On 6 March 2013 09:20, Brett Parker iDunno@sommitrealweird.co.uk wrote:
Why are you wanting to migrate to nginx? I've seen many instances of nginx falling over and then not being able to be restarted cleanly, leading to all manner of fun.
Interesting, this isn't something I was aware of.
I've only heard good things about nginx. Maybe I look in the wrong places!
Where you using mod_php in apache? Are you planning on using the same system in nginx? i.e. you're still not seperating users from each other and you still have all the issues of php to deal with, except now you're in a less tested environment with a relatively young and unproven webserver.
No, the plan is to move to FGM. This is one of the motivations for the move, although FastCGI isn't limited to nginx.
Customers tend not to test things, no matter how nicely you ask them. What actually happens is that they say "yeah, that's all fine!", then 2 weeks after you've changed things they go "oh, hang on, this bit is broken, and this, and this..."
Don't get me wrong, all sites would get a proper amount of testing by me too. By "proper" I mean extensive for commercial sites but rather less for the handful of "freebies" that always seem to accumulate... The server in question is mostly either internal or personal stuff so a failure is not critical - I wouldn't use anything I didn't know in a production environment for important sites and this exercise was partly about trialling something new, and partly about learning it's quirks so that if we do use it production at a future date I know it well enough to do so.
So, erm, the only thing that nginx is supposedly better at than apache is serving static sites... not a lot of yours are... erm... why are you moving to it again? (Please, don't tell me it's because "I heard of nginx and someone told me it was cool!")
I heard of nginx and, er, hmmm....
However, yes nginx touts static as a major strength (although lets be fair: even a heavily PHP based site will still likely be serving substantial amounts of images and Javascript/CSS files so static performance is always relevant).
My biggest concern is the memory usage of Apache; in recent months I've had several issues due to running out of RAM on systems that really ought not have an issue, and memory footprint is my prime motivation for looking at alternatives. Yes, Apache can be tuned (and largely this is something I haven't done), but fundamentally the event model seems better than the options that Apache (2.2) gives me. To be fair I have no knowledge of the event model used by Apache 2.4 (I didn't know it existed until yesterday) but that would also trip a lot of the "relatively young and unproven" tests.
Aside from making sure I have enough RAM to run both alongside each other, any reason to avoid this approach?
Only as outlined above - i.e. why fix something that isn't broken.
Because what I have now is broken, ie it's not stable due to memory requirements. Every time I've had a major issue the logs have suggested that Apache caused the system to run out of memory. Don't get me wrong: I'm not just assuming that Apache is the underlying problem here, as it's likely to be the code that Apache is running (via mod_php or whatever) that is the real culprit. But it has prompted me to look at alternatives, and until now I'd not heard a bad word said against nginx.
Aside: Another motivation is that we do a lot of work with ARM based systems which rarely have more than 512MB (think Raspberry Pi sort of spec). We usually end up with Apache on these systems because it's what we know, but I really think that nginx/lighttpd/other would be a better fit when resources are tight.