As an aspdotnetstorefront hosting partner and company that is widely regarded for the quality of aspdotnetstorefront hosting we provide we’re often contacted by aspdotnetstorefront website owners hosted elsewhere. Recently, we’ve noticed an increased number of new aspdotnetstorefront website owners contacting us about the performance of their own aspdotnetstorefront store and wondering why the aspdotnetstorefront stores we host seem to out perform their own site. More often than not the question is something like this:
“When I first load my aspdotnetstorefront store it’s very slow to load but then after a couple page loads it’s much faster and very responsive. What gives?”
Usually, the store owner immediately assumes it’s their designer, their developer or even the code because the rest of their website loads fine so it can’t be the host.
Often the host will further complicate the confusion by saying things like “No, you must have a memory leak because your site is using ALOT of memory” or “No our servers are fine, look at these sites they all load fast”. Although these things can happen we usually find they are not the culprit.
Why’s my aspdotnetstorefront site slow on the first load? Is it the code?
So then why is my aspdotnetstorefront store slow? Is is the code? Yes it’s the code! But it’s not the aspdotnetstorefront code! It’s actually the .NET framework or ASP.NET. When an ASP.NET site is called for the first time it’s compiled and then executed. While it’s getting compiled the page is going to load very slowly but then once compiled it will load extremely fast. This is usually the initial slow down you see when you visit any ASP.NET based site that’s been inactive or is just being visited for the first now. So this issue is NOT an aspdotnetstorefront issue but instead a shortcoming of the .NET framework.
Now, once the application is compiled, this compiled copy is then cached on the server so any subsequent requests will be VERY fast. If however the site isn’t very active or goes through a period of inactivity the server will see that the compiled code is taking up resources that could be used elsewhere so it will release that memory and make it available to the other applications running on the server. So the very next time your site (or web application) is executed it will need to compile all over again and you’ll experience that same slow down once again.
Can I avoid this slow down caused by the site going inactive?
So how can I avoid this? Many clients that don’t have very active sites and have clients that are sensitive to the slow down will find a clever workaround. They workaround this by setting up with a website monitoring service that will access their site on a given interval and pull one of the web pages to verify the site is online.
This causes the site to compile or remain compiled and has the benefit that now your site will be quick for everyone accessing it. The downside to this is that the site will be consuming memory even when it’s not in use and also CPU each time it’s compiled.
But my site goes really slow when people are surfing it or checking out?
Today it’s no secret about ASP.NET being compiled on the first execution and the slowdown it causes as many have become used to it. In fact with ASP.NET 2.0 you can even get around this sometimes by using pre-compiled binaries.
A bigger problem is when your site visitors start to complain that during a visit to your website while going from one page to another the site suddenly becomes unresponsive. Even worse is when during checkout their cart errors out or is suddenly empty! So what gives?
In this case it’s both the host and the site compiling! This is most often the result of the application pool your site is hosted in recycling. You see, in IIS6 each site is generally isolated in it’s own application pool, this is for security and stability. If one site starts to act up (or crash) it will only crash those sites in the same application pool as itself. So if every site is in it’s own application pool (the way we do it at appliedi.net) then your site is less likely to be affected by other sites on the same server.
So Why do dedicated application pools matter?
Think about it this way. Your e-commerce site is probably a major part of your store’s revenue and when it’s down you’re not earning any money. Now in a classic shared hosting account where many sites share a single application pool if one of the sites in that pool were to crash, then it goes down and takes the rest of the sites in the application pool down with it.
If your site is in it’s own dedicated application pool then when those other sites start crashing your site will remain online and responsive.
Great shouldn’t every host do it this way?
Yes, every host should do dedicated application pools, but they don’t. You see, for the discount hosting providers, the bargain hosters or the monster marketing hosts (like the guys you see ads for during the superbowl) they’re concerned about getting the best bang for their buck. Since their hosting is generally very inexpensive they find ways to get as many sites as possible hosted on each webserver. So by using shared application pools they’re often able to get many more sites per server.
Dedicated application pools result in better security (each app pool runs as a unique user so no two app pools can share or see each other’s data) and better stability (obviously) but the downside to this is that you use more memory on each server and aren’t able to get as many sites per physical server.
But I’m in a dedicated app pool and my app pool recycles all the time!
Now many of today’s hosting providers (including the cheap hosting guys) are moving to dedicated application pools for security and stability. In fact, they proudly let you know that you’re in a dedicated application pool. Some hosts even provide little application pool monitoring tools so you can see when your application pool recycles.
You’re probably finding that your application pool is recycling frequently and each time it recycles your site has to compile again.
For an e-commerce site this means not only did your client just suffer a lost cart but now they have to sit there and watch the progress bar spin until your site comes up again so they can start all over!!!
The problem is more than likely that your host has a very restrictive memory limit and although it’s fine for many simple applications or less active websites, for today’s advanced web application like aspdotnetstorefront, it’s just not enough. These hosts usually restrict your application pool between 75MB to 120MB of memory with 100MB being pretty typical.
Most of today’s advanced web applications (like aspdotnetstorefront, bvcommerce, dotnetnuke, kentico, communityserver, etc) need between 100MB to 150MB on average and can grow to require much more.
So if you find that your application pool is recycling frequently (say when you have more than just a couple site visitors or more than a handful of products) then it’s most likely that the memory limit is being reached and the server is automatically recycling the application pool to keep the memory usage in check.
Does AppliedI set an application pool limit then?
Yes we do set an application pool memory. We do this because the shared hosting servers are shared servers and these resources need to be shared among multiple sites.
The memory pool limits range between 100MB (such as on our valueplus plan) to our VS-3 semi-dedicated hosting plan which is set at 500MB of memory. These limits are of course monitored as well as the websites running in them to make sure they provide adequate resources for today’s websites. As the needs of web applications continue to grow these memory limits too will continue to grow.
So what do I need for my aspdotnetstorefront store?
So now that you know your site is probably recycling because of it reaching a memory limit you’re probably wondering how much memory your application needs?
We see on the average website application pool running aspdotnetstorefront store is anywhere between 120-140MB of memory.
We set the VS-1 (our recommended aspdotnetstorefront plan which includes 250MB of SQL, the ability to run your own SSL certificate and all the features you need for an aspdotnetstorefront store from just $22.96/month) at 175MB of memory which is more than enough for the majority of today’s advanced web applications.
What happens as my aspdotnetstorefront store grows? Can I continue to grow?
Absolutely! Applied Innovations core business is built around providing the hosting infrastructure your business needs to grow and facilitating that growth. This is why we call our hosting customers our “E-Business Partners” and our slogan is “Empowering Successful E-Businesses” because we provide the tools and technologies you need to not only grow your business but to succeed in your industry. We provide several shared hosting plans to help you grow gradually as well as virtual private servers and managed dedicated hosting services for when your site really starts to take off!
We found that website owners state one of the most difficult things for a website owner is having to switch hosting companies, you don’t know who to go to and you’ve probably built a relationship with your previous host that you really don’t want to switch hosting providers and as your E-Business partner we understand this and are here to help you grow.
So that’s why AppliedI.net is the leading aspdotnetstorefront hosting provider?
That’s not why but it’s certainly part of our secret sauce recipe. It’s not special coupon codes or clever marketing. Applied Innovations is a web application hosting provider that caters to growing businesses like yours and provides a series of services and product offerings that facilitate the growth and success of your business.
This does lead me to ask one question though?
So that’s the story on why your aspdotnetstorefront or for that matter any asp.net application is probably responding slowly and what Applied Innovations does to keep this from being a factor. I do however have one question for you, Why if your business ( and most likely your very livelihood) relies on your website, then why oh why did you try to skimp on your hosting service?
BlogEngine.NET
Recent Comments