Devexpress grid slow reponse after idle - asp.net

I'm using devexpress gridview on developing application that users have to view group of row data,my application works fine on development server of visual studio 2010 but when i deploy the application on iis 7.5 performance issue become clear.
when page is loaded on IE for the first time ,application respond normally and ajax calls respond fine,but when application became idle for awhile*(approximately less than 5 minutes)* ,ajax calls responding issue appear (takes 20 seconds for a single request).
note that:
-i review all application pool configurations on iis.
-i notice that when i use Firefox application respond normally but unfortunately i need to use it on IE.
-when i deploy the application locally from my machine (Local IIS) application respond normally.
could any one help please

If you're saying that the response time in Firefox is good then the issue is not IIS.
Devexpress controls are heavy on client (javascript) and can cause delays in page loading (especially if you use jQuery)
I suggest to:
create a test page that has nothing other than the gridview on it.
Enable client script debugging (in IE options)
use IE developer Profiler to see any client errors

Related

IIS 10 on WinServer 2019 is loading asp.net pages very slow even on subsequent loads

My question has nothing to do with the initial page loads. My ASP.NET Web Site is running very slow, on IIS 10. Even when I refresh the page after a load, it takes minutes. What do I need to check?
Application Initialization Module is installed and running
App Pool is using Classic managed Pipeline mode and has Start-Mode set to AlwaysRunning
Preload Enabled in Website's setting is set to true
The same application runs fine on another server running older WinServer and IIS 8. What do I need to check?
This is embarrassing. Posting this answer so I find my own question the next time I run into this again, or someone else runs into this. My application on the other server where it runs, has caching configured so all the database pulls are cached. This new server has no caching set up. Those pulls are so slow, I am finally getting the hang of it.

IIS only processing one request at a time

We have an asp.net web application that works fine in our environment. One of our partners tries to the exact same code in their environment and can only process one request at a time. For example, there is only page that calls a long running stored procedure (5 minutes). If you call that page and the try to open a new page, the new page won't serve until after the first page has completed. We can see the request back up by looking at the worker processes for their application pool. They are running IIS 8.5 on a windows 2012 server. They're also running SQL Server 2016.
The database connection is structured the same as as in our environment. The stored procedure is not wrapped in a transaction. Any ideas what might be causing this behavior?
IIS also can work in the Debug mode, when it is enabled, Asp is limited to processing one request at a time in a single-threaded manner.
Open “InetMgr” or IIS manager, double click ASP under the IIS section of the website. Check the below settings in Asp section.
See the below discussion for more information.
IIS7 - only serves up one page at a time. It's a making me crAzY!

Easiest way to run/debug ASP.NET Core app

I just upgraded my ASP.NET (Framework) MVC app to ASP.NET Core 2.2. That process was painful enough, however even more painful is running the web app locally.
Issues with running in IIS Express:
If I launch the app with F5 (to enable debugging), then once I stop debugging the browser window closes so I have to start over on the homepage each time after changing any code.
If I launch the app with Ctrl + F5 (no debugging), after a few rebuilds the website seems to die, meaning that any new page requests just say host not found. I then have to Ctrl + F5 again to get it going again, but then I'm back on the homepage.
Visual Studio 2019 sometimes decides to launch the webpage in my existing Chrome window on a new tab, but sometimes decides to launch it in an entirely new Chrome window. After several minutes of dev, I'm left with multiple tabs and windows open.
Issues with running in IIS:
The only way it runs is if I manually edit my Web.config to have the proper values for processPath ("dotnet") and arguments ("./bin/Debug/Housters.Web.dll"). Visual Studio likes to inject in aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" every time I build or run my app, despite me having IsTransformWebConfigDisabled = true in my .csproj. So I constantly have to go into git and revert these changes, or else my app will fall back to the dreaded ANCM In-Process Handler Load Failure page.
Assuming the Web.config has the proper values, after running the application in the browser I can no longer build the project. Instead it gives the error: Error MSB3027 Could not copy "obj\Debug\netcoreapp2.2\Housters.Web.dll" to "bin\Debug\Housters.Web.dll". Exceeded retry count of 10. Failed. The file is locked by: "IIS Worker Process (15496)". IIS is using the ASP.NET Core web app's dll so I can't actually update my code and build it, that's just great. The workaround is to recycle my IIS app pool, but this gets old REAL quick when you need to do it before every single rebuild.
Attaching to the w3wp.exe process isn't causing any breakpoints to be hit, so I can't debug under IIS (IIS Express debugging works fine.)
The launch profiles that I configured in launchSettings.json are ignored. For example, when I choose my IIS launch profile (which has "http://localhost" as the launchUrl and applicationUrl), if I F5 or Ctrl + F5 it opens "http://localhost:62551/" in the browser window.
So this begs the question, how are others developing/running/debugging their ASP.NET Core apps on their local dev machines? Maybe most web developers have moved away from ASP.NET to purely javascript frameworks like Angular, React, and Vue so I'm just out of luck? Or am I missing something that will make ASP.NET Core development less painful?
Currently, the experience with ASP .NET Core has greatly improved compared to the past.
However, certain glitches still remain. For what regards IIS Express (in production we use Kestrel), you can try these things with Visual Studio 2017 and 2019 (they work for us):
If I launch the app with F5 (to enable debugging), then once I stop debugging the browser window closes so I have to start over on the homepage each time after changing any code.
Just don't use the page: let the tab/page open, spawn another tab/page and use the latter for debugging. This way your session is going to be as similar to a production environment. We have Firefox as default browser, but we usually debug with Chrome, therefore, not touching the process spawned by Visual Studio keeps IIS Express alive.
If I launch the app with Ctrl + F5 (no debugging), after a few rebuilds the website seems to die, meaning that any new page requests just say host not found. I then have to Ctrl + F5 again to get it going again, but then I'm back on the homepage.
It seems that cleaning the whole solution twice solves the issue (at least for us). The first time you clean the solution, IIS Express still serves the site. Apparently, this should be the designed way (cannot find the documentation about that).
If that does not work, it might happen that a Visual Studio service is stuck. In this case, shut down Visual Studio (I know, it's painful), wait a little bit, and kill all the dotnet.exe currently running after verifying they are part of Visual Studio.
Visual Studio 2019 sometimes decides to launch the webpage in my existing Chrome window on a new tab, but sometimes decides to launch it in an entirely new Chrome window. After several minutes of dev, I'm left with multiple tabs and windows open.
This is partially what I said previously. Although painful and resource expensive, having multiple windows open allows us to survive.
For reference, we use the very same configuration on debug and release (with kestrel).

How to identify an iisreset in an asp.net web application?

I've got an application that needs to do some work on startup (before the first request is in).
I've added the initialization code in the global.asax file (Application_start method) but this code doesn't seem to be hit after an iis reset is performed.
Is there an event which is triggered in an asp.net application when an iis reset has occurred?
Thanks.
Application start happens on first request, not on iisreset.
The site doesn't start itself..
See "Restart cache item callback on web process restart" here.
In such cases, the service will stop
running unless a page is hit and the
Application_Start is called.
Application_Start is called only when
a page is visited for the first time
in a web project.
I would suggest having a batch file that contains iisreset and an "iexplore mypage" call
Edit: apparently, you can use application end to trigger application start. YMMV
http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx
This may be of help to you.
Tho the features are new to IIS 7.5 which is only on Windows Server 2008 R2 / Windows 7.
Auto-Start Web Applications with ASP.NET 4
Some web applications need to load large amounts of data, or perform expensive initialization processing, before they are ready to process requests. Developers using ASP.NET today often do this work using the “Application_Start” event handler within the Global.asax file of an application (which fires the first time a request executes). They then either devise custom scripts to send fake requests to the application to periodically “wake it up” and execute this code before a customer hits it, or simply cause the unfortunate first customer that accesses the application to wait while this logic finishes before processing the request (which can lead to a long delay for them).
ASP.NET 4 ships with a new feature called “auto-start” that better addresses this scenario, and is available when ASP.NET 4 runs on IIS 7.5 (which ships with Windows 7 and Windows Server 2008 R2). The auto-start feature provides a controlled approach for starting up an application worker process, initializing an ASP.NET application, and then accepting HTTP requests.
Edit: Link to more information about Auto Start feature.
http://www.asp.net/LEARN/whitepapers/aspnet4#0.2__Toc253429241

asp.net mvc 2 website MUCH slower on IIS 7.5 vs built-in server

I am taking some time to learn how to develop asp.net mvc2 websites, but I'm used to working directly off IIS instead of the built-in web server that uses the random ports when you hit F5.
but I've noticed that using the built-in webserver, requests fly and are immediate. I am using only the default project with the Home and About pages as it comes out of the New ASP.NET MVC 2 Project settings, no database connections, nothing beyond the base install...
but when I setup the IIS website and pointed it to the same directory, each request takes at least 3-5 seconds to complete, sometimes more.
this isn't just the "load" on the first request. EVERY request takes this long on IIS.
but if I F5 and test the project once again, everything zips and the responses are immediate.
What might i have configured incorrectly?
this is on win7 x64 by the way
You can check with a tool like firebug what takes the longest time in the request. If you use firebug it will tell you which part of the request cycles takes a certain amount of time. (I once used this when I encountered problems with the localhost URL, Firebug told me that the DNS request took about 2 seconds while using 127.0.0.1 took 1ms (using google I found out that was an issue due to ipv6 enabled)). So try tracing the requests with Firebug.
If the request to IIS is performed quite fast and the browser is waiting for a response for a long time it must be in the handling of IIS (the built-in server and IIS are different). In that case you can try reinstalling IIS (to make sure no plugins or other data is in IIS making the site slower) by removing and adding IIS via the windows components.
If that still doesn't solve the problem try tracing on the application via the built-in tracing capabilities of ASP.NET (http://msdn.microsoft.com/en-us/library/wwh16c6c.aspx)

Resources