I have an IIS website which connects to MySQL. I have a link in the website which do the intensive calculation. When this link is triggered, it uses around 20% of CPU resource. Then, if I click other links, the other links are responding very slow. Until the link that does calculation finished, then other links responding time will resume. I am curious why only 20% CPU is used, but the other links still respond slowly. It seems the calculation link occupies the CPU resource. But isn't it different link are run in parallel, how it should be affected by intensive calculation of one link? How can I improve that, or should I tune something in IIS of my code?
Increase the maximum number of worker processes in your IIS application pool for your website. This will enable the server handle multiple requests at the same time. Below is how.
Open IIS Manager and Navigate to Application pools.
Right click the application pool for your website and select Advanced Settings.
In the Advanced Settings Dialog Box under Process Model, change the value of maximum worker processes to 10. [You may enter another number (greater than or less than 10)] 1 is default and means only one worker process will be started to handle all your requests. Meaning that only one request will be processed at a time.
Click Ok to save your changes
Restart your application pool [Not mandatory but advised]
Thats all. Your Website should now be able to process multiple requests at the same time
Related
In IIS there are two areas (well, more than two) where recycling can occur:
Under the "Process Model" section → "Idle Timeout" (default 20 minutes)
and
Under the "Recycle" section → "Regular Time Interval" (default 1740 minutes)
My questions are:
What are the differences between the two methods?
What are the negative implications of settings them to 0?
Idle Timeout is if no action has been asked from your web app, it the process will drop and release everything from memory
Recycle is a forced action on the application where your processed is closed and started again, for memory leaking purposes and system health
The negative impact of both is usually the use of your Session and Application state is lost if you mess with Recycle to a faster time.(logged in users etc will be logged out, if they where about to "check out" all would have been lost" that's why recycle is at such a large time out value, idle timeout doesn't matter because nobody is logged in anyway and figure 20 minutes an no action they are not still "shopping"
The positive would be get rid of the idle time out as your website will respond faster on its "first" response if its not a highly active site where a user would have to wait for it to load if you have 1 user every 20 minutes lets say. So a website that get his less then 1 time in 20 minutes actually you would want to increase this value as the website has to load up again from scratch for each user. but if you set this to 0 over a long time, any memory leaks in code could over a certain amount of time, entirely take over the server.
From here:
One way to conserve system resources is to configure idle time-out
settings for the worker processes in an application pool. When these
settings are configured, a worker process will shut down after a
specified period of inactivity. The default value for idle time-out is
20 minutes.
Also check Why is the IIS default app pool recycle set to 1740 minutes?
If you have a just a few sites on your server and you want them to
always load fast then set this to zero. Otherwise, when you have 20
minutes without any traffic then the app pool will terminate so that
it can start up again on the next visit. The problem is that the first
visit to an app pool needs to create a new w3wp.exe worker process
which is slow because the app pool needs to be created, ASP.NET or
another framework needs to be loaded, and then your application needs
to be loaded. That can take a few seconds. Therefore I set that to 0
every chance I have, unless it’s for a server that hosts a lot of
sites that don’t always need to be running.
IIS now has
Idle Time-out Action : Suspend setting
Suspending is just freezes the process and it is much more efficient than the destroying the process.
I have inherited a desktop app that makes calls to a series of Web Services on IIS. The web services (also) have to be able to run timed processes, independently (without having the client on). Hence they all have timers.
The web service timers were shutting down (memory leak?) so we set the Idle time out to 0 and timers stay on.
I am working on an OLAP application, WCF + Silverlight clients (up to 100 concurrent users). Unfortunately from time to time, a specific service call goes crazy (although it is perfectly valid, just too complex) and occasionally (once a month) brings the whole server down (by consuming all CPU).
A solution would involve killing user request or even the whole user session which is not a big deal for us from the business perspective - recovering/restarting the whole application is.
The idea of isolating user sessions into separate processes is very tempting: CPU/memory throttling and clean resource disposal (not like Thread.Abort) - if modern browsers can do this just for web pages, maybe it's time to do this on servers. We just want to evaluate this concept and see pros and cons in our particular scenario.
Hence the questions:
Is there already an existing library/framework which will be useful for managing processes (like pre-spawning/reusing processes, throttling, kill after timeout)?
Are there any "best practices" or guidelines how to create such architecture?
I was having same problem with my WCF services they too serve more than 100 clients..
and problem which i discovered using IIS logs (C:\Windows\System32\LogFiles\HTTPERR)
I found my problem in Application Pool Recycle timeout on IIS setting.
Application pool was getting restarted every 48 hours and which was causing issues with already subscribed clients.
So i would suggest
1. Analyze the http error logs and IIS logs which will give more information about all the application pools status if any gets shutdown or recycled.
2. If application pool crashes then Setup for Windbg and attach the process set the correct source file path. It will tell you the location if any exceptions are occurring.
Intro
I am developing a web application using ASP.NET MVC 3, C#, targeting IIS 7.0+. We have a number of long-running async requests (utilizing AsyncController/Async action features). I also use HttpRuntime.Cache quite often (and in some non-standard way which doesn't really matter here).
Question
Can IIS application pool be suddenly recycled if there are active long-running requests present? I want to prevent that behavior if possible as I don't want to lose data from cache.
Do I really need to use some persistent storage (i.e. Database) to overcome possible issues?
Normally IIS won't recycle an application which has pending requests for it due to period of inactivity. But IIS could recycle your application if you hit memory or CPU tresholds. But this is something that you could configure in your IIS management console.
When a recycle is triggered there is a "shutdown time limit" that defaults to 90 seconds. That's how long processes have to finish before they will be shutdown forcibly. This is configurable through IIS, you likely want to increase this to a large value in addition to removing non-desired recycle triggers (memory, CPU, time, schedule, requests, etc.)
So I'm running a Windows Service as a user. Admin rights. This service launches an EXE via Process.Start. Within the EXE, a WebBrowser control is used to navigate to a website, log in, handle all the security handshaking, and get some data. It comes back out, writes the data to a file.
Not the most efficient process, admittedly, but my work situation has stuck me with it.
Anyway, when testing the WebBrowser EXE directly, it runs really quickly, but when it's running from the service it goes substantially slower. Why would this be? Are there some network bottlenecks placed on services? I've tried raising the starting thread priority of the process WebBrowser exe in the Process.StartInfo of it before I run it, and that works a bit, but it is still massively slow.
Within the WebBrowser EXE, I'm waiting until pages are complete or certain elements appear by constantly polling the state of the WebBrowser. Could that be the cause of this slowness?
I've also seen very similar slowdowns when using HTTPWebRequest to do the same sort of things from a service -- it'll run relatively fast from a Forms app, but very slowly from a service.
So yeah, my predicament can be summarized thusly:
Why do WebBrowser and HTTPWebRequest transactions seem to take longer when executed by an EXE called from a Windows Service running as an admin user?
There will be tons of setting missing because the HKEY_CURRENT_USER hive is not loaded in service (LoadUserProfile is not called in serivce). I am not even sure how IE's security zone policies work without the zone definitions.
And IE has a small simultaneous connections limit, 6 on a broadband connection in IE8. If your web server has more concurrent users than the limit then someone has to wait.
I have a website hosted under IIS 7 on Window 2008 x64. IIS is running in 64 bit mode and the site has its own Application Pool 64 bit etc. The website appears to run fine most of the time and then all of a sudden each hour it freezes the users request. They don't get a timeout message, it just hangs and appears to wait for about 2-3 minutes before returning the page.
I have monitored the Worker Process on that application pool during and see the processor is at a very steady 25%. Memory is fine and not increasing in any scary way.
I have setup Failed Request Tracing to show me every issue where a request takes more than 30 seconds and yes it records it but with no errors.
Other websites in different application pools on the same server are working fine during the outage.
Any suggestion of how I might debug this issue?
Do you have IIS set to recycle worker processes on that application pool on a given schedule? You indicate you monitored it, but you didn't indicate whether or not you found it to be recycling excessively, just that the memory allocated wasn't increasing in an untoward way.
Do the IIS logs show anything unusual during the time period? Try an app like Fiddler to help debug requests to the web server.
Turn out we were using a control called i-Load to resize images. It has a function to delete temp files after 3 hours. This was locking the IO and causing out entire web-app to halt. Switch it off and all work fine now. Hope this helps someone.
Does the Application depend on a Database that has some Job running every hour?
In case the DB is under heavy load, it would take longer for the queries to execute on your DB and therefor take longer for your web-app to process the pages.
Yes IO process can block the application pool pending thread once not completed other one. So create another thread of IO process and proper handle the cancel token source.