I'm working in an ASP.NET MVC 4 application, and on app start up I'm looking using BuildManager to get all referenced assemblies.I'm looking through all types in the application to find a few that I want (it's dynamic so I don't know what types I need until start up).
Essentially my code looks like this:
var allTypes = BuildManager.GetReferencedAssemblies()
.Cast<Assembly>()
.SelectMany(a => a.GetTypes());
I'm calling this on app startup but also at the beginning of each new request in order to dynamically find types.
So my questions are:
Since ASP.NET doesn't load assemblies until they're needed, by calling BuildManager.GetReferencedAssemblies() am I loading ALL assemblies before they're needed and causing a performance issue?
Is iterating through all types a bad idea for each request? I could cache the types but ASP.NET has the option of loading assemblies dynamically after I've cached them, right? If so I may miss some types which are indeed there.
Thanks!
Don't do it every request: do cache as early as possible; reflection is slow.
Pre-load all the assemblies and do it on app-startup; I have a system that I use in a lot of our websites which has to do a lot of dynamic stuff based on deployed assemblies, and I do all the work on startup.
Yes startup is therefore slower - but that's less of a problem than each request taking longer.
You will then most likely be interested in a question I asked and answered a while ago about how to preload all deployed assemblies reliably: How to pre-load all deployed assemblies for an AppDomain.
I still use the same process to this day and it works like a charm.
Related
Hi I have project developed in ASP.NET MVC. I am using Entity framework database first approach. Problem I am facing now is, first time when user loads my website, it takes time to load which is unusual. So I am searching for the reason behind this. Can anyone help me in this?
For a moment, I am assuming since I am using database first approach, I have to load all database to my project first before i connect. So I think it is making my website to load slower.
If this is the case, can someone guide me to generate connection string dynamically during run time in entity framework and connect to database?
I have stored procedure from which I can get connection string. But I dont know how can i use that connection string and connect to database.
When you say “first time when user loads my website, it takes time to load which is unusual” could you give us a comparison of how slow is slow the first time. And by “first time” is you mean after re-starting IIS or re-starting the app-pool, it may take some time as some of your code would have to be turned into native code by the just-in-time computer.
EF may slow you down if you have many hundreds of tables and it has to re-construct the context based on all of those tables and relationships. Even if it is the case, you would see the delay in every time you create a new EF context. But if this is the case, you may have to create multiple contexts each with a limited number of tables to manage. A good read on that http://msdn.microsoft.com/en-us/magazine/jj883952.aspx
Other than that, I would suggest you do the usual things such as pre compile your views (http://geekswithblogs.net/Aligned/archive/2013/05/28/pre-compiling-your-mvc-views.aspx) and use caching
Love to hear how it went
I use rails to present automated hardware testing results; our tests are run mainly via TCL. Recently, we have implemented a "log4TCL" which is basically a translated version of log4J. The log files have upwards of 40000 lines, each of which is written to the database as a logline record, and load time for the view is too long to be considered usable. I have tried to use ajax requests to speed things up, but the initial query/page load accounts for ~75% of the full page load.
My solution is page caching. I cannot use the rails included page caching because each log report is a different instance of "log_viewer". The report is generated using a test_run_id parameter. Rails-included page caching only caches one instance of "log_viewer.html". What I need is "log_viewer_#{test_run_id}.html". I have implemented a way of doing this. The reports age out after one week and are purged from the test_runs/log_viewer_cache directory to save disk space. If an older report is needed, loading the page re-generates the report with a fresh age-out timer.
I have come to the conclusion that this is the way to go. My concern is that I have not found any other implementations such as this anywhere which leads me to believe that I have missed an inherent flaw in my design. Any input would be much appreciated.
EDIT: For clarification, the "Dynamic" content of this report is what takes too long to load. I need to cache multiple instances of what action/fragment caching is not concerned with.
I have several websites that are currently experiencing the following problem. Over time, rendering of a specific partial view (asp.net mvc 1) will degrade, and take around ten times longer than it does normally. I currently have a workaround, but it's far from ideal.
Take this node off our load balancer
Stop IIS
Delete all temporary asp.net files
Start IIS
Hit the site to get caches populated and views compiled
Put the node back on the load balancer's rotation.
I know that it's not the restarting of IIS fixing it, it seems that the temp asp.net files have to be deleted for this to work properly. After those steps are completed, performance on the site is much, much better for around three to six hours. After that, it goes back to being terrible. The partial view that's having issues pretty much just renders out some html with cached data. We have not been able to reproduce this issue in our dev environment at all, so we're pretty stumped. We're going to be upgrading our live environment shortly, so I'd just like to know what's causing this problem. If it's configuration related at all, I want to make sure it's fixed with our new setup. Anyone ever seen this before?
There could be many things at play here, an initial check list
confirm app is not deployed in debug mode
what logging do you use and is it being done excessively?
what is the bottleneck on the server when this happens? memory? then you might have to check for a leak
do you regularly recycle your app pools?
Can you give some more details on what this partial view actually does?
The solution for this problem was to clean up the temporary asp.net files. We integrated this step into our deploy process, and the site overall has been running faster.
I have one doubt here , I have one asp.net MVC web application and every night we are recylcing the applciation pool from IIS. Now when the next day first request comes it is taking time to get response.
First request it is taking time because app domain is not loaded (application is not started) to start web application it takes some time.
Now the question is does the just in time compiler will come here again ?
Means every morning it needs to recompiled by JIT again ?
Yes, the application will be compiled from IL to executable code again after the recycle: Throwing away the appdomain will also loose the JITed native images.
You could, for instance, avoid some of the compilation by putting dependent assemblies that don't change often in the GAC, and use NGEN on them. That could possible speed up things a bit.
JITting will normally not have a huge performance hit. Cold startup of the IIS process, starting your AppDomain and loading your assemblies from disk will probably have much higher impact. Also, your application might have some custom startup logic in the global.asax file (reading stuff from db). And don't forget your database might have to wake up as well.
I have an MVC view with a partial view recursive call that displays hierarchical data.
The complete tree typically includes in the order of 500 or so items.
The data is all included in the model, and the model's a trivial record class - nothing in it except auto-properties.
In IIS this works fine.
However in Cassini/WebDev (Visual Studio's built in web server) this page runs painfully slow and often times out.
A little digging shows that this is due to each call to Html.RenderPartial taking around 200ms (or 1/5 of a second). The actual partial view seems to take under a millisecond or so.
Anyone got any ideas why this is so slow?
Why would it be different between IIS and Cassini? The IIS application is pointed at my development directory; they're running exactly the same code, build and config.
I think this could be related to the caching of view resolved paths. The article here explains the issue to which I am referring.
Do you notice the same behaviour if you pass the full path of the view, like:
RenderPartial("~/Views/MyView.ascx")
Kindness,
Dan