Best practice - load a lot of stuff in the application_start?

Question

I have a webshop with a lot of products and other content. Currently I load all content in to a global list at Application_Start, which takes aprox 15-25 seconds.

This makes the the site really fast, as I can get any product/content in O(1) time.

However, is this best practice?

Currently I got a webhotel which is not a VPS / Dedicated server, so it recycles the application from time to time, which gives random visitors load times up to 15-25 seconds (only to become a bigger number with more content). This is of course totally unacceptable, but I guess it would be solved with a VPS.

What is the normal way of doing this? I guess a webshop like Amazon probably don't load all their products into a huge list :-D

Any thoughts and ideas would be highly appreciated.

It is acceptable for small to medium sites. It may not scale well to multiple servers. Depends on the data too. — H H, Mar 14 '12 at 18:42
I use MSSQL as a database. I would also like a solution for when we get 50.000+ products, and this method is probably not that scalable :) — Lars Holdgaard, Mar 14 '12 at 18:49

score 7 · Accepted Answer · answered Mar 14 '12 at 18:52

It looks like you've answered your question for your case "This is of course totally unacceptable".

If your goal O(1) normal request to database for single product is likely O(1) unless you need to have complicated joins between products. Consider trying to drop all your pre-caching logic and see if you have problem with performance. You can limit startup impact by lazy caching instead.

Large sites often use distributed caching like MemcaheD.

score 5 · Answer 2 · answered Mar 14 '12 at 18:51

5

A more scalable setup is to set up a web service to provide the content, which the website calls when it needs it. The web service will need to cache frequently needed content to achieve fast response times.

answered Mar 14 '12 at 18:51

Jonny Cundall

2,552
1
21
33

score 2 · Answer 3 · edited Nov 21 '12 at 09:12

Separation of responsibilities will help you scale for the future.

With your current setup, you are limited to the resources of your web server, and, like you said, your start up times will grow out of control as you continue adding more products.

If you share the burden of each page request with SQL Server, you open up your application to allow it to scale as needed. Over time, you may decide to add more web servers, cluster SQL Server, or switch to a new database back-end altogether. However, if all the burden is on the application pool, then you are drastically limiting yourself.

Aristos · Answer 4 · 2012-03-14T19:32:08.310

First of all, 15-20 seconds to load data is too much time, so I suspect this cases

This time is for compile and not the data load
The data is too much and you full the memory
The method that you use to read data is very slow
The data storage is too slow, or the struct is on text file and the read of it is slow

My opinion is that you cache only small amount of data that you need to use it too many times in short time. The way you describe it is not good practice for some reasons.

If you have many pools you read the same data on all pools and you spend memory for no reason.
The data that you cache you can not change them - is for read only
Even if you cache some data then you need to render the page, and there is where you actually need to make the cache, on the final render, not on data.

What and how to cache.

We cache the final render page.
We also set cache for the page and other elements to the client.
We read and write the data from database as they come and we left the database do the cache, he knows better.
If we cache data then they must be small amount that needed to be used for long loop and we avoid the database call many times.

Also we cache as they ask for it, and if not used for long time, or the memory need space this part of cache gone away. If some part of the data come from complex combinations of many tables then we make a temporary flat big table that keep all the data together, every one in a row. This table are temporary and if we needed too much we make a second temporary database file that we keep this part of the data.

How fast is the database read ? Well is so fast that you not need to worry about that, you need to check other point of delays, like as I say the full render of a page, or some parts of the page.

What you need to worry about is a good database design, a good and fast way to retrieve your data, and a good optimize code to show them.

Best practice - load a lot of stuff in the application_start?

4 Answers4