Databases
StackOverflow2013
Postsdbo
POrazor performance on web server much slower than using VS development server
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POrazor performance on web server much slower than using VS development server
    primarykey
    data
    text
    <p>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.</p> <p>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)</p> <p>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. </p> <p>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.</p> <p>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. </p> <p>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).</p> <p>I verified that the IIS version was running the release code and the dev server the debug code (by logging HttpContext.IsDebuggingEnabled in controller)</p> <p>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)</p> <p>So far what I've concluded from these results are:</p> <p>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.</p> <p>It's not due to a failure to cache and reuse the compiled razor code (evident from the time pattern in the logs)</p> <p>It's not likely due to the application as all the pages of similar complexity experience similar problems</p> <p>It's not a browser side issue as the same browser instance was used to view both.</p> <p>It's not a 64 vs 32 bit issue as both are apparently using 32 bits.</p> <p>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).</p> <p>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.</p> <p>So far I am stumped as to what may be causing this 700+ msec additional time when rendering on the web server.</p> <p>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.</p> <p>UPDATE: I've added code to print out Environment.Version. Dev Box: 4.0.30319.468 Web Server: 4.0.30319.1</p> <p>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.</p> <p>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. </p> <p>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.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USSteve Hunt
    1. USSteve Hunt
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. POrazor performance on web server much slower than using VS development server
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POrazor performance on web server much slower than using VS development server
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POrazor performance on web server much slower than using VS development server
      1. USDarkWalker
      1. VTFavorite
    1. COdo you have the correct .net runtimes loaded on the server? perhaps the razor is being parsed in 4.0 in one and 4.5 in the other?
      singulars
      1. POrazor performance on web server much slower than using VS development server
      1. USClaies
    2. COPerhaps there's a resource that it can't find in the live version such as an image or script resource. That used to hang us up a bit when someone would reference a script such as 'http://localhost...'. The result is that in the live environment the browser just hangs while looking for a resource it won't be able to find. Also, is there a backing data-store that may be causing the hang? If the backing data store needs re-indexing or something it can drag down the performance of the site.
      singulars
      1. POrazor performance on web server much slower than using VS development server
      1. USBlackjacketMack
    3. COThat's one of the few variables I haven't eliminated yet. However, I'm not sure how to verify it. I don't know which .net dll's are the critical ones such as the Razor compiler. The backing data store is a separate SQL server and the application accesses this third server both when run on my desktop and when run on the web server. Also note that DB calls are only made in the controller and the times show that the controller performance is not the problem. I don't believe it could be a missing image or script resource because the razor code only sees them as strings.
      singulars
      1. POrazor performance on web server much slower than using VS development server
      1. USSteve Hunt
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload