I just made a strange observation in my windows 10 based symfony installation.
I always got rather dissapointing response times, so I wanted to use the profiler to check for reasons.
I found one interesting deviation immediately: Although the profiler sums the totals to about 1000 ms, the browser shows that the TTFB is about 5800ms?
My public\index.php is the same as
https://github.com/symfony/recipes/blob/master/symfony/framework-bundle/4.4/public/index.php
And here is the thing: When I put an exit() right after $kernel->terminate($request, $response); my browsers TTFB is suddenly at 1600ms!!!
This is mind blowing, cause I always thought nothing happens after the last line in index.php?
Can someone explain, why my symfony route calls are blocked for SECONDS after they are ready?
Turns out that this delay must have to do something with xdebug enabled in my php.ini, while the IDE (VS CODE in my example) was not running the debugger.
When I turn on debugging in the IDE (and I remove all breakpoints) the TTFB is as short as with the exit() in place.
When I switch off Xdebug, it is the same.
I think xdebug trying to communicate with the IDE (and not succeeding) must block the HTTP Response for the additional 2 - 3 seconds.
Related
Fresh installation - plugins disabled, no malware. Chromium runs without delays. Firefox on every other action, including typing every now and then - takes 3-5 second pauses, sometimes displays a running wheel when the delay is even longer.
Started at certain point in time. De-installation/re-installation didn't cure. Running as a single process didn't cure. Latest version.
Any ideas what can be causing this, specifically for the Firefox?
Upgrade to v67 - I remember reading some glitch has been removed in prior versions that might have been causing this behavior.
Also, another idea would be not to limit your cache to a very low space.
+1 to move this question to SuperUser.
I'm developing a web app running on WildFly 8.2 and I'm experiencing annoying UI responsiveness lags that I do know how to pinpoint. The lags occur shortly after loading a new page - they last about 3-4 seconds during which all UI is not responsive (such as hovering does not have effect, you cannot close the window or open DevTools)
I considered the following aspects:
code-related - angular, animations, kendo, less.js, not optimized selectors or iterators in my code, etc. Disproved - I rolled back to a very early version where I had never observed the problem (so to eliminate a hidden impact of newly introduced features), and the problem was there too.
CPU-related - restarted afresh many a time, running no extra apps - no go.
server-related
browser-related - disabled extensions and hardware acceleration setting - disproved. Chrome/FF usually silently choke, sometimes asking whether to close unresponsive page, IE complains about script, but when I choose to Debug the script, all I get is being directed to random script.
The key test however was to view my local deployment over LAN from other desktops - the app performed sluggishly regardless, whereas the same app (same code, same branch revision) deployed locally on those desktops performed superbly.
So this proved this is more server- or CPU related stuff. The app ran fine on WildFly 8.0. When the problem started to bite, I upgraded to 8.2 but it does not seem to have any effect.
As I'm running out of ideas, does anyone seem to have a hint what to do/check next?
Last minute: I went along the advice from here http://www.tomshardware.co.uk/forum/1843-73-windows-slow-browsing-chrome-firefox-faster and turned off Windows Defender's real-time protection - nothing got better.
The problem was caused by invisible content (shown on request in a modal) that grew up to 5000+ table rows and was employing angular binding (ng-repeat a.o.). Thanks for your hints.
I use PHPStorm 5.0.2 for debugging php/mysql projects with WAMP framework (php 5.3.1, Apache 2.2.9, mysql 5.5.24 on Windows 7 platform).
Question 1: Some times in a project, when watch debug variables are used, they take some seconds to refresh on the debug panel, after each code step. Each watch variable takes a few seconds to refresh, so the more watches have been defined, the more slowing down takes place during code stepping, rendering debugging disappointedly slow. So, for example, I cannot press 'Step over' every second, because I have to wait till watch values are refreshed, before I press the next 'Step over' and this may take 5 or more seconds.
This didn't use to happen before, it started happening lately and also it doesn't happen all the time. When it doesn't happen, the code stepping can advance very quickly, as it usually did.
In this project I have set up quite a few breakpoints, so I was wondering if they are the culprit. I tried to disable most of them (not delete them, since I need to keep them for future use), but I didn't see any improvement.
I also tried different xdebug versions, but no change took place.
I have also tried to switch browsers, delete browser data (cache, etc), restart WAMP server, browser, phpStorm, even Windows, but many times the issue remains. Other times, it disappears for a little while and it reappears later in the code.
I was wondering what reasons might produce this slow refresh.
Question 2: Is there any way to export or save breakpoints from a project?
Question 3: If I tried PHPStorm 7, in case this slow-refresh issue disappeared, could I open the PHPStorm 5 project in order to not loose the breakpoints I have already set?
So the times you see is an example of typical development. You fire up your server and mysql database, then login to the backend and try to add a simple thing like a menu item.
The times shown are only for the server to start responding, not for the page to actually finish loading. So this is time, passing on the server in the code, executing queries etc. All the JS files and CSS is not part of this measurement.
I can keep going. Clicking on "New Menu Item" and Hitting "Save" will take just as long.
So for a simple thing like adding a menu item the user spends roughly a minute looking at a blank screen (assuming the user knows joomla by heart and makes no wrong clicks and thus never has to go back).
Caching
So I read about caching. If you enable Page Caching I cannot keep developing because it seems my changes are not getting refreshed, and you really want this feature when you develop.
The View Caching actually speeds up the backend and the frontend a lot. But you still have to access the page once slowly before it gets cashed, and you have to access it again in the timeframe of the existence of the cash to profit from it. So for me, this means the backend is basically always slow. Unless I try to do something like adding 10 menu items within 15 minutes.
I btw run on a brand new notebook which really should not be the problem.
Is there something I am missing out on?
Is this actually normal?
EDIT
I could improve my times to around 2 seconds. The profile shows a lot of red colors though, someone has an idea? The picture is for the view menu manager, main menu menu items.
My times are all below 2 seconds, usually approx 1 both on my development server (a VM running CentOS 6 in virtualbox hosted by a Win7, i7 / 6Gb RAM / SSD disk) and my production server (Xeon dual 2GHz / 4Gb / 10000 rpm SATA disks).
Enable the debug for your site and see in the bottom of the page the times each module / component / event takes to run, this will make it possible to determine if it's a single extension / piece of Joomla eating up all the time, or it's just your machine.
I don't have a particularly good local machine (just a cheap W8 and using EasyPHP) and my times are all much faster than wither yours or those other people are reporting. One of the things you can do is turn on debug and look at the profiling data. When I load the admin login page even with debug on I can see it's onAfterDispatch which is the slowest part of the process.
A lot of times upgrading MySQL will give massive speed improvements.
When working on a localhost, the loading time usually depend on the PC performance. I work a hellish amount of time using wampserver (localhost) at work and on my computer at home.
When installing a fresh copy of Joomla 3.2 on Wamp at home, the step to create the database and insert the default content takes around 7-9 seconds, where as at work, it literally takes under 2 seconds. The reason? Because my work computer performance is much better than my personal computer.
It's the same concept for loading pages in the backend.
Hope this bit of info helped you.
I'm currently learning OpenGL and I've noticed a rarely occuring performance problem:
My program is rather small so it's not a performance problem with the code itself, but when I'm running the code via Visual Studio I sometimes only get 1-2 FPS instead of the usual 60.
Once this happens I can restart the program as often as I want to (in debug and release mode alike) and it won't go away.
However, when I close my Firefox (or manually shut down the plugin-container.exe though task manager) and restart my program everything is fine again. After that I can start Firefox again (with the same tabs open) and the bug does not reappear.
I use the newest version of Firefox, and I've had this bug with several programs already - both made by me and others and using different versions of OpenGL. However I don't think I've had this problem when starting a compiled exe directly, but only by using the Run feature of Visual Studio.
I've searched the web but I only found a link about the generally bad performance of this plugin-container.
Does anyone else have this problem? Do you know any walkarounds or fixes?
PS: Regarding isti_spl's answer:
The CPU utilisation of the plugin-container.exe jumps to the 50% limit when the problem happens.
I'm working with Visual Studio, but the problem only occurs when I also have Firefox running (it most certainly is because of this plugin-container, so it probably won't happen with other browsers).
It's hard to isolate the problem because I can't replicate it. It might happen 1 out of 50 times.
I'll see if closing flash-related tabs (youtube, blip.tv etc) fixes the problem next time it happens.
Can you isolate the problem?
You first mentioned running visual studio then firefox. Please try to run separately.
Under FF. is it caused by WebGL or flash plugin? Is it caused by visiting specific sites?
Is it FF specific or happens under other browsers too?
Does CPU utilisation jump high? Please verify that too and which process consumes most CPU.
Not sure, but likely gpu driver + flash problems.
If so, the problem is not in your code, other GL program should be affected too.