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.
Related
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.
At work i want to upgrade our system to PHP7. It is currently at PHP5.6.
We have a different folder structure, as we have all our code in the /home/user directory.
I am not a server guy, i only code. But i know some linux basics.
I came across phpbrew. Is it safe for me to use? as we have a different folder structure then most have.
I dont want to mess up my development server, so it is important for me that i can switch back to 5.6. The server is running debian 8 and we use apache2.
I also came across this article:
https://lornajane.net/posts/2016/php-7-0-and-5-6-on-ubuntu
Is this a safe way to do what i want?
Any other suggestions are also welcome!
Thanks in advance!
The process described in that link looks plausible. Possibly other online resources might confirm it. Why not make a quick VM and try it out?
Is your current dev server a VM? You could clone it, then make the changes and run both in parallel. If not, you could shut it down briefly, image it, and then use the image to build a VM or another physical box.
That way you've got any custom server setup copied across reliably with minimal effort, and you can test PHP7 along with that stuff, with no risk to the current environment. That would be my advice.
I have an ubuntu server that I've setup with PHP7 and nginx. It's running a Laravel application, and this runs on AWS. The MySQL DB is on RDS.
I've provisioned this server using Ansible. It's a pretty straightforward configuration. I have opcache enabled and ample php child processes. I also installed mysql-client to interface with RDS.
The issue: prior to provisioning this box, I was using a pre-provisioned box (from Laravel Forge). My new box seems to be MANY times slower than the pre-made box I previously used (5 to 8x slower!)
I've compared the settings between the two boxes and they are more or less the same, so I can't really figure out what would be causing this.
An example is: if I benchmark a particular piece of code on one of the more taxing endpoints, the actual sql queries are fast in both cases, but the new box seems to take an incredible amount of time populating the objects in Laravel, or maybe the application is getting queued up to wait for the database connection. It's hard to say. But the old box takes 50ms and the new one takes 1200ms.
My question is: what sorts of places should I be looking to find this issue, which seems to be in the server configuration? From what I can see, nginx and php seem properly configured. The issue happens when there's zero traffic, so I don't think it's a scaling problem. I'm wondering if there's some mysql-client configuration, or some mysql-php configuration that I could be overlooking. Any suggestions, or tools for debugging something like this would be appreciated.
There is a PHP application right now on a Linux box running under Apache with MySQL. Since we are a windows shop, management wants to get rid of the Linux box and move everything over to windows. Is there a performance difference between the two platforms? Or, is there any significant difference at all, in terms of performance or management?
Microsoft had a team help out optimising PHP for Windows, which work is part of PHP 5.3. Some figures I've seen places the performance close to PHP + Apache on a unix system. Before 5.3 (Which means currently, since 5.3 isn't out yet), performance is bad on Windows. I think there are some patches and tricks you can pull to improve it, but it's going to cost you a bit of performance. That may or may not be a problem; People have a tendency to overestimate performance.
Note that there are other reasons to use unix than just performance. Code may not be portable and even though the core php runs fairly ok, you can well get into trouble with php-extensions and third party libraries. No matter how you look at it, Windows is a second-rate system for running php on.
If your application isn't huge or get hit a couple thousand times per second, there's no difference between the two.
LAMP == WAMP in php small projects. Just install something like XAMPP if you want your environment to be as close as possible to your existing one but in Windows.
Good luck with your project!
You should consider the MS WebPI (download at www.microsoft.com/web ) which would install the entire stack for you to run PHP in IIS7 environment.
the performance is comparable for most apps.
I've just done this for the same reason. Mgt wanted to get rid of the Linux box. I was able to completely move my php application and MySQL database. It took longer for me to configure PHP for IIS than it did for me to move the existing content over.
I have found though that the IIS server is a fair bit slower when it comes to loading pages and images. Where in Linux it appeared instantaneous, in IIS it takes a half second for the page to load and another second for images.
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.