We have a Asp.net MVC 3 application with 3 areas, Unity dependency injection, about 20 routes. The total time to render the page is very inconstant. The biggest problem seems to be the amount of time it takes to start the action method within the controller. Even when viewing the same url. Sometimes the action is started within 100 milliseconds sometimes its greater than a second, this happens in all environments from development to production.
Does anybody have some fresh things to try?
Check out MvcMiniProfiler.
It will allow you to measure the time it takes to render any portion of the action method you specify.
Not sure what you mean by "time it takes to start the action method".
Maybe there is some rogue action filters going on?
Sorry, but this is a large problem with having a huge singleton (unity) around implementing IDependencyResolver. I would bet that you are leaking memory.
edit
In response to your comment:
The reason that memory leak or the DI Container struck me as the issue is because there should be really no time inbetween the controller firing up and an action firing up as they are very close to each other. A simple way to test if it is a memory leak is to let the application sit unentered for a good amount of time (30 minutes to 2 hours) and then attempt to revisit it. If this is quick at first then that could indicate a memory leak. If it is slow on first request then perhaps it is something else. If memory leaking is not the issue then perhaps it is something easier. You said it is before the controller finishes so I would rule out rendering the view (which can take some time). Something you said makes me wonder about your web.config file. "this happens in all environments from development to production." Perhaps your production environment is still running under debug=true. These are all the ideas I could think of at the moment.
Related
Every postman requests spent less and less time
This is the first request
And this is second.
Why does it work like this? I saw this when I was writing spring application and now the same with quarkus.
Similar to running your JSP pages when running a Spring application, at the first time, everything is getting compiled, built, rendered, and presented, and many other operations, but if you hit refresh for that JSP page again, it will happen much faster because it does not compile, build and rendered every time, it is just being present.
This is just a very simple example to get an idea, you are probably not using JSP pages, but the concept is still the same.
Basically, first requests in theory do like 10 tasks, but after everything is done, the number of tasks is much lower, hence the speed.
I'm trying to display a server response time on the page similar to google's search time, something like "page loaded in about 1.3 seconds" or so.
What is the best way of achieving this? I currently have a MVC framework setup, and my initial approach was to store initial time in the controller, and pass it as the model into the view and it is up to view to calculate the time elapsed.
Somehow I feel there must be a better approach, that, for all requests, context might already have the information recorded, either the request start time, or the elapsed time.
Can someone please verify if my original thought was right? or there exists an already implemented solution?
Thanks,
Jason
If you wait all the way until your controller, you're potentially missing a lot of the "load time". You want to use a Filter to time the request from as early to as late in the process as possible. The Java EE Tutorial has more details on writing Filters. There's also another SO answer that deals with exactly this:
In spring MVC, where to start and end counter to test for speed execution time?
You could use a servlet filter to store the start time in a request attribute for each request (or at least for each request to a page), and compute the elapsed time at the end of your view execution.
If you use a template engine like Tiles or SiteMesh, this elapsed time computation would be called in a single place: the page template.
I'm using AbstractAjaxWicketBehavior in my Wicket application and it seems to have a descending performance over time when more AJAX calls appear. When a page is refreshed without AJAX, the performance is fine again. I would like to know if this is a normal thing or can be a memory leak of some kind present? I can't simply attach the code as it's spread over more classes and it would require too much effort to understand, but in short I want to do this:
create and start the timer
repeat some code 10x
stop the timer
set some values to attributes
ajax refresh (causes show/hide of some components)
and do the same again (hypotetically infinite times).
Every repetition of this flow is slower even though I use constant updating interval of 100ms.
As the timer is a behavior and does not allow to be restarted or reused, it is created every time as a new instance and attached to the Form component.
The timer looks like this:
static int count = 0
new AbstractAjaxTimerBehavior(Duration.milliseconds(100)) {
// do some code
count++
if(count == 10) {
stop();
// do some code
}
}
This behavior is attached to a Form inside a Panel and upon a click on an AjaxLink the Form is refreshed (added to AjaxRequestTarget). Every time I remove the old timer from the Form component before adding the new behavior.
Everything works fine, but every repetition of this procedure runs slower (The first one is perfect, the second one is also around 100ms, but then it gets slower (after 10 or 15 repetitions, the refresh interval is about 1 second) and all other AJAX calls in the app also go significantly slower), so I suspect there is a memory leak... any obvious reasons? Or any ways how to make a wicket timer better for my purpose? Any advice appreciated. Thanks.
Our wicket applications also tend to get slower with every AJAX-Request. I'm not sure if this is the exact same problem or if it relates to the AjaxTimerBehavior in particular, but:
We found that one reason for this are pseudo leaks in the browser that occur due to HTML replacement. Obviously the nrowser cannot free memory until the page is reloaded.
You can monitor Browser Memory with the Task manager (or another Tool) and watch Memory raise with every AJAX-request and how it reliefs on a full page reload (F5). Especially in IE.
We replace alot of HTML with our AJAX-requests though.
I run a Symfony 1.4 project with very large amount of data. The main page and category pages are using pagers which need to know how much rows are available. I'm passing a query which contains joins to the pager which leads to a loading-time of 1 minute on these pages.
I configured cache.yml for the respective actions. But I think the workaround is insufficient and here are my assumptions:
Symfony rebuilds the cache within a single request which is made by a user. Let's call this user "cache-victim" to simplify things.
In our case, the data needs to be up-to-update - a lifetime of 10 minutes would be sufficient. Obviously, the cache won't be rebuilt, if no user is willing to be the "cache-victim" and therefore just cancels the request. Are these assumptions correct?
So, I came up with this idea:
Symfony should fake the http-request after rebuilding the cache. The new cache-entries should be written on a temporary file/directory and should be swapped with the previous cache-entries, as soon as cache rebuilding has finished.
Is this possible?
In my opinion, this is similar to the concept of double buffering.
Wouldn't it be silly, if there was a single "gpu-victim" in a multiplayer game who sees the screen building up line by line? (This is a lop-sided comparison, I know ... ;) )
Edit
There is no "cache-victim" - Every 10 minutes page reloading takes 1 minute for every user.
I think your problem is due to some missing or wrong indexes. I've a sf1.4 project for a large soccer site (i.e. 2M pages/day) and pagers aren't going so slow even if our database has more than 1M rows these days. Take a look at your query with EXPLAIN and check where it is going bad...
Sorry for necromancing (is there a badge for that?).
By configuring cache.yml you are just caching the view layer of your app (that is, css, js and html) for REQUESTS WITHOUT PARAMETERS. Navigating the pager obviously has a ?page=X on the GET request.
Taken from symfony 1.4 config.yml documentation:
An incoming request with GET parameters in the query string or submitted with the POST, PUT, or DELETE method will never be cached by symfony, regardless of the configuration. http://www.symfony-project.org/reference/1_4/en/09-Cache
What might help you is to cache the database results, but its a painful process on symfony/doctrine. Refer to:
http://www.symfony-project.org/more-with-symfony/1_4/en/08-Advanced-Doctrine-Usage#chapter_08_using_doctrine_result_caching
Edit:
This might help you as well:
http://www.zalas.eu/symfony-meets-apc-alternative-php-cache
I just want to ask for your experience. I'm designing a public website, using jQuery Ajax in most of operations. I'm having some timeouts, and I think it should be for hosting provider cause. Any of you have expirience in this case and may advise me on some hints (especially on timeouts handling)?
Thanks in advance to all.
Esteve
If you have a half-decent host, chances are these aren't network timeouts but are rather due to insufficient hardware which causes your server-side scripts to take too long to answer. For example if you have an autocomplete field and the script goes through a database of 100,000 entries, this is a breeze for newer servers but older "budget" servers or overcrowded shared hosting servers might croak on it.
Depending on what your Ajax operations are, you may be able to break them down in shorter chunks. If you're doing database queries for example, use LIMIT and OFFSET and only return say, 5 entries at a time. When those 5 entries arrive on the client, make another Ajax call for 5 more, so from the user's point of view the entries will keep coming in and it will look fluid (instead of waiting 30s and possibly timing out before they see all entries at once). If you do this make sure you display a spiffy web 2.0 turning wheel to let the user know if they should be waiting some more or if it's done.