Limiting web-profiler-toolbar AJAX request count #20155
Comments
|
I think that JS could be optimized a little. I think it should append new rows to the table as opposed to re-creating the whole thing. |
|
@marceldeglau I haven't had a chance to test this yet, but here's my attempt at fixing this up. The gist wouldn't let me save with slashes in the file name, so if you convert the tildes to directory separators, that should be the file you need to create to overwrite this. I'm hoping to test the changes tomorrow and if it's good I'll open a PR, but if you have a chance to test it, I would love to have another set of eyes on it. |
|
@patrick-mcdougle Thank you for your gist. I've not tested it long time, only for any minutes. The layout is a little bit "buggy" also the requests are added to the wrong direction. Also I think this will produce the same issue: After long times of requests 3.000+ requests the page will get very slow and buggy. I think the best way will be to add a configuration to limit the displayed requests, for example the 501. request is done, the first entry (1. request) should be remove from the HTML. Additional node: I've tested my idea, by removing the request using a own jQuery script, after removing the whole page is going speed up well! |
|
Limiting the max number of requests shown makes sense. I would not make it configurable though. 500 requests is already a lot and nobody is going to browse just a long list anyway. So, let's find a number that works well performance wise and that still gives enough information to the developer. |
|
@fabpot Thanks for your comment. I'll think this is the best way! +1 Sure 500 requests are very much. I mean 200 up to 150 requests are complete enough for debugging. Note: Perhaps also we can add a button or link for stop to count requests in the profiler? |
|
@marceldeglau The layout is "buggy" because of #19576 where they added a new column. I'll bet you're not on master and don't have the column yet. I truly believe that the performance problem has nothing to do with the number of requests, but rather the inefficient way we're re-constructing that section of the DOM on each request. Working on taking another stab at it now. If I can't get it to perform well, I'll limit it to 200 requests (seems like a meaningful number for ajax requests). Yes that's a HTTP joke. |
|
@marceldeglau Gist updated. I basically re-wrote all the rendering code to be more smart. I personally think the resulting code is more clear, but I'm biased. I also removed the type column so it would work with your version of symfony. |
|
@patrick-mcdougle Thanks for your work, but it isn't working for me: http://i.imgur.com/lDyenWn.png |
|
@marceldeglau doh. Back porting this to 3.1 from master is giving me trouble. I'll come back to this in an hour or so. |
|
@patrick-mcdougle @fabpot I think the best way is to add it to 3.2 version. It's currently not a "immediately" issue. |
|
@marceldeglau Try one more time. I was so close. Gist updated. |
|
I'll be targeting the PR to master, but I wanted to make sure it solves your performance issue before I bother opening the PR. |
|
@patrick-mcdougle Thanks! I#ve testes over 2.000 calls, and it seems to be stable. No lags or other issues. Thank you very much for your awesome work dude! |
|
I think having an arbitrary limit is confusing and unneeded if the performance problem can be fixed. People might assume the bottom request is the first one when it's the 200-ago one. |
|
I agree |
|
@patrick-mcdougle I've tested it again with over 5.500 calls. The page is going fine, but when I mouse-over the requests, the complete browser will lag and freeze for any seconds. I think there are too many requests they've stored in HTML. It will be the best, we add a limit for the requests they are shown in the hover card. (Referencing to @fabpot comment)... |
… (javascript) (patrick-mcdougle) This PR was squashed before being merged into the 3.3-dev branch (closes #20197). Discussion ---------- [WebProfilerBundle] Improve Ajax Profiling Performance (javascript) | Q | A | | --- | --- | | Branch? | master | | Bug fix? | kinda (is bad performance a bug?) | | New feature? | kinda (is increased performance a feature?) | | BC breaks? | no (unless performance is a BC break) | | Deprecations? | no | | Tests pass? | do we have JS tests? | | Fixed tickets | #20155 | | License | MIT | | Doc PR | n/a | The old version of this JS re-rendered the entire list of ajax calls which was causing some performance issues when people had high numbers of ajax requests (increasingly common as people create SPAs. This PR changes the behavior of the ajax profiler to be more smart about the DOM manipulations it makes. Instead of re-rendering the entire list, on any AJAX requests/responses, it instead adds the row to the profiler when an AJAX request is made, adding the DOM node as a property of the request on the requestStack. When the AJAX response comes back, it updates the existing DOM node instead of re-creating it (and all of the others). I've tested this on my machine using a modern version of chrome. I don't think I'm doing anything fancy, so I think the likelihood that I broke something is minimal. I've left a couple of the commits separate, because they represent distinct ideas. The first commit is just some consistency/cleanup. The second commit is the meat of the work. Its diff is basically useless since I've added two new functions and modified one function heavily. I tried to make the diff as easy to read as possible, but it's still pretty rough. The third commit removes some functions/calls that I don't think need to be there now that this is re-written, but I wanted to leave them in a separate commit for ease of revert if they are indeed needed. Commits ------- 65e391c Replace occurances of querySelectorAll with querySelector fddff26 Put back the indentation 9942edd Remove unnecessary method calls/definitions 2c053ee Rewrite ajax profiling for performance da621c9 Fix indentation & JS Cleanup
…ormance (javascript) (patrick-mcdougle) This PR was squashed before being merged into the 3.3-dev branch (closes symfony#20197). Discussion ---------- [WebProfilerBundle] Improve Ajax Profiling Performance (javascript) | Q | A | | --- | --- | | Branch? | master | | Bug fix? | kinda (is bad performance a bug?) | | New feature? | kinda (is increased performance a feature?) | | BC breaks? | no (unless performance is a BC break) | | Deprecations? | no | | Tests pass? | do we have JS tests? | | Fixed tickets | symfony#20155 | | License | MIT | | Doc PR | n/a | The old version of this JS re-rendered the entire list of ajax calls which was causing some performance issues when people had high numbers of ajax requests (increasingly common as people create SPAs. This PR changes the behavior of the ajax profiler to be more smart about the DOM manipulations it makes. Instead of re-rendering the entire list, on any AJAX requests/responses, it instead adds the row to the profiler when an AJAX request is made, adding the DOM node as a property of the request on the requestStack. When the AJAX response comes back, it updates the existing DOM node instead of re-creating it (and all of the others). I've tested this on my machine using a modern version of chrome. I don't think I'm doing anything fancy, so I think the likelihood that I broke something is minimal. I've left a couple of the commits separate, because they represent distinct ideas. The first commit is just some consistency/cleanup. The second commit is the meat of the work. Its diff is basically useless since I've added two new functions and modified one function heavily. I tried to make the diff as easy to read as possible, but it's still pretty rough. The third commit removes some functions/calls that I don't think need to be there now that this is re-written, but I wanted to leave them in a separate commit for ease of revert if they are indeed needed. Commits ------- 65e391c Replace occurances of querySelectorAll with querySelector fddff26 Put back the indentation 9942edd Remove unnecessary method calls/definitions 2c053ee Rewrite ajax profiling for performance da621c9 Fix indentation & JS Cleanup
I having some trouble with the web-profiler-toolbar. We have a lot of AJAX requests in our application, any time the request count is going higher than 500 past requests the web page is going very slow and laggy.
So is there any method to limiting the counted request, for example: Are 500 requests done, delete one of the latest and add the current (new) request. So the AJAX request count is limited to an special number.
When there is no function for this, see this issue as an very helpful feature request.
The text was updated successfully, but these errors were encountered: