On 6 March 2013 13:09, Brett Parker iDunno@sommitrealweird.co.uk wrote:
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...
No argument there!
- 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...
True. Although the memory footprint it starts with is considerably bigger, and on a low memory system that is always a mark against Apache.
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.
Fair comment. Which is why I'd certainly consider Apache+FastCGI as an alternative.
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...
This is the direction I'm heading in. To be fair, whilst I have seen issues in the past with code uploaded and run as the Apache user, I've not yet seen it "travel" outside the docroot of the affected (infected) vhost. Generally, I like to think that my own code is also fairly robust, but increasingly it's the "standard" packages that have thrown issues at me and FastCGI would make me a lot happier.
However, I've spent some time playing with nginx this afternoon, and I have to say that the biggest PITA so far as been working with FastCGI (in which I have little experience), so I'm not looking forward to either route.
Erm, it certainly used to be easy enough to run multiple version of apache in parallel...
Something I should have mentioned: I don't put any build tools on my servers and I rely on the O/S provider to manage security patches, which means that unless I can: apt-get install apache-2.2 apache-2.4 .. it's going to be hard, and since they likely wouldn't want to share config directories anyway... From that point of view installing Apache and Nginx alongside each other is rather easier.
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 :)
What would it take to convince you? Today's research hasn't found anything that contradicts this position, putting 2.4 (event) ahead of 2.2 but behind nginx performance-wise. Every benchmark I found had flaws so i wouldn't put any forward as "proof" but it certainly felt like the general consensus pointed that way.
(I'm not arguing the case for it myself!)
I'd have been trying to tie the breakages in with the apache logs, really... but meh, whatever! :)
Been there done that - or rather not found anything which ties the problem even to a single virtual host, never mind a single script.
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...
Not at all :-)
Certainly I don't have the time to go fixing coding issues in third party code, but I started down this route after research suggested that nginx generally made a better hash of things. I've not been completely convinced otherwise by your arguments but I'm certainly wavering! At the end of the day anyone could make a good argument for fixing the code not the webserver even if I was on IIS.
I know those ones all too well, but apparently maiming developers is frowned upon... I don't know why!
This is the biggest issue with PHP - it seems to have a sufficiently low barrier to entry that any idiot can write PHP code, and many of them do.
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...
Bit late for me to start playing with this today but I'll give that a go when I get chance and see how I get on.
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.
Absolutely, however I've always tried to code down to the lowest common denominator so it's more that I (try to) treat a decent server like a Pi rather than the other way around. Most of my development stuff is on VMs running in no more than 512MB RAM. No point having a decent server if it's slowed down by inefficient code. Which so far has meant there's no point having a decent server at all, and the Pi isn't much of a step down (and we'll go up to newer ARM chips when needed).
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?
I couldn't think of a reason, but I didn't want to go through the exercise to end up with a "Doh" moment at the end. Not that this has ever happened.
Anyway, what's your favourite editor? :-)