This is my set up on a stage server
compiled my web application
published website
copied the output directory from my machine to stage server
created domain account
created virtual site on a static IP
website runs under domain account created
impersonate set too true as windows integrated authentication is used with sql server
Now first time i hit my stage site, the page is slow to load which i understand, but subsequent request do take a while for the page to load.
planning to run wire shark to see what the traffic is. is there anything else that i should look for?
Note: My IIS and SQL are on the same machine.
You should run it through a profiler to see what it is spending so much time on. SQL Server includes it's own nice query profiler, and if you want a free profiler for .net, there's nprof. If you want to pay for a profiler for .Net, and it's probably worth it in the long run, there's lots of good offerings available.
Can you define slow? how many seconds?
Definitely check the queries to sql server to see what they are doing.
There is always task manager and take a look at cpu/memory. It is not hard to peg a single cpu for example. Anything else on the server?
When having problems I always like to have an empty aspx page just to eliminate other issues.
Related
For an ASP.NET Website where i am making updates. What would cause user sessions to reset?
From my understanding if i make any changes to files in the app_code folder or the global.asax file it will reset everyone's session but if i made a change to .cs file (in the top directory) it wont reset everyone's session?
Would it reset the session of anyone that was on that page that i updated?
Can someone help me with my understanding, thank you.
Assuming memory-based session (as opposed to sql server based).
Well, the app pool restart will blow out session.
(so, in some cases even un-handled errors will blow out session).
Modify web config?
that will case app pool to restart (and blow out session).
Update any folder outside of app_data. Again, app pool re-start (and blows out session).
change content of bin folder - again app pool re-starts, (and blows out session).
Update code behind (.cs, or vb pages (code behind)). - again, app pool re-starts, (and blows out session). (so anything that will cause a re-compile of code).
There are probably a good many more - the above is a basic list.
You can thus consider adopting sql session based, and that will thus be far more robust, and I even re-started IIS services, and users if not doing anything just looking at their web page while logged on? They were able to continue working even after a full re-start of IIS services.
On the other hand, I now always use a asp.net web site "applcation". Thus no souce code is placed on the web server, and my compile is done with visual studio before deploying. The only big issue is that if you change to a application deployment model, the even just changing one line of code behind will force/require a full re-publish of the web site.
It looks like you are using a web site, and thus source code (code behind) is placed on the web server. Thus, IIS has the job of re-compiling such code, and thus any code change will as a general rule cause a app_pool re-start, and thus loss of session.
As noted, if you change from in-memory session to SQL server based (turn that feature on), then most if not all of your session issues will go away. Even if you not using "application deployment" and have/use code behind on the site for IIS to re-compile? Then using sql server-based session management should fix all of your session() woes.
My IIS nested application hangs when I browse from IIS -- browser's busy spinner just spins forever.
I added a 2nd VS ASP.NET web app project to my primary web site, as a IIS 'nested' application.
The 2nd web app project debugs from VS OK and opens browser to it.
Is it possible to break in with debugger to see if code is in a loop or something?
BACKGROUND:
IIS 6.5 on my Windows Server 2012 R2 Azure VM
VS is 15.3.4
IIS > Sites > my primary web site > TEST (this Application added to primary) > Advanced Settings:
App Pool = DefaultAppPool
Physical Path = path to TEST's VS project
Virtual Path = /TEST
IIS 6.5...
Test Settings...
If you aren’t sure what issue is causing your website to spin forever, look at the live requests within IIS. From the IIS Management Console select Worker Processes.
Right click on your running application pool and select “View Current Requests”.
This will bring up a list of the currently running ASP.NET web requests as shown below.
I would suggest looking at the “Time Elapsed” to see if you have a lot of requests that are taking a very long time. You should also see if they are all stuck in the same module. This could be a clue that the issue is all related to ASP.NET Sessions or some other step within the ASP.NET request life cycle. You may also be able to identify a specific URL that is causing the problem.
Also in addition to that , I would highly suggest using a logging framework like NLog, log4net or Serilog. You can then send them to a log management service to make it easier to search them across multiple servers. Application logs are good way to trace your application trace across server.
If your web request is returning a 500 Internal Server Error, you need to check your server-side logs for exceptions. As mentioned above about application logs in general, it is important to have good exception handling in place and properly logging all of your errors.
Also you could use some open source diagnostic tool like Glimpse to trace. Glimpse is a thriving and growing family of open source NuGet packages that provides detailed performance, debugging and diagnostic information for ASP.NET apps. It's trivial to install, lightweight, ultra-fast, and displays key performance metrics at the bottom of every page. It allows you to drill down into your app when you need to find out what's going on at the server. Glimpse provides so much valuable information we recommend you use it throughout your development cycle, including your Azure test environment. While Fiddler and the F-12 development tools provide a client side view, Glimpse provides a detailed view from the server. You can try using that too.
Hope it helps.
I use Visual Studio 2013's "Publish" and Web Deploy to publish my Asp.Net MVC 5 website. However when I update my website, it won't work during the upload. I'm looking for a way to minimize the downtime of the website during the update. The website is running in a VPS and I have full access to it. One solution that came to my mind is to configure the Web Deploy to first put the uploaded files to a temporary folder and once the upload is finished, it should then replace the new files. This would make the update a few seconds tops. I can do this manually but that's not an elegant way to update one's website.
PS: Maybe there are better ways to update the website but so far I like the web deploy. It's much faster than FTP for instance.
One of the most interesting things I've seen is to have two websites. Only one of them is running at a time. After finishing the upload, you disable the active one, and enable the one you uploaded too.
This works well if both are in the same Application Pool and even works with sessions if you want (how to: Configure SQL Server to Store ASP.NET Session State).
I've never done it this way, seems a little to complex for the minimal down time there actually is, but it's one way.
Here's the solution that we use on a high traffic website with 4 web servers.
1) Files are moved to the server into /site/version-xxx
2) IIS Web Application is re-pointed to the new version.
All this is automated and synchronized across the web servers. The end user doesn't notice any difference. (we don't rely on sessions to persist the user experience, if sessions is a must for you and you don't want to interrupt them, then you need to consider to store them on an external system that will not flush them when the websites are repointed).
This approach also allows us to rollback to any previous version.
We would like to warm up an ASP.NET MVC application hosted on IIS 7.5 server. The warm up module that used to be available at http://forums.iis.net/t/1176740.aspx has been removed since sometime.
The application should be warmed up everytime IIS or ASP.NET worker-process restarts for any reason. During the warm up period, IIS should return some HTTP status code signifying its warm up state or its inability to serve any clients.
Would creating a executable that navigates through necessary pages in the site via HttpRequests be a good idea? The executable can be triggered from IProcessHostPreloadClient implementation. Is it possible to configure IIS so that it would only accept requests from localhost and once the executable is done, it can switch over to all clients - but that switch should not trigger an IIS restart (obviously).
Is it possible to use an Visual Studio 2010 - Web Performance Test to warm-up an application instead of creating an manual executable? Any other alternatives?
PS: The application uses Forms Authentication and uses sessions - so maintaining state cookie and other cookies is important.
UPDATE 1 - We are using .NET Framework 4.0 and Entity Framework (database first) in our application. The first time hits to EF queries are slow. The reason behind the warm up is to get these first time hits out of the way. We are already using compiled queries at most places and we have implemented pre-compiled views for EF. The size of the model and application is very large and complex. Warm up needs to walk through many pages to ensure that compiled and non-compiled EF queries get executed at-least once before any end user gets access to the application.
Microsoft has released a module that does exactly what you ask for. The Application Initialization Module for IIS 7.5 improves the responsiveness of Web sites by loading the Web applications before the first request arrives.
You can specify a series of Urls that IIS will preload before accepting requests from real users. I don't think you can get a true user login expereince, but maybe you can set up simulated pages that does not require login that fulfills the same warmup you ask for?
The feature I think is most compelling is that this module also enables overlapped process recycling. The following tutorial from IIS 8.0 include a step-by-step approach on how to enable overlapped process recycling.
When IIS detects that an active worker process is being recycled, IIS does not switch active traffic over to the new recycled worker process until the new worker process finishes running all application initialization Urls in the new process. This ensures that customers browsing your website don't see application initialization pages once an application is live and running.
This IIS Application Initialization module is built into IIS 8.0, but is available for download for IIS 7.5.
You may take a look at the following post for the Auto-Start feature built into IIS 7.5 and ASP.NET 4.0.
Any application that generates a server request for the hosted resources can be used to warm up an IIS process. Exactly how many requests you need depends on what parts need warming up. Typically, warm-up is used for:
Starting up a worker process. For this, you only need to ask for one resource to warm up a process for the entire application.
Perform any static initialization, database startup, or pre-caching. Anything you do in your Global.asax file will happen when you do your first request, so if you can make all of your initialization happen then, you'll still only need to make one page request.
Force pre-compilation of ASP.NET pages. For this to happen you would need to hit every page. Fortunately, this is typically not much of a time cost, so you likely don't need to worry about it. If you do have individual pages that load slowly, you can warm them up separately.
The "warm-up" process here isn't anything magical. You just need force IIS to serve the URL in question. Everything you mentioned would take care of that: using a stress-test tool to query the URL, writing a custom utility to post HTTP requests, even just scripting out a tool like 'wget' or a PowerShell script to download the URLs would do it.
As far as restricting access to localhost, as far as I know, within IIS, the only way to change that requires you to restart IIS. You could always build a pre-request hook into your application and maintain the state there, and have your warm-up process query some specific URL that toggles that state to "open". But I'm not sure what you would accomplish. If, somehow, a user did try to query your site before your warm-up finished, all that would happen is your site would take a long time to respond, then they would eventually get the page they asked for. If you locked them out of the site during warm-up, they would instead get a browser network error that claimed the site was offline, which (to me) sounds much worse.
I compiled my app in release mode. I then went ahead and 'published' the site.
Copies all files and moved them to a staging server with a static ip. Restarted IIS.
Went to another machine and hit my web site. It took about 4 seconds for just the default page, which is pure HTML with no custom framework usage, to show up. What gives???
Sounds like it is just the application pool spinning up. Assuming that you are the first person to hit it after deployment, this isn't uncommon. It appears fine after the first page hit, correct?
If you set the #Page directive variable "Trace=True" does that show you any load times which out out of place? Also, if you are connected to a database, running SQL Profiler for example will show you any database queries which are too slow.
Lastly, I had a strange issue where I had a virtual directory setup which pointed to a directory that didn't exist. The network timeout that ocurred looking it up took a while.