CODEWITHSUNDEEP
.netasp.net-mvcweb-applicationsgarbage-collection
Avrohom Yisroel
Avrohom Yisroel

Reputation: 9440

How do I avoid hitting the application pool memory limit?

My client has a desktop application that he uses to run his business. It runs against a local database. He wanted a web site to display some of this data.

I wrote an ASP.NET MVC5 web site, that includes an action that takes an HTTP POST containing some XML, and updates the web site's database based on the contents of the XML. His application makes multiple posts to the web site to upload the data. These posts are made on after the other, not simultaneously.

However, we have discovered that when he has a lot of data to upload, it will work fine for a while, then he gets a "Service unavailable" error. I checked with the hosting company, and they said that the pool log file was full of entries like this...

11/10/2015 4:15:03 AM --- a worker process serving application pool has requested a recycle because it reached its private bytes memory limit.

Anyone any ideas what I can do about this? The web site uses Entity Framework, which I realise is not the most memory-friendly way to do it, but to recode it all to access the database directly would be a huge job. I'm hoping there might be some easier way.

Would it help if he slowed down the requests? It occurred to me (possibly incorrectly as I'm not expert in these matters) that it might be that the garbage collector just isn't getting chance to free up the memory before more is requested. If so, would slowing down the rate of posts help?

As I said, I'm not being an expert in these areas, so please go easy on me!

Upvotes: 1

Views: 1932

Answers (1)

Hadee
Hadee

Reputation: 1402

Two reason may cause speed issue on web applications: thread starvation and huge data amount in transaction.

On the Web server, the .NET Framework maintains a pool of threads that are used to service ASP.NET requests. When a request arrives, a thread from the pool is dispatched to process that request. If the request is processed synchronously, the thread that processes the request is blocked while the request is being processed, and that thread cannot service another request.

This might not be a problem, because the thread pool can be made large enough to accommodate many blocked threads. However, the number of threads in the thread pool is limited. In large applications that process multiple simultaneous long-running requests, all available threads might be blocked. This condition is known as thread starvation. When this condition is reached, the Web server queues requests. If the request queue becomes full, the Web server rejects requests with an HTTP 503 status (Server Too Busy).

for "thread starvation" the best approach is using "Asynchronous Methods". refer here for more information.

About "huge data amount in transaction", you should check your code. May be you using too much data without need to all of them. For example you transfer all object which you may need just one properties of object. In this case use "projection"(refer here for an example).

Also you may use "lazy loading" or "eager loading" base on you scenarios. But please be noted that none of these are magic tool for every scenario. In some cases "lazy loading" improve performance and on others "eager loading" makes things faster. It depends to your deep understanding of these two terms and also your case of issue, your code and your design.

Upvotes: 2

Related Questions