Here's an interesting story about performance I had the chance to work on over the last couple of weeks. The object of the call was a UserControl embedded in Internet Explorer, which was very slow to load the first time you browsed the page, but then was performing quite well after that long delay (around 60 seconds); unfortunately closing and reopening the browser caused another 60 seconds delay, which was quite bothering if not frustrating for end users... As you can imagine the control needs to be downloaded, JIT compiled and loaded which of course requires some time depending on how big is the control, how fast (or slow) the Internet connection, how powerful the client etc..., but those 60 seconds where definitely too much. Moreover on Vista we were prompted to run csc.exe and under some circumstances (usually if IE was not run as Administrator) we got a FileNotFoundException.
First thing, Fiddler showed that after downloading the first dll (the actual UserControl) we were probing for further localized resources, so we wasting about 15 seconds just for this reason (which is a quarter of the entire time spent waiting on a white IE page...). At the same time Process Monitor showed (as expected) that some time was needed to JIT the control but also to create on the fly the serialization proxy assembly, which the UserControl needed to call a remote Web Service and get the data to show to the user.
There are different possible approaches to the problem, but in this case we had some constraints imposed by the hosting company the customer was using to test his application, so to work around those limitations we first removed the strong name from the two assemblies because it was not a strict security requirement in this case and because strong named assemblies are prone to probing (as you may know, one of the token in a strong name is the culture information). Then we specified the NeutralResourceLanguageAttribute to tell the ResourceManager to not search for resources that are included in the main assembly; when looking up resources in the same culture as the neutral resources language, the ResourceManager automatically uses the resources located in the main assembly, instead of searching for a satellite assembly with the current user interface culture for the current thread. This will improve lookup performance for the first resource you load, and can reduce your working set. As a final step we added an empty file (zero bytes) in the first places where the runtime was probing; this because the NeutralResourceLanguageAttribute resolved the problem for me (I was testing with an English OS) but not for the customer whom was using a non English OS...
As you can see from the screenshot here, the runtime was also probing for <assemblyname>.XmlSerializers.dll which is the proxy needed to call the remote Web Service (and which needs to be created on the fly, as Process Monitor shown); so in this case we used sgen.exe to pre-generate the serialization assembly we could put on the server in the same folder of the UserControl. This serialization assembly is downloaded by the browser and therefore there is no need to create it on the client, so we removed both the security prompt (and the exception) and the delay to create the proxy on the client.
In short, after applying those changes the time taken from the first HTTP request to the UserControl fully loaded and functioning on the client went from about 60 seconds to just 5!
There is a nice article from Chris Sells on the subject, it's 5 years old but still gives some interesting insight on probing and how serve related files (like .config etc...).
Doing further researches for this post I found another couple of possible solutions to the problem. First it's possible to specify a codeBase attribute in your web.config as described in http://support.microsoft.com/kb/814668/en-us (this applies also to .NET 1.1).
Or you can add a section to the web.config file telling the ResourceManager exactly which resources are present on the machine for each assembly. Here's an example:
1: <?xml version="1.0"?>
2: <configuration>
3: <satelliteassemblies>
4: <assembly name="mscorlib, Version=..., PublicKeyToken=...">
5: <culture>fr</culture>
6: </assembly>
7: <assembly name="UserAssembly, ...">
8: <culture>fr-FR</culture>
9: <culture>de-CH</culture>
10: </assembly>
11: <assembly name="UserAssembly2, ...">
12: </assembly>
13: </satelliteassemblies>
14: </configuration>
Note that the assembly references in this example are abbreviated, and they will need to supply full assembly names.
Carlo
You've been kicked (a good thing) - Trackback from DotNetKicks.com
hi,
i got into same issues with our control, so i tried to follow your advice, but without success. The loading time is still like 14 sec from remote machine even if dll is allready in download cache...
So i'd like to ask this: have you accessed your control from local machine or from remote one?
regards
Lubos
Hi Lubos,
This was done all on the remote server, the traces and values I talked about where all captured from my machine in Milan to a web server located somewhere in France (I think) over the Internet.
Have you tried using Fiddler? The control is already in your local cache, but is it downloaded every time? Where are you spending those 14 seconds? Anything interesting on the IIS logs?
If you're able to answer those "tracing" questions and you should (hopefully) have a more clear picture of what's happening (and at least know where you have to concentrare your efforts).
HTH
i'm using HttpWatch which is really similar to fiddler and i'm sure that control is allready in download cache.
when i got deeper into this it seems that activating the control itself on clients machine takes this long time - but this seems to be dependent on connection... from what i saw no requests (even to check if assembly was modified or not - 304) are going...
what i did - i put trace messages into control and on client side i attached debugger to see them - result is that there's like time difference like 5-20 secs (depens on connection)
i also tried to create small application which creates new appDomain, set the same way as IE does and tried to do AppDomain.CurrentDomain.CreateComInstanceFrom(http://zzz.zzz.dll, typeName) to simulate IE host behavior (i'm not sure if it's really the same) and measured the time needed for this action - it gave similar results as IE...
have you got any experience with that?
regards and thanks a lot!
Uhm... that is strange (that no request is made to even check if there is a newer assembly version available)... and if the time taken to load the control depends on network connection, should mean that something is really happening over the network, right?
I don't have experience creating a COM host to then load the CLR, but why are you using the CreateComInstanceFrom method? Do you need a COM instance of your managed assembly?
Anyway, to be sure you could capture a network trace to see what's transferred over the network, and Process Monitor to see how much time (if any) is spent by the compilers (csc.exe etc...); you can also consider to have a Fusion log to see if there are problems finding and loading the needed assemblies (maybe there is some delay there, too)
Hi,
I am struggling with similar (winforms Usercontrol NO database web service) it is just a DLL getting downloaded into "Temporary Internet Files"
is this default behaviour it suppose not to download again and again if the DLL is not changed?
Thank you
Sahridhayan
Correct, there is no reason to download again the dll if it has not changed. If you see your dll is downloaded every time, maybe the client "loses" the file every time (for some reason it is deleted?) and needs to get it again from the server, or maybe for some reason the file "expires", or the local cache on the client is deleted (there is a setting to control this behavior in IE), or for some reason the runtime is unable to check the version of the local file and compare with the version of the online file...
Unfortunately there might be quite different reason for that kind of problem; try to check all the fundamental requirements and you should be able to at least identify where the problem lies. If you'll then need assistance understanding the reason behind the behavior (and how to fix it), of course I can suggest you to open a support call with us at http://support.microsoft.com :-)
Thank you for consideration in responding.
I will take up with them it will take long process as for i am experienced. :)
but before that please just comment me with this inputs,
0. The file does not get deleted. All page contents (gif,web resource,browser config,DLLs,..etc) available
1. In IE we have setting "Temporary Internet Files"
- check newer version of stored pages for,
- Every time open IE (Not selected)
- Every visit of Page (Not Selected)
- Automatic (Selected)
- Never (Not selected)
2. My dependent DLLs does not get downloaded everytime (vendor dlls licensed), we use license.licx file to include them.
Our DLL is "COMVisible" set to true.
3. I have tried to sign my DLL and tested still same result.
4. I have tried the solution provided in Support ticket (probing issues) so i gave paths for all DLLs in a config file. Still the config gets downloaded into Temporary Internet Files folder, but the performance same.
5. as you said i have run the Fiddler, the DLL got downloaded almost instantly when the page browsed but the loading into IE takes time (when we close and Open the browser)
6. We have Proxy specified in IE settings.
7. It is a intranet site, but we have corporate level Network Policy, i have tried to exclude the group policy for the machine & account by "gpupdate /force"
Now can you throw some light?