Increasing site traffic has escalated both our cpu and memory issues such that I am constantly tweeking 'bad-bot' and other defences against multiple concurrent connections, from single IP's, IP ranges and in total, using both mod_security and fail2ban/firewalld rules.
The problem has prompted 2 x server upgrades in the past 6 months. I now want to see if I can make better use of available resources, before having another server u/g forced on us.
Among other things I am considering moving to the Apache event-MPM using php-fpm and mod_proxy_fcgi because it is claimed to half (or better) process memory usage and provide major cpu-related speed improvements over the old pre-fork-MSM - I understand that thread-safe issues have been addressed such that the setup is now close to the old pre-fork safety. I would welcome confirmation (or otherwise) of that from anyone.
Any pointers/comments etc from anyone with experience of this setup would be appreciated. Also any pointers on optimising SMW query caching since the site makes very heavy use of property-based queries and I have a gut feeling that judicious SMW caching might help to speed things further.
I know much of this may seem a more appropriate to an Apache list but I think the php issue combined with both MW and SMW make it relevant here.
PeterP Wikispooks https://wikispooks.com
PS. FI: posted to both MW and SMW lists
On 8 November 2015 at 10:43, Peter Presland peter@wikispooks.org wrote:
Among other things I am considering moving to the Apache event-MPM using php-fpm and mod_proxy_fcgi because it is claimed to half (or better) process memory usage and provide major cpu-related speed improvements over the old pre-fork-MSM - I understand that thread-safe issues have been addressed such that the setup is now close to the old pre-fork safety. I would welcome confirmation (or otherwise) of that from anyone.
I'm not aware of SMW-specific issues, but in general (a) PHP is the fat part of the process in both memory and CPU time (b) fcgid is reputedly very slightly slower, but this will be vastly overshadowed by how fat PHP is.
The only reason I've ever found not to go full fcgid is that it's more fiddly to set up and get right. The main benefit is not less use of resources, but greater control over their use, i.e. if you run out of fcgid workers then at least Apache is still up to serve everything else.
(Is there any detail on these SMW-specific issues?)
- d.
When I have worked with php based websites. I try to avoid apache prefork as that tends to be resource hungry.
Look into apache event or worker with php-fpm. You will notice a major difference and things will be quicker.
Prefork works on a single thread to process requests.
Where as event and worker have a parent thread that handles the initial processing of the request then hands it off to a child thread while starting on the next request.
Jonathan Aquilina
On Sun, Nov 8, 2015 at 2:17 PM, David Gerard dgerard@gmail.com wrote:
On 8 November 2015 at 10:43, Peter Presland peter@wikispooks.org wrote:
Among other things I am considering moving to the Apache event-MPM using php-fpm and mod_proxy_fcgi because it is claimed to half (or better) process memory usage and provide major cpu-related speed improvements over the old pre-fork-MSM - I understand that thread-safe issues have been addressed such that the setup is now close to the old pre-fork safety. I would welcome confirmation (or otherwise) of that from anyone.
I'm not aware of SMW-specific issues, but in general (a) PHP is the fat part of the process in both memory and CPU time (b) fcgid is reputedly very slightly slower, but this will be vastly overshadowed by how fat PHP is.
The only reason I've ever found not to go full fcgid is that it's more fiddly to set up and get right. The main benefit is not less use of resources, but greater control over their use, i.e. if you run out of fcgid workers then at least Apache is still up to serve everything else.
(Is there any detail on these SMW-specific issues?)
- d.
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org