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
