I have a single-tenant ASP. NET web application which is deployed on a Windows 2008 R2 web server and DB is on another server. My application uses at-least 20 3rd party DLLs, and the total size of these DLLs is around 150 MB. Assuming we have 20 customer sites running in IIS, these 20+ DLLs hog a lot of memory space as they get loaded in each individual IIS process. My problems: Very slow site load times: a fresh customer single-tenant install takes around 3-5 min to load the home page. I am assuming it takes that much time to load all these DLLs in memory space. RAM hogging: My RAM is being used up like crazy, as we scale (get more customer installs precious memory space will get used up for these same DLLs. These 3rd party DLLs will not change much in future (no upgrades). So given these conditions, should I go ahead and install these assemblies in GAC? From what I read, I find developers advising me against GAC for various reasons (which I do understand but I still feel that given my conditions, installing these assemblies in GAC will not only improve my load times significantly, but also save precious RAM. Any inputs would be great. Note that I have already profiled the application performance using ANTS and dot Trace, and there are no significant bottlenecks which would cause the app to load so slow during the first hit. Also note that application performance is acceptable AFTER the first hit. It loads all pages within 3 seconds, but the first hit takes 3-5 min.
I too had this problem and noticed that it was mostly related to 3rd-party assemblies acquired via Nu Get. In these cases, Visual Studio was trying to load PDBs from paths that apparently existed on the original author's machine (i.e. D:\ Original Author\ My Visual Studio Projects\ Awesome Nu Get Package) but on my machine the same path referred to an optical drive. I then discovered via Command Prompt that if you tried to change directory to an optical drive that didn't have a disc in the tray, it took a very long time (~30 seconds) to fail. With this in mind, my solution was to simply place a DVD in the tray. At that point Visual Studio was able to very quickly determine that the path didn't exist, skip loading the PDB, and go straight into debug. So, if Visual Studio is taking a long time to load symbols, watch the Output window for the paths it's trying to access and verify that you can quickly access (or quickly fail to access) those paths yourself via Command Prompt. This brings up an interesting question about security/privacy-apparently Visual Studio is storing the absolute path of the original PBD within the assembly. I suppose this isn't a super critical issue, but from a privacy perspective I don't really want my absolute filesystem paths being exposed to the public without my knowledge.
Download Now