Ging gang cloudy? IBM programmer packs it in for life as an online Scouts badge-tracker

Been there...

Ed did approach them and said pretty much that i believe, however they wanted something they made and knew from the ground-up themselves which is reasonable but to be honest i'd call it a waste of money, i mean if one of your own has created a system (as you say) why not just buy them out/pay them to keep doing it rather than pay some third party external (i.e non-scouting) company to reinvent the wheel, the mind boggles it really does and let's not forget The Scout Association themselves hardly has a great track record with IT as many of it's leaders would agree with.

Apache is phenomenally configurable in its mode of operation. If you choose the default chosen by most distributors, you get a mode of operation - prefork - where performance does blow. They choose this mode by default for two reasons, PHP and ease of use for their users.

PHP can run in two modes, an interpreter embedded in to the web server, or as a standalone process with worker children/threads that communicates with the webserver via FCGI. In the first mode, it is easier to setup a PHP app, simply put PHP files in a directory served by the webserver, in the second you need to configure FCGI - its not hard configuration, but it is extra work. Distros prefer not to do that, so prefer the first mode, however the first mode can only run in apache in prefork mode, therefore they choose prefork.

Each worker in prefork has a PHP interpreter active in it, whether it is serving static files or running PHP apps. This means you have more interpreters 'active' than are necessary - wasting resources. Plus, you can only handle as many simultaneous connections as you can handle simultaneous workers - regardless of what those connections are doing. So prefork is a dog, and to be avoided.

Apache has other modes. We use "event", which is a hybrid thread/process model, basically the same model as nginx, and guess what, it performs just as well as nginx. Plus, we can still use the billion or so apache modules out there. We have to use a fcgi-wrapper for our web apps, but this is good anyway as it allows us to control how many PHP processes are active at any one time, which prevents you having too many DB connections, which, if you've ever run a dynamic website will know, is usually the limiting factor of any hosted site.

nginx, as a bare bones web server, doesn't have the option of the prefork model, nor of embedding PHP directly in to the webserver, so you need to configure a php-fcgi wrapper for each app, just like we do for apache-event.

tl;dr - apache not dead, read the manual and learn how to configure it for performance.