what are the opinions about the best way to run php for a forum like this or rslight ?
explanation:

due to the recent performance problems of both def2 and def3 (both threw a lot of 503s recently, this has gone away now), i have researched a bit about the best setup to run php ("the best" is relative to my needs of course: so: a modest number of users and messages, running the server on a vm hosted on modest hardware, with a limited up/download speed).
on the old machine, def3 used to run with nginx as webserver, connected to php-fpm over a system socket, and that worked fine. now i use lighttpd with php-cgi, and it seems to work fine as well (the performance problems came in fact from some daemons running wild that had nothing to do with the webserver or php).
def2 ran with lighttpd/php-cgi from the start, with mixed perfromance.
i understand that php-cgi is outdated, and fcgi is recommended. from php, the fcgi implemention in php (php-fpm) is recommended. on the other hand, i don't mind running outdated software if it does the job, which seems to be the case right now. php-fpm in combination with nginx also had a vuln recently (potential remote root access), so newer is not necessarily better. there are also much more parameters to adjust, which is fine if you know what you are doing, but makes it more complex.
So what are the opinions around ? What is your experience ? And if you use php-fpm, what are your settings ?

cheers

trw
Posted on def3

  To: trw
I doubt switching from php-cgi to fcgi would make much of a difference as you've already determined that it's about as fast as it was before. I always ran apache back in the day, but nginx had better performance so I moved over to that together with fcgi. Don't know about lighthttpd.

It is quite difficult giving performance advice when you don't know the machine or the specific setup in question. It looks like you are running FUDForum, but possibly also heavily modified? Whenever I had performance issues with forum software, then it was generally due to the database and not PHP or the web server per se. Not enough RAM, fragmented tables, bad queries, thrashing the hard disk... some of my performance issues were bad custom modifications that brought my server thrashing down lol.

My bet for performance issues is usually the database, and likely RAM or hard disk related. It's usually the case.

Excessive logging can also be an offender that many do not suspect, especially on hard drives with spinny disks.

with a limited up/download speed

I don't know how limited, but in that case I would gzip compress the pages.

on the other hand, i don't mind running outdated software

It's fine if you get security patches, but you may be missing out on some performance improvements. Do you use PHP 7? If not, then you should. It's twice as fast as previous versions of PHP due to JIT compilation with optimizations and it also uses less memory.

- crowbar
--
Posted on RetroBBS

  To: AnonUser
Forgot to add: what usually makes a big difference is the amount of worker processes and how many connections per process. The setting is very dependent on your hardware and will have to be configured accordingly.

Too many processes and they'll be waiting on IO, too few and your hardware will be idle during requests (where it's processing).

PS: I don't run synchronet bbss, but if they're anything like normal web forums that access a database then it should theoretically also apply. I assume they would sync in the background in addition to the normal forum software tasks..
--
Posted on RetroBBS

I doubt switching from php-cgi to fcgi would make much of a difference as you've already determined that it's about as fast as it was before.

Well, I thought it would be, but right it seems back to the old 503.

I always ran apache back in the day, but nginx had better performance so I moved over to that together with fcgi. Don't know about lighthttpd.

Well, google used to run lighttpd, so it should handle heavy loads pretty good, as long as it is configured correctly for the use case i guess.

It is quite difficult giving performance advice when you don't know the machine or the specific setup in question.

yeah, of course. the servers run as virtual machines with qemu. some part of the problem might be linked to configuration of the vms as well.

It looks like you are running FUDForum, but possibly also heavily modified?

Exactly. Heavily depends on definition of course, but yes, there are hacks/mods applied for:
-nntp updates
-session management
-string filtering -some admin functions (batch creation of groups and update rules)
-the theme of course (took out some functionality)
The reason might be in that as well (or part of it).

Whenever I had performance issues with forum software, then it was generally due to the database and not PHP or the web server per se. Not enough RAM, fragmented tables, bad queries, thrashing the hard disk... some of my performance issues were bad custom modifications that brought my server thrashing down lol.

I guess I can start searching for any of those as well....maybe it will also help to muscle up a bit on the RAM and CPU, just in case.

Excessive logging can also be an offender that many do not suspect, especially on hard drives with spinny disks.

This caused one of the recent server crashes. Good thing we are federated :-)

Do you use PHP 7?

yep.

Thanks for your feedback so far, I will check some stuff and report back.

trw
--
Posted on Rocksolid Light

I'm using php-fpm for my servers. I originally used the built in php support in apache, but had problems with heavy resource use. php-fpm seems to take care of this fine.

I discovered this mainly because all the sites on retroBBS run using Synchronet as the web server, and it was much more stable and reliable than the apache servers. Synchronet uses php-fpm.

Once switching apache to use php-fpm it was a lot better, but still had to modify mpm_prefork to kill processes eventually (after a certain number of uses). This seems to have made the biggest impact on stability.

I have used lighttpd and it has worked well. It seems to handle things exactly as the Synchronet server. Apache is a beast, but I still use it as I'm familiar with config etc., but it does take some tweaking to run well.

Retro Guy

--
Posted on Rocksolid Light

it seems like the database is the main component to cause the fuckups. corrupted tables (which i could repair) and still the importing problem of some outlandish characters causing collation errors.

Posted on def3