I have an Windows Azure app (Asp Net Mvc 4).
And there is some ajax in this app. Some requests with simple in-memory server logic (no sql, no external web services).
When I run it locally in debug mode, it takes about 900 ms for ajax request to get a response.
Locally in release mode, it takes about 30 ms (It`s OK).
When I publish app to Azure it takes 450 ms for request to get a response. I try both debug mode and release, also cloud and local service configuration. In all cases it takes 450 ms.
Question: is there something that I did not take into account?
To properly diagnose the performance of your ASP.NET MVC application, you need to take in consideration:
The latency between your client computer and the server. Use the ping utility to measure that.
The time it takes to establish the HTTP and/or HTTPS connection.
The time spent waiting for other concurrent requests your browser may be issuing.
Data transfer time, both to send the request and to retrieve the response.
Queueing on the web server due to overload.
Time spent on the server actually processing the request. You can measure this with the StopwatchAttribute described in this article. Use the current code from GitHub though, because the code in the article is not compatible with ASP.NET MVC 3.
Tools like Chrome's and Internet Explorer's Developer Tools, Firefox's Firebug and Yahoo's YSlow can give you a greater insight on your application's performance.
Related
I have an Rest API that is hosted in IIS8. The API is not called very frequently, perhaps 30 times per day. It seems that when the API is called it takes quite a while to get the first result, subsequent calls a short time later return very quickly. It seems that IIS is releasing resources and unloading the API and resources after a period of time.
Is there a way to force IIS to keep API up and active so that every time a request comes it responds quickly?
Couple of ways are mentioned here - Can you prevent your ASP.NET application from shutting down?
Other then that there is Application Initialization module http://iis.net/downloads/microsoft/application-initialization. Application Initialization module makes sure your process is up and running and loaded with all the necessary libraries, however it works only on IIS 7.5 and greater and framework 4.0 and above.
I deployed node js server to Azure WebApp, and it worked fine. But, I see that sometime the response time is very slow. Also, I see that somewhere above 500 request/second the server start to fail handling request, and I see it use only 15% CPU. Now, I checked and the server return 500 error because the pipe is busy (by the win32 error code). That's why I was wondering if there is something I can change in the IISNode config to improve the server request capacity.
I already enabled the AlwaysOn feature, and also I add a check in Pingdom to keep the site alive. Also, I already changed nodeProcessCountPerApplication to 0 so it use all the available process.
Thank you,
Omer
One thing you can do is enable Always On. Without it, when your site hasn't been visited for 20 minutes the site gets taken down. Then the next time someone makes a request to your site Azure Web Apps warms up (re-sets up) your site but this process takes a few seconds.
Note that Always On is only available for sites in Basic, Standard, or Premium SKUs
Also, check out this page for tips on debugging Node.js apps in Azure Web Apps: https://azure.microsoft.com/en-us/documentation/articles/web-sites-nodejs-debug/
We have a web application that runs on 6 web servers with HAProxy as the load balancer. We use web deploy to sync our IIS and application across all web servers. Starting January some of customers starting reporting application slow downs. After a lot of work we found that request coming to IIS at random times get stuck in BeingRequest state of IIS Web Core. I am attaching a screenshot from one of my server. Any insight into the issue will be really appreciated.
Thanks,
Fahad
I have a similar issue but my requests are stuck in a different part of IIS. If anyone has any input there you may also find it useful - Debugging requests which are 'stuck' in an IIS worker process
In the screenshot you give your oldest request is 16s old - do they stay in forever or are they just very slow to process? If they don't process is the oldest request in the queue always exactly the same URL and if so can you trigger the issue with that URL?
If they do eventually process (or even if they don't) a good first step for you would be to run Failed Request Tracing/Logging - you can configure it directly in inetmgr at site level. Looking at the compact output will give you an overview of if your requests are being sent on loops around IIS or if there is anything triggering that you wouldn't expect in the life of the request.
If they do eventually process also look into utilisation exhaustion - maybe IIS is just crawling as it's struggling for CPU/RAM/IO - check out the usual suspects.
I am working on windows azure cloud service. First time when i click on login button it takes 6 to 7 seconds but after sometime when i click on same login button it takes 2 seconds. I am not able to understand why it is happening so though the server side code is same for both processing but subsequent calls are quiet faster than first call ?.
"First-hit" delay is very common with ASP.NET applications. There is the overhead of JIT compilation, and various "pools" (database connections, threads, etc) may not be initialized. If you have an ASP.NET Web Forms application, each .aspx page is compiled the first time it is accessed, not when the server starts up. Also the various caching mechanisms (server or client) that make subsequent requests faster are not initialized on that first hit. And on the very first hit, any code in Application_Start will be run, setting up routing tables and doing any other initialization.
There are various things you can do to prevent your users from seeing this delay. The simplest is to write some kind of automated process that hits every page and run it after deploying a new release. There are also modules for IIS that will run code ahead of the Application_Start, when the site is actually deployed. Search for "ASP.NET warmup" to find those.
You may also experience delays after a period of inactivity, if your ASP.NET App Pool is recycled - this resets a bunch of things and causes start-up code to be run again on the next request. You can ameliorate this effect by setting up something to ping a page on your site frequently so that if the app pool is recycled it is warmed up again automatically, instead of on the next actual user request. Using an uptime monitoring service will work for this, or a Scheduled Task within the Azure ecosystem itself.
I have a web application that's consuming a WCF service. Both are slow on warmup after IIS reset or app pool recycle. So, as a possiible solution I installed Application Warm-Up for IIS 7.5 and set it up for both web site and wcf service.
My concern is, it doesn't seem to make any difference - first time I hit the site it still takes long time to bring it up. I checked event logs, there are no errors. So I'm wondering if anything special needs to be done for that module to work.
In IIS manager, when you go into the site, then into Application Warm-Up, the right-hand side has an "Actions" pane. I think you need the following two things:
Click Add Request and add at least one URL, e.g. /YourService.svc
Click Settings, and check "Start Application Pool 'your pool' when service started"
Do you have both of these? If you don't have the second setting checked, then I think the warmup won't happen until a user hits the site (which probably defeats the purpose of the warmup module in your case).
There is a new module from Microsoft that is part of IIS 8.0 that supercedes the previous warm-up module. This Application Initialization Module for IIS 7.5 is available a separate download.
The module will create a warm-up phase where you can specify a number of requests that must complete before the server starts accepting requests. Most importantly it will provide overlapping processes so that the user will not be served by the newly started process before it is ready.
I have answered a similar question with more details at How to warm up an ASP.NET MVC application on IIS 7.5?.
After you have fixed possible software/code optimizations allow me to suggest that each and evey code needs processing via hardware cpu. And our server skyrocketed in performance when we went to a multicore cpu and installed more GIGS of ram and connected UTP-6 cable insetad of standard UTP 5e cable onto the server... That doesnt fix your problem but if you are obsessed with speed as much as us, then you will be interested in the various dimensions that bottleneck speed.