Forking is not inefficient unless you work on Windows. Threads are more complicated to code for - thread safe coding is a thing.
Agreed web sockets are lacking but they are not essential in all modern application. I think we have discussed this topic enough and nothing new is being shared on the topic hence this will be the last reply on this conversation. On Tue, Dec 22, 2020, 7:35 AM John Dunlap <j...@lariat.co> wrote: > mod_perl is horribly inefficient because prefork is inefficient and > because each request is single threaded. In addition to this, mod_perl also > cannot provide websockets which are essential in a modern application. > > On Mon, Dec 21, 2020 at 1:26 AM Vincent Veyron <vv.li...@wanadoo.fr> > wrote: > >> >> [You forgot to cc the list ] >> >> On Sun, 20 Dec 2020 23:16:03 -0500 >> John Dunlap <j...@lariat.co> wrote: >> >> > We run 20 customers on a single box and our database has approximately >> 500 >> > tables. We run hundreds or thousands of queries per second. >> > >> >> 500 tables is a lot more than what I typically handle. I'm sure it >> complicates things. >> >> But see this post by James Smith in a recent thread : >> >> >> http://mail-archives.apache.org/mod_mbox/perl-modperl/202008.mbox/ajax/%3Cef383804cf394c53b48258531891d12b%40sanger.ac.uk%3E >> >> Easier to read in this archive : >> >> http://mail-archives.apache.org/mod_mbox/perl-modperl/202008.mbox/browser >> >> I also remember a post by a chinese guy who handled the same order of >> database size, in which he wrote that he had compared several frameworks >> and mod_perl was the fastest; but that was something like 10 years ago, and >> I can't find it anymore. >> >> So I'm not sure how mod_perl could handle that kind of load and be >> horribly inefficient? >> >> (I forgot to say in my previous post that over 50% of the time used by my >> script is spent on the _one_ query out of 120 that writes a smallish >> session hash to disk) >> >> -- >> Bien à vous, Vincent Veyron >> >> https://compta.libremen.com >> Logiciel libre de comptabilité générale en partie double >> > > > -- > John Dunlap > *CTO | Lariat * > > *Direct:* > *j...@lariat.co <j...@lariat.co>* > > *Customer Service:* > 877.268.6667 > supp...@lariat.co >
