These questions and answers are directly from ASPDNSF‘s support and copied here w/ permission:
- Does the cart support .Net 2.0? .Net 3.5? Are there migration plans for 3.5?
.NET 2.0 is fully supported, and while not officially supported, it works fine on .NET 3.5 from all reports. Version 8.0 will be .NET 3.0+ only
- Does the cart use native SQL components, or use OLE DB? Does the cart support more than one type of database?
We use native .NET SQL components. Microsoft SQL 2005/2000 is the only supported DB, and we will be moving to SQL 2005 ONLY in version 8.
- Does the cart have a large foot print for loading separate instances of the code for each customer/session? Are there any statistics as to memory usage at high volumes?
This really depends on where the customer is at in the shopping process, but in a nutshell, no. Most data is stored in the DB as opposed to in memory, so while there is some memory usage for each customer, it is a relatively small amount.
- How does the cart handle moving objects from the worker process to the state server? Are they making use of the session? To what extent?
Our app is server farm safe, so almost NO data is stored in the session state. We store session information in the customer session table in our DB.
- How does the cart perform at higher volumes? What are the limits of scalability? E.g. number of products in database, limitations from IIS.
250,000 products and 25,000 entities (maybe a bit more in terms of entities) is about the max that the store was designed for, but can scale beyond that with a bit of tuning. Scalability at that point is directly proportionate to the amount of tuning the developer is willing to do.
- To what level has the cart been tested (i.e. Customer volume and transaction volume)?
Customers have reported handling a load of 35,000 orders per hour on a 10-server farm with a single DB server and hardware load balancer.
- For high volume sites, are there any recommendations for hardware or configuration?
It depends on what high volume is considered, but the app is typically processor limited on the web server, so the more procs/cores the better. These days there is no reason not to max out RAM on the server, and we do have a 64/bit version J
- For high volume sites, are there any performance tuning or database server side practices recommendations for the base cart?
Actually yes. Our software supports a HUGE feature set, so performance tuning is typically an exercise of removing unneeded features either at a code level or in the sprocs. For example, on a product page load we have to account for customer levels, sale prices, template switching, inventory filtering, multiple currencies, multiple locales, œCatalog Only sites with no buy buttons, multiple images per product/color, image filename overrides, spec calls to external html files, downloadable products, etc. Spending some time turning off unneeded features can go a long way in wringing the last bit of performance out of the web server.