I've published an MVC application on IIS 7.5 on external server. But when i run it it just says "Waiting for..." and nothing is happening! No errors, no application logs (because the application didn't even started), no IIS logs, no errors/warnings in event viewer. Can you tell me what can I do to track what is going on? Keep in mind that in development environment everything works fine. Also I already published the same application on another server and it is working like a charm.
the best you can do is to add glimpse to your project and see its reports,
btw, if you are using a shared host it could be a memory limitation, slow CPU, slow bandwidth,....a lot of possibilities....
Related
I do not know if this is a Visual Studio, ASP.Net-MVC, IIS Express or EPIserver issue.
The problem is that in Visual Studio, when I click on what looks like a play icon, it takes at least 5 minutes until my local EPIserver development website loads in the browser.
I have tried selecting different browsers from within Visual Studio: Firefox, Chrome, MS Edge.
We have also tested this on 2 identical laptops, and 2 identical desktops. All running the latest Windows 10.
What happens is that about 4-5 seconds after I click on play, a browser instance will be launched. This is pointing to localhost. It then takes at least 5 minutes for the website to start loading in the browser.
This is making it really hard to work efficiently.
I would be very thankful for any tips on what to try, what to check, etc..
I am a relatively new users when it comes to all of the above mentioned components, so I would be very thankful for step by step tips on what to check/test.
Enable log4net logging (usually config file called EPiServerLog.config in the site root) using a relevant appender with debug-level logging.
The logs can probably show you what happens after the site has started. I have seen examples where poor implementations have, for example, iterated all content on a site on startup, causing a ton of database traffic as the cache is populated. Needless to say that takes a long time. :)
If the logs don't give anything away, I would suggest attaching the VS debugger to do some basic profiling on startup.
Example on configuring log4net, albeit an old post.
How do I debug an always pending request? This morning something strange started to occur, one request (which should download an PDF file) stopped working. When I reproduce the error I can't see anything in the web browser (tried multiple browsers just in case) or any log files on the server.
All the other requests works fine which makes everything seems strange. I have checked at another server with identical code and there it works just fine, also I have tried to do an iisreset without any success. On the hardware side everything seems great (cpu, ram, disk, network).
We use windows server 2012 and IIS 8
Any ideas on where can I start look for errors?
I have a web application running on a deployment server that uses MVC5 and EF6. I have the same version concurrently running on my development machine. I can make updates or add functionality and test it on the development machine and have no problems, then publish it to the deployment server and it will work fine.
From 2-8 days all of a sudden the system starts giving me entity validation errors, or giving me an error about changing an entities Id in a simple page that does nothing but load some entities and iterates through the list to display them.
To fix the problem I literally do nothing other than go back in to VS2013 and click publish...I don't change any code or settings...and it works again.
Anyone else have this problem or know what could be the cause? Its not a complex web app and there are no background processes running.
What are the best practises to limit (or best, eliminate) hang time when publishing changes to a single-server IIS 8 ASP.NET MVC application?
Now, we are deploying our changes via MSBuild.exe trough TeamCity. Once the app is deployed, it hangs for a little less than a minute doing its startup things (building NHibernate proxy assemblies, changing db schema, building ioc container etc.).
Is there a way for us to setup that the "old" process keeps handling requests until the new one is fully ready (and not just deployed) ?
EDIT:
Our startup code is launched via the
[assembly: WebActivator.PreApplicationStartMethod(typeof(..), "..")]
attribute.
You didn't specify what version of IIS you are using, but if you are using version 8.0 then you might want to take a look at the Application Initialization feature: http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-application-initialization
You'll want to set your application pool start mode to AlwaysRunning and then set preloadEnabled to true. Setting preloadEnabled to true tells IIS 8.0 to send a "fake" request to your application when the associated application pool starts up, whilst this won't eliminate the startup compilation, it will mean your application is available sooner than it was previously. You can also set IIS to display an alternative page whilst compilation is occurring, if you don't want your users hanging on...
I have an MVC 3 application where browser page loads are much faster when running in debug mode using VS2010 and the VS Development server on my desktop (windows 7 with 8GB RAM) than they are when loading from an actual web server (a virtualized 2008 server running IIS 7.5 and hosted on an Intel box with twin Xeon CPUs on the same LAN as my desktop). Just the opposite of what one would expect and hope for.
To help figure out what is going on I added code to log the start and end times corresponding to executing the controller code and the razor code as well as the interval between the two. I repeatedly switched between loading the instrumented page and another web page in the same application in my browser (FF) then looked at the logs from both servers. (FYI the pages in question are loaded via Ajax so there's no caching on the browser side)
I skipped the initial cycle which included the time to compile the razor code and averaged the results over the subsequent 5 load cycles although the numbers for all the repetitions were pretty similar.
The controller code execution time was 133 msecs for IIS vs 113 for my dev server. Somewhat surprising considering that the dev server was running the debug version and IIS the release version but not significant at least from a user perspective.
However the razor execution time was 823 msecs for IIS vs 72 msecs for my dev server, over an order of magnitude difference!! At first I though perhaps the razor code was always getting recompiled on IIS but the logging showed a large time lapse between end of controller execution and start of razor execution for the first load and only a few msecs for all subsequent loads for both IIS and the VS dev server so it seems clear that the compiled razor code is being used in both cases.
I verified that both were running as 32 bit apps (by logging the size of intptr) and also that Enable 32 bit apps was set true in the IIS app pool settings (also set to v4 and integrated mode).
I verified that the IIS version was running the release code and the dev server the debug code (by logging HttpContext.IsDebuggingEnabled in controller)
I also repeated the experiment with other pages in my app and they all show the same loading behavior for pages of similar complexity so it does not appear to be something funny with that particular page (much simpler pages did load more quickly as one would expect)
So far what I've concluded from these results are:
It's not likely a difference in resources on the two boxes as the execution time of the controller code is virtually the same and there was no other significant traffic on the virtual server besides me at the time of the tests.
It's not due to a failure to cache and reuse the compiled razor code (evident from the time pattern in the logs)
It's not likely due to the application as all the pages of similar complexity experience similar problems
It's not a browser side issue as the same browser instance was used to view both.
It's not a 64 vs 32 bit issue as both are apparently using 32 bits.
It's also not some difference in the code because I published the code to the web server at the same time I performed the tests ( and they both have the new logging code I added).
I considered the possibility it could be the LAN (because presumably the razor code is being rendered and sent at the same time it is executing rather than being buffered and sent after rendering) but the payload is only around 140KB (from Net tab in Firebug) and the LAN is 100MB switched. To help eliminate this as a factor I found a file of around 240KB on a file share on the same web server and copied it to my desktop. The transfer was almost instantaneous. Certainly nowhere near 800 msecs.
So far I am stumped as to what may be causing this 700+ msec additional time when rendering on the web server.
UPDATE: I succeeded in getting IIS 7 installed on my desktop and pointing directly at my project. Page loads are as snappy as they are using the VS development server so it does not appear to be simply an IIS vs VS Dev Server issue.
UPDATE: I've added code to print out Environment.Version.
Dev Box: 4.0.30319.468
Web Server: 4.0.30319.1
I'm going to figure out how to update the web server. Also not sure if this is the whole story. Perhaps the MVC dll's have separate versioning but don't know yet how to figure it out.
I also find it curious that even after publishing (when I have built the release version), when I run my local web server (which points at the same folder that is published) it shows debug mode.
UPDATE: I checked and it appears that I'm providing all the Razor dlls in the project's bin folder and thus they should be the same on the server and the desktop. Presumably MVC will check first in the bin then the GAC.