I've been trying to see a way to get a measure of how much a PHP script costs of memory to the server. Well, I've found some solutions out there that requires some software to make tests and even require to install something on the server. Those solutions are not what I'm looking for, as I just want a simple measure of the consumption.

My try was to do the following:

     $initialMem = memory_get_usage();
     /* Script comes here */
     $finalMem = memory_get_usage();
     echo ($finalMem - $initialMem)/1024 . " Kbytes";

Where I divided by 1024 to convert from bytes to kilobytes. The idea was that the function memory_get_usage() gets the amount of memory allocated for the execution of the script and so I thought that taking the difference would be a good measure of the usage.

Is this correct? Is the difference between those values a good measure of the usage of memory by the script? If not, how can I get a good measure of this usage without having to install anything on the server?


It doesn't matter how much memory PHP is using. As long as there is enough allocated.

PHP runs in a sandbox inside a webserver. The sandbox is allocated a chunk of memory for use by PHP, and when you hit that limit then PHP throws an out of memory exception. You have to either increase the limit in php.ini or change your code.

PHP scripts do not remain executing after a request is made. The script is terminated and the output buffer is sent to the browser. Your sample source code will only tell you how much memory was used for that HTTP request. The amount of memory used by PHP will change depending upon how many concurrent requests are made to the server, and what that server is configured to handle.

I think the default chunk of memory for PHP is 64MB, but I run mine at 2BG because I have command line cron jobs that are very memory hungry.

How much memory PHP uses is peak = 64MB * concurrent requests.

  • Probably not worth noting (obvious per the details); but this assumes the script isn't run from the command line and/or a cron job, correct? That is, if you fire up the PHP CLI, you're not sharing memory with mod_php, are you? – svidgen Jul 31 '13 at 22:09
  • Thanks for the help @MathewFoscarini, I think I wrote in a little confusing way. What I really wanted to know was the memory used for that request. So in that case, this code works for that? The other answer says that if there are unsets (and there really are some of them) I should use $finalMem = memory_get_peak_usage(), using this will also return me a measure of the memory used for that request? Thanks very much again! – user1620696 Jul 31 '13 at 22:20
  • @user1620696 yea you should be good with that. – Reactgular Jul 31 '13 at 22:30
  • 2
    You can increase the memory_limit programmatically via ini_set. So, you don't have to increase it for large jobs (they can increase it for themselves), and you can't rely on the formula described above when using third-party PHP apps unless you've verified they don't modify the memory limit. – Joeri Sebrechts Aug 1 '13 at 11:11

If your script contains any unset()'s or objects that otherwise perform cleanup during execution, your script could be hogging more memory during execution that you'll see reported. I think you want your final measurement to be peak usage:

 $initialMem = memory_get_usage();
 /* Script comes here */
 $finalMem = memory_get_peak_usage();
 echo ($finalMem - $initialMem)/1024 . " Kbytes";

Also, the $finalMem in this scenario is relevant only in optimizing your code. If you're trying to assess the script's impact on overall system performance (sounds like you do), you need to account for PHP's overhead. In that case, you don't need to compute a delta; just report the peak usage at script end.

  • one doubt yet. I did what you've said and used peak usage instead because of some unsets. The only thing is that using the normal memory_get_usage() the difference between the consumption between the old script and the new was big (25% approximately) while with peak usage the difference is really small (just 2kb). The unsets do not optimze the code then? You know where I can find more about optimizing the speed of the script? Thanks for your help! – user1620696 Jul 31 '13 at 22:37
  • @user1620696 if you want to optimise for speed, then don't unset(). The garbage collector will do it for you when it needs to or when the script ends. Think memory vs speed trade off. – imel96 Jul 31 '13 at 22:56
  • @imel96, I've removed the unsets. Can you point me some article that talks more about optimizing for speed and about testing the performance? I've made many changes to my script, removed extra variables, unecessary code and so on, but by this test with memory_get_peak_usage() the impact on performance was very small. Thanks for the help! – user1620696 Jul 31 '13 at 22:59
  • @user1620696 I think you should edit your question or post a new more specific one stating what you're trying to achieve. You're already on the right path by profiling how your code run. In this case you show how the script is using memory. If you want speed then don't worry about memory usage, instead, you should just replace your memory_get_usage() with microtime() to measure time. But doing it that way is not very efficient. There are tools like wincachegrind that does better job. Once you know how your script runs, usually you can just take it from there yourself. – imel96 Jul 31 '13 at 23:54
  • @user1620696 unset only marks data as available for garbage collection, but will not be collected if PHP doesn't need more memory. It's a performance hit to free memory. Only use unset to remote things from arrays or you have logic that tests for variables that are set. With the exception to large chunks of things processed in a loop (like images or datasets). Unset will automatically happen when a variable goes out of scope. – Reactgular Aug 1 '13 at 10:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.