I've spent hours googling, as well as searching the Apache site, and I can't find any documentation about how Apache handles file uploads — particularly large ones. I've read anecdotal reports that PHP isn't involved until the upload is complete, which is what I'd expect. But as far as what Apache does during the upload, I can't find anything.
The reason I'm hot for documentation is that Apache is storing uploads entirely in memory, instead of streaming them to disk. httpd will use every byte of available memory on the server I'm using until it crashes. Typically the amount of physical memory consumed is 3x the size of the file being uploaded, and increases in the vicinity of 5 MB/s (nowhere near my upload speed).
I've tested this same request on another LAMP stack I'm using, and Apache memory usage doesn't change at all throughout the course of the upload.
Can anyone explain to me how Apache could handle the same upload so differently on two different servers? Any thought greatly appreciated.
Technically, PHP is handling the upload on behalf of Apache, and buffering the file in ram until it completes. However, your script will not gain control until after the upload completes (or aborts). Apache by itself won't buffer out to disk unless it has to. Think of it as an invisible "handle_upload()" function call that's transparently inserted as the very first thing in your script.
Back in the "everything is a cgi script" days when language interpreters like PHP weren't embedded in the webserver process, POST data was sent to the CGI script via standard input The file would pass through Apache directly to the CGI process and could be read byte-by-byte as it came in.
The answer is unsatisfying. I never found any documentation.
I continued poking around in the dark, finally stumbling on a mod_fcgid upgrade (from 2.2 to 2.3.6) that did the trick. Perhaps there was a bug in 2.2.
The memory usage still goes up in 2.3.6, but far less dramatically. Only a few megabytes for a ~100 MB file. (However, when the upload finishes and the file is moved, memory usage instantly shoots up ~100-200 MB, but then seems to be immediately released.)
This might help you, because the WAMP server has Apache in it.
http://www.wampserver.com/phorum/read.php?2,39439
Related
I develop a web server's PHP scripts to retrieve tiled images to cover Earth surfaces such as World Wind.
Suppose I have get_image.php that returns image/jpeg or image/png as the response.
The initial condition is also that I have Windows Server 2003 to test my script on and preinstalled Apache 2.2.16 with a thread model. So I had to install thread safe PHP 5.3 to use it as Apache's module.
After script has been succesfully written I decided to produce a load testing using JMeter. Starting with a single virtual user performing a request per no more than 0.5 seconds and increasing the number of virtual users every minute at the moment of nine virtual users I get some not handled requests though looking in server's Task Manager I see no more than 8-10% of CPU. The maximum performance I get is 1600-1700 successful responses per a minute (requests are produced by eight virtual users).
I am not a system administrator and not experienced dealing with heavy performances, so my question is: can this be a problem of PHP thread safety discussed here? How can I determine the problem I face? Would it be better to try my script as CGI with IIS + FastCGI or we have to look at Linux-based web server?
P.S. I also use memcached server and php_memcache.dll (so-called thread safe version) downloaded from http://downloads.php.net/pierre. This module is not officially supported for Windows and probably it's not really thread safe so it could cause an additional effect to my problem in the case of the problem described is PHP thread safe issue.
If I were you I would use XDebug to track down which parts of your application ar eating the time and causing the failed requests.
Since you are on windows ( i presume ) then you can use a handy little program called WinCacheGrind to open and review the output files. It will show you, line by line or function by function, exactly how long the different blocks of code in your application take to run.
If you find that there is nothing surprising in the grind then that is the time to start looking at the environment.
I've got 2 servers: my local server and remote production server. They've got basically the same config: Ubuntu 10.10, Apache 2, PHP 5.3, PHP-APC, MYsql etc. I also have copies of a webapp on both servers and here's the problem with PHP:
On my local server webapp uses only ~4 MB of memory, but on my production server memory usage spikes up to 50 MB of memory for no good reason. I tried to run memory_get_peak_usage() function to get memory usage at different stages of webapp execution and i've found that on production server memory spikes from 0.7 up to 49 MB on such function calls as class_exists().
What could be the problem?
Tanks.
Hate to sound a bore, but have you verified that they have exactly the same Apache/PHP config as they can easily become the source of these sort of differences..
Also are they experiencing the same sort of load, as code running on a server under load can behave very differently to code running with ample uncontested resources.
Are there any other differences in terms of other running applications that could be affecting stuff?
It maybe worth profiling the code on both the servers to see if there are any per-request differences, XHprof[1] is a great tool for this and it can safely be run in production (as long as you read the instructions)
[1] http://phpadvent.org/2010/profiling-with-xhgui-by-paul-reinheimer
Ok, i've found where was a problem. There is a class that was creating cache file containing information on user's browser (in order to recognize them later). Apparently there was a problem with that file and/or parser so it was using too much memory. Since then i've cleared cache files and if situation will repeat, i'll ditch that class altogether.
Thanks to all who answered/commented on problem.
I set memory_limit to -1 . Still i am getting out of memory issues.
I am working with a legacy system, which is poorly coded ( :) ). I ran apache benchmark to check the concurrent user access to the system
ab -n2000 -c100 http://......com/
In the log file i see so many memory related issues.
In the code they use object buffering. This can be the issue ?. Is object buffering is related to memory_limit ?
Changing the memory limit on PHP stops it being killed when it goes past a certain value. However, it does NOT physically give your hardware more memory (or swap). Ultimately, if it needs memory which you don't physically have then things will break.
Object buffering in PHP : I don't know what it means, if you mean Output buffering with ob_start and ob_stop it is not related to object buffering and has not really an impact on memory usage of PHP.
Memory usage of PHP depends on the size of created objects while you build the response of the request. If you perform several times the same request the memory usage of each php execution should be the same.
With a 'no limit' on memory usage the only thing you do is avoiding a request crash because of too much memory usage. That mean if your problem is memory usage on your index page you can easily test it by setting some values in this setting, and decrease until it crash (64Mo, 32Mo, 16Mo, 8Mo, etc). You do not need ab for that.
Now, when you're using ab you make your apache server respond to several parallel requests. For each PHP request you have a new apache process created. And this new apache process will execute an independant PHP-thing, and it will take the same amount of memory as the others process doing the same thing (as you request the same page, and nothing is shared between different PHP execution, and each PHP execution is done in one apache process).
I assume you're using apache with mpm_prefork and mod_php, not any php-fpm or fastcgi php.
So If you have a memory problem in that situation it's maybe that you allow too much process for apache. By default it's 150, if each process takes 30Mb of RAM (check that with top) then it makes 30*150=4.3Go. See the problem?
3 easy solutions
decrease the number of apache process (MaxClients), and set the MinSpareServer, MaxSpareServer and StartServer to that same amount, you wont loose time creating and destroying apache processes.
limit the PHP application memory usage, then you'll be able to handle more process (well, not so easy, can be a long rewrite)
use APC, it decrease the memory usage (and speed up execution)
and after that the other solutions are more complex
use an apache in worker mode or nginx, and get php out of the webserver with php-fpm
use a proxy cache like varnish to catch requests that can be cached (pseudo static content), and avoid requesting apache & PHP too much.
We have a lamp server that is fairly busy, the CPU usage hovers around 90% at peak times. We are having an intermittent problem where file uploads from web forms fail. It only seems to happen with larger files (over a mb) and it seems to affect some users more than others. We've gone through and checked the obvious stuff like PHP ini max upload sizes, execution times, and folder write permissions. Also, the site worked for a year without trouble like this and it suddenly began (we don't think any of our application php would cause this).
We've watched what happens in Charles Proxy and it shows the upload happening (the sent filesize increases regularly) until it just stops sending data. The browser just shows it's spinning progress like it's proceeding but you can wait 20 minutes and nothing will happen or it reports a timeout.
Does anyone know why an upload might fail intermittently? My only guess is that maybe it has to do with server traffic, like apache is closing that connection prematurely.
If the load on the server is high, then your scripts may be timing out while trying to upload the file. Can you give any more specifics on your problem? I think PHP scripts have a 30 second timeout by default, meaning that if the script has not completed i.e. uploading the file within that time frame then the script will timeout and the upload will fail.
It seems like if the site worked for over a year, and now traffic has grown to the point where it is starting to strain the load on the server then it is possible that scripts may be timing out given the increased traffic and load on the server.
I'm helping out in a forum that runs on SMF. The site has been lagging recently and our host tells us it's the file uploads that clogs the servers memory and that SMF is using server memory in a non optimized way. There's probably one file upload every hour at most so the load isn't that high.
Any thoughts on this? I don't know php to the extent that i can argue against them.
If PHP is run as an Apache module, used memory will not always be returned when the PHP script ends. There are a couple of ways to fix this:
Use less memory in your script (obviously)
Run your script as CGI instead of as an Apache module (this way, the memory will be returned on script exit)
Restart Apache when the memory needs to be reclaimed. This is not really a good solution, but we do it at Levonline twice a day...
Upgrade your hosting to your own server, where you don't have to think about the hosting provider's other customers, and can use as much memory as you want.