When I started developing with Symfony on Windows it worked pretty well at first, but lately the profiler is taking way too long to load the toolbar.
The profiler is taking 18.48 seconds to load (day:116).
I didn't find anything helpful online, does anyone know what might be causing this?
Ok, this is super weird, but after I did a JSON request (that returns a JsonResponse) everything turned back to normal. I have no idea why this had an effect at all, since this problem persisted over hours and server restarts did nothing. Anyway, I hope this might help someone else in the future.
Edit: The problem returned after a while, and there didn't seem to be any fix. I was using XAMPP on Windows 10 with Xdebug, APCu and OPcache. My hardware was definitely not the problem, I was running the server on a really beefy machine.
Kind of fix for people with the same problem:
I started using a Ubuntu VM, and it never happens there, even though I use the exact same code and server setup aside from the OS.
Related
I've been experiencing an odd issue where something is getting cached somewhere and I'm not sure which item to blame and it's not only driving me nuts, but slows down my development workflow (and is VERY confusing).
The Problem: I save changes made to a PHP file and refresh my browser, however the changes do not show up.
Expected Behavior: The refreshed browser shows the updated file.
Actual Behavior: The most recent changes do not show up.
For some background, here are the possible factors that could be contributing to this problem:
Macbook Pro (16-inch, 2019, 2.6 GHz 6-Core Intel Core i7)
Mac OS (Monterey v12.5)
Chrome (v104.0.5112.79)
MAMP Pro (6.6 Build 33836), Apache (2.4.46), PHP (7.4.21), MySQL (5.7.34)
Xdebug
PhpStorm (2022.2 Build #PS-222.3345.135)
Gulp (v4.0.2) - Unlikely
BrowserSync (v2.26.14) - Unlikely
I work with WordPress although I don't think that's a factor here. Basically what is happening is I'll go to make a change to a PHP file, which could be just adding more code, fixing an error, or maybe even doing a var_dump, and when BrowserSync refreshes, the changes are not reflected, so the new code does nothing, or the error still exists, or the var_dump doesn't show up. Another example is once var_dump does work, if I go to remove that debugging line, it will still show up.
I haven't figured out a fix either, other than just repeatedly refreshing the browser or re-saving the file (sometimes after adding a few blank lines to "trick" whatever it is causing it to think the file has not been changed). This can happen with or without running Gulp/BrowserSync, but I don't want to rule this out as a potential part of the problem. It's behaving like the file has not been saved.
I sometimes will quit gulp and restart to see if that resolves the issue, although it's hard to tell if it has any effect since the problem persists for maybe 30 seconds and then I'm able to see the updated file.
This is something that has recently started to happen but doesn't happen consistently. Sometimes everything works as expected, but it's hard to tell what factors are contributing to when the issue starts happening again. Most recently it started again after I restarted PhpStorm (to apply an update).
Has anyone else experienced something like this? I'm not even sure what other information would be helpful, but would be happy to post more details if I'm missing something. Thanks!
I'm building a website using the FuelPHP framework, which by default prints the execution time and memory usage at the bottom of the page. Now I just noticed that on my local machine, I have a pretty small memory footprint:
Page rendered in 0.0304s using 0.721mb of memory.
I deployed exactly this site (including a snapshot of the database) to my remote test server and suddenly memory usage increases by a factor of 10:
Page rendered in 0.0963s using 7.099mb of memory.
I cannot explain such a big difference from the details of execution alone, so I think the deviation must be in the environment.
Unfortunately I'm mainly a programmer, not really a server admin, so I don't really know where to start looking. So I'm going to ask a bit of a general question, which will hopefully give me some useful pointers: where should I start looking? The code is exactly the same and as far as I am aware both machines (local laptop and remote server) are fairly standard Apache installations with PHP5. Any answers suggesting specific Apache or PHP settings that might cause this, or specific lines to search for in the logs, are welcome.
I realise this is a pretty general question that might get me some downvotes, any constructive critisism is welcomed instead. Basically, I'm at a loss where to even start looking, at the moment.
Update: I decided to first exclude the framework as the culprit, so I ran the following one-line script on both machines:
Locally I get a value of about 115, while the remote server reports about 600.
Update 2: Just noticed I'm running PHP5.5 locally but server is only at 5.3. Maybe some bug that got fixed later - will upgrade that first.
Thanks for the suggestions guys, I fixed the problem.
As noted in the update to the original post, I realised I was running PHP5.5 locally but server was only at 5.3. After some ppa-magic with apt and some help from other questions on SO I managed to install Apache 2.4 with PHP 5.5.x. Now I actually see
Page rendered in 0.0261s using 0.582mb of memory.
locally and remotely
Page rendered in 2.3184s using 1.238mb of memory.
Assuming that a factor 2 is caused by the server being 64-bit and not my development machine, I can live with the remaining difference.
Use Xdebug to find out what functions are using all your memory.
Most likely it's a bug or design flaw in the framework.
It can be difficult or even impossible to get Xdebug working depending on your server. But sometimes it's pre-installed and simple.
I'm trying to speed up my wordpress site because for some reason it's taking on average 5 seconds to load a page (obviously way too slow). I've tracked it down to the php-cgi.exe hogging an incredibly large amount of cpu time, but now have no idea how to figure out why or how to fix it. Any ideas how I could debug the php-cgi.exe and figure out what is slowing it down?
PHP itself should definitely not be doing that. Are you sure it is PHP, and not the script you are running?
Try a simple Hello World script and see if you notice the same behavior:
<?php echo "Yellow World"; ?>
If you do, try calling it from the command line and see if you have the same problem:
php.exe helloworld.php
If the CLI version executes nice and fast, but the web based one doesn't, you can begin digging into the trouble between your web server and PHP.
Finally, check and make sure a broken or misconfigured extension isn't hanging things up. Remove all extensions you don't need. If you still have trouble, remove them all and add them back in one by one.
Switched to a shared Linux server. All of a sudden everything works without a hitch... start microsoft bashing... now.
We have a server at my work with APC installed on it, and about every 1-2 weeks, all of a sudden this error just starts being thrown and when it is throw it happens a lot. It will be perfectly fine for the whole of the 1-2 weeks, and then it just blows up. The only thing I've figured out to do to stop the errors is to restart apache. The website seems to work fine while this is happening, but I am worried that if I don't restart apache the server it will eventually start to become unstable and start behaving erratically.
When I search for this on Google I found one page that was sort of useful (a PECL bug), and a bunch of pages that were indexed while they were having this error.
I would love to solve this warning or at least figure out more about what the problem is. Thanks for your time!
P.S. The server hosts a few sites and a couple of those sites are using expression engine. Other than that it is pretty much your normal LAMP setup.
We're currently running with php 5.2.5. We have now encountered a bug that creates a seg fault. Our first idea at the solution is upgrading to version 5.2.6 but are skeptical of problems that it will create. We are running Apache and host a dozen or so sites.
Will any existing code break?
Are there any significant changes to be aware of. I was reading the change log but didn't notice any.
Is it easy to revert back to 5.2.5 if something goes wrong?
Anything else to be aware of?
It's impossible for any of us to say definitely yes or no about your existing code breaking without performing an analysis on it first.
This is exactly what test environments are for. If you have a test environment set up, you can perform the upgrade, then do regression testing to see if anything breaks. Without this environment, you're making a gamble.
#Grant Wagner: Great point on virtualization. Setting up a good test environment doesn't have to be difficult.
With modern Virtual Machine options VMware Server, Microsft Virtual Server, Microsoft Virtual PC and others, why not set up a virtual environment running your existing platform, then upgrade and test that?
If you are willing to spend money, you can buy tools to do P2V (Physical-to-Virtual) that will take your existing setup and provide you with a virtualized copy of it (this could be valuable if you've done a lot of customization to the configuration that might be difficult to produce to a virtualized version that matches the original well enough to do proper testing).
Most likely not. The jump from 5.2.5 to 5.2.6 is small, it is a bug-fix release (see the changelog).
But whenever upgrading anything, make sure to test your code in a dev environment before putting it into production.
As everyone is saying, only testing will tell you for sure. However, minor version updates like this will only rarely cause compatibility problems.
For what it's worth, here are the change notes.
In the long run though, you will have to upgrade at some point or risk being exposed to known security vulnerabilities.
Thanks for everyone's input. Getting a test server is definitely on the road map. This should be a good argument for finally getting one setup. We're a small enough company where we could easily get away with only having one, but there are so many advantages to having a test server.
Unfortunately it will be hard to get this project moving forward without upgrading and i doubt there will be time for a test environment.