On 06 Mar 11:42, Mark Rogers wrote:
On 6 March 2013 11:01, Brett Parker iDunno@sommitrealweird.co.uk wrote:
Serving statics on ftp.uk.debian.org actually was one of the things that we've watched it die from... ;)
When was that (ie was it a while back and things could have improved)?
Within the last 6 months...
Since your first comment I've done quite a lot more Googling, and the conclusion seems to be:
- the number of people saying nginx is better than Apache outweighs the reverse
A lot of them also aren't serving any thing large, or have long running php processes... the event model is fine, except in those cases... then it can get "interesting".
- a lot of people talking about memory leaks in lighttpd, and in
general more people favouring nginx
lighttpd isn't my favourite, and I wouldn't run it on anything internet facing... but then, I wouldn't expect the Raspberry PI to be internet facing...
- a lot of issues in nginx with PHP pre FPM, but a general consensus
that nginx with FPM is "great".
Apparently FPM is now part of the standard PHP build, so maybe it'll eventually properly replace the old fastcgi module they had... who knows. Either way, PHP is generally a PITA...
- a lot of people talking about stability issues with Apache due to
running out of memory (ie my problem), and that things have been better since they switched.
And if you're running the same PHP in the same way under nginx you'll have the same issue...
Of course, you're not going to do that, as nginx doesn't have a mod_php... So, not even a like for like comparison... and all the posts that claim nginx to be faster and more stable also say they switched from apache and mod_php! Apples, meet Oranges.
Of-course everyone has an anecdote, and one from someone I "know" (ALUG counts :-) carries more weight.
Do you mean FPM? As in PHP-FPM? But anyways - that's just fastcgi, really... and for that I'd use mod_fcgid, a small wrapper script, mod_suexec, and a seperate small wrapper script for each user (the wrapper script potentially sets various envvars and ulimits, maybe even chroots them in to a new and interesting place).
Yes, FPM, that's what I typed, the keyboard just had other ideas :-)
"Most people" still use Apache with mod_php though, don't they? Which means Apache with FastCGI has many of the same "fewer people use it" arguments against it as nginx. Mind you, if "fewer people use it" was a big factor I'd have a Windows desktop... (Aside: It read that Nginx now has the number 2 web server spot, having overtaken IIS? Still only about 10% compared with 5/6x that for Apache though.)
Depends on the difinition of "most people"... If most people is people that set up their own hosting and aren't security focused and do trust mod_php (or are, infact, the only people hosting at all on that server), then yes, it's still the most common way of running PHP... However, I can't remember the last sysadmin I've encountered that would consider running PHP in anything other than a fastcgi environment as a seperate user from the web server, and as locked down as they could make it...
Fair enough - I'd suggest waiting for the apache2-event-mpm to become more stable if you really want to use an event based webserver...
However long I wait, nginx will have been doing it longer than Apache. A bigger issue is that running Apache 2.2 and Apache 2.4 alongside each other on the same server isn't as easy.
Erm, it certainly used to be easy enough to run multiple version of apache in parallel...
But, anyways - I'm still not convinced that event driven web serving is any better for the interesting work loads that a PHP driven site can do, and I don't think it's any good for large file serving, but hey :)
Most of which, if it's an even remotely busy site, will be in the filesystem cache, and once there, apache is going to be able to serve them fairly much as quickly anyways....
None of my sites are remotely busy, to be honest. All the more reason Apache shouldn't struggle for RAM. I think getting hit by search engine spiders is the biggest demand it faces.
I'd have been trying to tie the breakages in with the apache logs, really... but meh, whatever! :)
Have you got limits set in PHP?
Yes. Not finely tuned though.
Still, mod_php is leaky even with it's limits set, so I'd advise the /etc/defaults/apache2 setting as per earlier post.
Are large files being uploaded?
No. Large memory processes tend to be badly written sitemap generators on sites with lots of products, etc.
Right - so, erm, a coding issue, which is only going to be "magically" fixed because the fastcgi processes will be restarted after a certain number of requests...
Could it be that there's a bad PHP script that's leaking all over the place, and using a frequently restart fastcgi script would limit the problems?
Yes, although likely not leaking as such, just inefficient. The sort of code that does a "SELECT * FROM table" and builds an array from the results, regardless of whether that's 100 or 100k results it has to hold in memory.
I know those ones all too well, but apparently maiming developers is frowned upon... I don't know why!
OK - so, I'd be switching to a mod_fcgid based php setup, and limiting the resources that apache uses.
Assuming I go this route, [how] can I migrate an existing server virtual host by virtual host?
Setup a second virtual host with the other port number, remember to use the Listen and NameVirtualHost directives for the other port... setup the required wrappers and SuExec directives, done...
Depends what you're serving from the Pi, really. But nginx wouldn't be my choice for a pi... lighttpd, maybe, perhaps.
I pretty much expect to be able to do on the Pi whatever I do on anything else, mainly because starting with that assumption hasn't caused me any major headaches so far!
I'd class the Pi as embedded kit, it hasn't got that much in the way of power, and thus although I *could* treat it as Just Another Box, I'd be looking to use the lowest footprint software possible unless some bit of functionality is required.
That's two suggestions I should look at lighttpd in this thread, so that's something I will do.
I've seen a fair few holes in lighttpd, I don't actually recommend it for anything facing the general internet, but it is small...
But, returning to the original post: any reason why I can't install (lighttpd|nginx) alongside Apache (on a different port) and dual-run for a period of time? Memory constraints permitting of-course.
Absolutely none. Why would there be?