We have hundreds of users polling our servers every few seconds just waiting for events. In the near future, I'm going to have to do a refactor to avoid users polling two different endpoints for different kinds of events. The vast majority of the request in our access logs are polling requests and they put significant load on our systems that I would prefer to avoid. Additionally, web sockets aren't just for pushing content to the browser. If you use them in the opposite direction, they improve performance because you can avoid opening/closing a new connection and because you can avoid the overhead of the HTTP protocol resulting in shorter request times.
On Tue, Dec 22, 2020 at 8:32 AM James Smith <j...@sanger.ac.uk> wrote: > There are not many applications which really benefit from multiple threads > in web server environments unless you have very low load – as they are only > efficient as they can use multiple cores, so you need stupidly speced > machines to manage this load properly, and if you are using external > resources can often be blocking anyway. > > Yes mod_perl doesn’t do web-sockets – but usually that isn’t an issue > unless you have the need to push when people update content and you want it > immediately available. There are others issues to consider with web-sockets > e.g. port usage to keep the connections open. If you don’t need that > immediate response – polling can achieve the desired effect – and Apache > can even tell the client how long you need to wait before you send another > connection. > > > > > > *From:* John Dunlap <j...@lariat.co> > *Sent:* 22 December 2020 13:35 > *To:* Vincent Veyron <vv.li...@wanadoo.fr> > *Cc:* mod_perl list <modperl@perl.apache.org> > *Subject:* Re: suggestions for perl as web development language [EXT] > > > > 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 > [mail-archives.apache.org] > <https://urldefense.proofpoint.com/v2/url?u=http-3A__mail-2Darchives.apache.org_mod-5Fmbox_perl-2Dmodperl_202008.mbox_ajax_-253Cef383804cf394c53b48258531891d12b-2540sanger.ac.uk-253E&d=DwMFaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4oDX0XM7vQ&m=d_ZhFPlvaXw1KbAmeExguXy1fSbpEKzIuAPZMOJ9h78&s=nK2GCkR9GuTuv3TffZBjRZgIDya7tetj5oHLLDBsn18&e=> > > Easier to read in this archive : > > http://mail-archives.apache.org/mod_mbox/perl-modperl/202008.mbox/browser > [mail-archives.apache.org] > <https://urldefense.proofpoint.com/v2/url?u=http-3A__mail-2Darchives.apache.org_mod-5Fmbox_perl-2Dmodperl_202008.mbox_browser&d=DwMFaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4oDX0XM7vQ&m=d_ZhFPlvaXw1KbAmeExguXy1fSbpEKzIuAPZMOJ9h78&s=Om-DkyClcEdOiq5HBizz-ydRhOziZbAP-AL_sR0eXAE&e=> > > 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 [compta.libremen.com] > <https://urldefense.proofpoint.com/v2/url?u=https-3A__compta.libremen.com&d=DwMFaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4oDX0XM7vQ&m=d_ZhFPlvaXw1KbAmeExguXy1fSbpEKzIuAPZMOJ9h78&s=mT-OlBL98gDcEsBMBidxank1GbEXq2zX6zPGOmpwobU&e=> > Logiciel libre de comptabilité générale en partie double > > > > -- > > John Dunlap > > CTO | Lariat > > > > *Direct:* > > j...@lariat.co > > > *Customer Service:* > > 877.268.6667 > > supp...@lariat.co > > -- The Wellcome Sanger Institute is operated by Genome Research Limited, a > charity registered in England with number 1021457 and a company registered > in England with number 2742969, whose registered office is 215 Euston Road, > London, NW1 2BE. > -- John Dunlap *CTO | Lariat * *Direct:* *j...@lariat.co <j...@lariat.co>* *Customer Service:* 877.268.6667 supp...@lariat.co
