You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by James Smith <js...@sanger.ac.uk> on 2020/08/04 07:36:47 UTC
RE: suggestions for perl as web development language [EXT]
Perl is a great solution for web development.
Others will disagree but the best way I still believe is using mod_perl - but only if you use it's full power - and you probably need a special sort of mind set to use - but that can be said for any language.
From experience - it may be fractionally slower than small "standalone" apps that dancer etc are good at, but it is (a) much, much more stable {dancer etc does not cope well with either large requests or lots of small requests}, and (b) if you have a large code base and/or a large number of services then it generally uses much less compute power than the others {can easily handle multiple services on a single apache instance}
Where it really gains is the hooks into the apache process - being able to add functionality easily at any stage in the request process, from path translation, AAA stages, pre-processing, to post-processing and logging, and also to interact with other languages at any stage - e.g. can handle pre-processing & post-processing around a script written in another language (e.g. PHP, Java) or produced by another webserver integrated by mod_proxy.
It isn't really a framework though like dancer or mojolicious and thus has its own advantages and disadvantages.
You would to some extent have to roll your own code to produce the pages themselves although there are libraries out there to do lots of it.
We have an in house library whose embryonic stages were written over 20 years ago - and has now been stable for around 12-13 years and works strong...
James
-----Original Message-----
From: Wesley Peng <me...@yonghua.org>
Sent: 04 August 2020 06:43
To: modperl@perl.apache.org
Subject: suggestions for perl as web development language [EXT]
greetings,
My team use all of perl, ruby, python for scripting stuff.
perl is stronger for system admin tasks, and data analysis etc.
But for web development, it seems to be not as popular as others.
It has less selective frameworks, and even we can't get the right people to do the webdev job with perl.
Do you think in today we will give up perl/modperl as web development language, and choose the alternatives instead?
Thanks & Regards
--
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.
Re: suggestions for perl as web development language [EXT]
Posted by Mithun Bhattacharya <mi...@gmail.com>.
Making a wild guess here - most RDBMS won't like it if you make thousands
of queries per second across 500 tables every second. Can this be done -
yes but most setup's aren't tuned to be able to handle such a scenario.
If I was doing something like this I can imagine quite a few places which
would fall apart in my current code which would have nothing to do with
either mod_perl or forking/threading. Again I have absolutely no idea what
has been implemented by John so it is quite possible it is a mod_perl and
forking issue but that can not be generalized for everyone.
On Mon, Dec 21, 2020 at 1:27 AM Vincent Veyron <vv...@wanadoo.fr> wrote:
>
> [You forgot to cc the list ]
>
> On Sun, 20 Dec 2020 23:16:03 -0500
> John Dunlap <Jo...@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
>
RE: suggestions for perl as web development language [EXT]
Posted by James Smith <js...@sanger.ac.uk>.
> (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)
The first rule of session hashes is don't use session hashes, but the 2nd rule of session hashes is don't write them to disk - that is really inefficient. Look at using something like MySQL, memcached, redis, ... to store them instead - whatever you do - just avoid writing to disk!
-----Original Message-----
From: Vincent Veyron <vv...@wanadoo.fr>
Sent: 21 December 2020 07:27
To: John Dunlap <Jo...@lariat.co>
Cc: modperl@perl.apache.org
Subject: Re: suggestions for perl as web development language [EXT]
[You forgot to cc the list ]
On Sun, 20 Dec 2020 23:16:03 -0500
John Dunlap <Jo...@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 :
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=DwIFAw&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4oDX0XM7vQ&m=wOEBUDMfU7L3Uq4Q7pzEIfQ0Qfh1jaa-dmtnINBi3sM&s=fztwZzN5yK5qT6hb4WlQYTaEBqRmSv7Pj7v_o6WmyfM&e=
Easier to read in this archive :
https://urldefense.proofpoint.com/v2/url?u=http-3A__mail-2Darchives.apache.org_mod-5Fmbox_perl-2Dmodperl_202008.mbox_browser&d=DwIFAw&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4oDX0XM7vQ&m=wOEBUDMfU7L3Uq4Q7pzEIfQ0Qfh1jaa-dmtnINBi3sM&s=3saqpwQfa8fOf9eiynEa-w3JsT-tenD-pyUc3vfFhwc&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?
--
Bien à vous, Vincent Veyron
https://urldefense.proofpoint.com/v2/url?u=https-3A__compta.libremen.com&d=DwIFAw&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4oDX0XM7vQ&m=wOEBUDMfU7L3Uq4Q7pzEIfQ0Qfh1jaa-dmtnINBi3sM&s=yvWfWmnBK99th1DSC5sQcjzdWwA6QZRGXpO2R5H1414&e=
Logiciel libre de comptabilité générale en partie double
--
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.
Re: suggestions for perl as web development language [EXT]
Posted by Mithun Bhattacharya <mi...@gmail.com>.
Sounds like a classic use case for Kafka - your service should publish when
done and your clients should subscribe to their relevant topics. This is
not going to be scalable even with websockets.
On Tue, Dec 22, 2020 at 9:06 AM John Dunlap <Jo...@lariat.co> wrote:
> 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 <js...@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 <Jo...@lariat.co>
>> *Sent:* 22 December 2020 13:35
>> *To:* Vincent Veyron <vv...@wanadoo.fr>
>> *Cc:* mod_perl list <mo...@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...@wanadoo.fr>
>> wrote:
>>
>>
>> [You forgot to cc the list ]
>>
>> On Sun, 20 Dec 2020 23:16:03 -0500
>> John Dunlap <Jo...@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:*
>>
>> john@lariat.co
>>
>>
>> *Customer Service:*
>>
>> 877.268.6667
>>
>> support@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:*
> *john@lariat.co <jo...@lariat.co>*
>
> *Customer Service:*
> 877.268.6667
> support@lariat.co
>
Re: suggestions for perl as web development language [EXT]
Posted by John Dunlap <Jo...@lariat.co>.
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 <js...@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 <Jo...@lariat.co>
> *Sent:* 22 December 2020 13:35
> *To:* Vincent Veyron <vv...@wanadoo.fr>
> *Cc:* mod_perl list <mo...@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...@wanadoo.fr>
> wrote:
>
>
> [You forgot to cc the list ]
>
> On Sun, 20 Dec 2020 23:16:03 -0500
> John Dunlap <Jo...@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:*
>
> john@lariat.co
>
>
> *Customer Service:*
>
> 877.268.6667
>
> support@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:*
*john@lariat.co <jo...@lariat.co>*
*Customer Service:*
877.268.6667
support@lariat.co
RE: suggestions for perl as web development language [EXT]
Posted by James Smith <js...@sanger.ac.uk>.
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 <Jo...@lariat.co>
Sent: 22 December 2020 13:35
To: Vincent Veyron <vv...@wanadoo.fr>
Cc: mod_perl list <mo...@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...@wanadoo.fr>> wrote:
[You forgot to cc the list ]
On Sun, 20 Dec 2020 23:16:03 -0500
John Dunlap <Jo...@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:
john@lariat.co<ma...@lariat.co>
Customer Service:
877.268.6667
support@lariat.co<ma...@lariat.co>
[cid:image001.png@01D6D86F.18E6D9C0]
--
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.
Re: suggestions for perl as web development language [EXT]
Posted by Mithun Bhattacharya <mi...@gmail.com>.
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 <Jo...@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...@wanadoo.fr>
> wrote:
>
>>
>> [You forgot to cc the list ]
>>
>> On Sun, 20 Dec 2020 23:16:03 -0500
>> John Dunlap <Jo...@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:*
> *john@lariat.co <jo...@lariat.co>*
>
> *Customer Service:*
> 877.268.6667
> support@lariat.co
>
Re: suggestions for perl as web development language [EXT]
Posted by John Dunlap <Jo...@lariat.co>.
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...@wanadoo.fr> wrote:
>
> [You forgot to cc the list ]
>
> On Sun, 20 Dec 2020 23:16:03 -0500
> John Dunlap <Jo...@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:*
*john@lariat.co <jo...@lariat.co>*
*Customer Service:*
877.268.6667
support@lariat.co
Re: suggestions for perl as web development language [EXT]
Posted by Vincent Veyron <vv...@wanadoo.fr>.
[You forgot to cc the list ]
On Sun, 20 Dec 2020 23:16:03 -0500
John Dunlap <Jo...@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
Re: suggestions for perl as web development language [EXT]
Posted by Vincent Veyron <vv...@wanadoo.fr>.
[don't know why I'm seeing only parts of this thread, I did not get the original messages for some reason]
> >> On Sun, Dec 20, 2020 at 2:28 PM John Dunlap <Jo...@lariat.co> wrote:
> >>
> >>> It's extremely inefficient by comparison. We host our application on
> >>> beefy servers with 32 cores and 64G of ram and I commonly see poor system
> >>> performance with less than 25% cpu utilization.
> >>>
Hu? I'm hosting web apps on a lowly Kimsufi host (2 cores, 1,86GHz; 8 euros/month); each app makes dozens of database queries, the latest one makes 150 different queries in .05 seconds. I never see more than 0.15 load average with 10 users on line.
Granted, I have low traffic and small databases, but still.
(incidentally, I had a look at your home page, which took a good 5 seconds to load)
Bien à vous, Vincent Veyron
--
https://compta.libremen.com
Logiciel libre de comptabilité générale en partie double
RE: suggestions for perl as web development language [EXT]
Posted by James Smith <js...@sanger.ac.uk>.
Didn’t see the earlier response – John if you are seeing 25% cpu utilization that indicates that something is wrong with architecture of the solution rather than the language.
It would suggest that you have bottlenecks elsewhere – network, memory, database, disk. We have seen that the sweet spot of well designed servers is somewhere between 4 and 8 CPUs and 8-16G RAM, after that the performance gain is not so good – not because of the language – but because of all the other constraints on the system - wanting to databases/disk/network etc. We have HPC compute clusters at work – and to really make use of the large CPU/memory machines (last time I checked it was around 200 cores and 1Tb RAM) not just the coding but the underlying algorithm has to suit parallelisation, and care has to be taken to avoid writing to disk at any point in the operations.
From: Mithun Bhattacharya <mi...@gmail.com>
Sent: 20 December 2020 22:29
To: mod_perl list <mo...@perl.apache.org>
Subject: Re: suggestions for perl as web development language [EXT]
Running individual functions in independent threads can't be a solution for performance optimization - at least I have never heard such a thing, maybe others can pitch in.
On Sun, Dec 20, 2020 at 4:15 PM John Dunlap <Jo...@lariat.co>> wrote:
I have no doubt that our application can be optimized. We do so whenever we encounter poor performance and we will continue to do so. The point is that Perl didn't do a lot to help us in this regard. Languages like elixir use immutable data structures and will automatically run individual function calls in separate threads. Perl, by contrast, will only have a single thread per request.
On Sun, Dec 20, 2020, 3:33 PM Mithun Bhattacharya <mi...@gmail.com>> wrote:
You would have to define poor system performance - are you doing anything cpu intensive at all ? Maybe your RAM is being the bottleneck ?
On Sun, Dec 20, 2020 at 2:28 PM John Dunlap <Jo...@lariat.co>> wrote:
It's extremely inefficient by comparison. We host our application on beefy servers with 32 cores and 64G of ram and I commonly see poor system performance with less than 25% cpu utilization.
On Sun, Dec 20, 2020, 2:22 PM Mithun Bhattacharya <mi...@gmail.com>> wrote:
Agreed prefork is recommended but what is the problem with that ?
On Sun, Dec 20, 2020 at 12:47 PM John Dunlap <Jo...@lariat.co>> wrote:
Our app segfaults at random of we use anything other than prefork.
On Sun, Dec 20, 2020, 1:32 PM Mithun Bhattacharya <mi...@gmail.com>> wrote:
I am confused - you like threads so Perl is bad ? I am very happy forking away and yes I work a lot with non thread safe DBI connections without any issues.
On Sun, Dec 20, 2020 at 11:53 AM John Dunlap <Jo...@lariat.co>> wrote:
In my opinion, no one should build new projects in Perl. The world is increasingly trending towards parallelism and higher numbers of cpu cores and Perl is poorly positioned to leverage these advancements. Many of Perl's dependencies are not thread safe and mod_perl forces you to use mpm_prefork. My organization has started moving away from Perl to Elixir for these reasons.
On Tue, Aug 4, 2020, 3:37 AM James Smith <js...@sanger.ac.uk>> wrote:
Perl is a great solution for web development.
Others will disagree but the best way I still believe is using mod_perl - but only if you use it's full power - and you probably need a special sort of mind set to use - but that can be said for any language.
From experience - it may be fractionally slower than small "standalone" apps that dancer etc are good at, but it is (a) much, much more stable {dancer etc does not cope well with either large requests or lots of small requests}, and (b) if you have a large code base and/or a large number of services then it generally uses much less compute power than the others {can easily handle multiple services on a single apache instance}
Where it really gains is the hooks into the apache process - being able to add functionality easily at any stage in the request process, from path translation, AAA stages, pre-processing, to post-processing and logging, and also to interact with other languages at any stage - e.g. can handle pre-processing & post-processing around a script written in another language (e.g. PHP, Java) or produced by another webserver integrated by mod_proxy.
It isn't really a framework though like dancer or mojolicious and thus has its own advantages and disadvantages.
You would to some extent have to roll your own code to produce the pages themselves although there are libraries out there to do lots of it.
We have an in house library whose embryonic stages were written over 20 years ago - and has now been stable for around 12-13 years and works strong...
James
-----Original Message-----
From: Wesley Peng <me...@yonghua.org>>
Sent: 04 August 2020 06:43
To: modperl@perl.apache.org<ma...@perl.apache.org>
Subject: suggestions for perl as web development language [EXT]
greetings,
My team use all of perl, ruby, python for scripting stuff.
perl is stronger for system admin tasks, and data analysis etc.
But for web development, it seems to be not as popular as others.
It has less selective frameworks, and even we can't get the right people to do the webdev job with perl.
Do you think in today we will give up perl/modperl as web development language, and choose the alternatives instead?
Thanks & Regards
--
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.
--
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.
Re: [Hangout - NYLXS] suggestions for perl as web development
language [EXT]
Posted by Mithun Bhattacharya <mi...@gmail.com>.
Can you just shut up and unsubscribe from a Perl mailing list?
On Tue, Dec 22, 2020, 4:24 PM derrick <sd...@optonline.net> wrote:
> Why PERL at all anyway? Dump PERL.
>
Re: suggestions for perl as web development language [EXT]
Posted by Mithun Bhattacharya <mi...@gmail.com>.
Running individual functions in independent threads can't be a solution for
performance optimization - at least I have never heard such a thing, maybe
others can pitch in.
On Sun, Dec 20, 2020 at 4:15 PM John Dunlap <Jo...@lariat.co> wrote:
> I have no doubt that our application can be optimized. We do so whenever
> we encounter poor performance and we will continue to do so. The point is
> that Perl didn't do a lot to help us in this regard. Languages like elixir
> use immutable data structures and will automatically run individual
> function calls in separate threads. Perl, by contrast, will only have a
> single thread per request.
>
> On Sun, Dec 20, 2020, 3:33 PM Mithun Bhattacharya <mi...@gmail.com>
> wrote:
>
>> You would have to define poor system performance - are you doing anything
>> cpu intensive at all ? Maybe your RAM is being the bottleneck ?
>>
>> On Sun, Dec 20, 2020 at 2:28 PM John Dunlap <Jo...@lariat.co> wrote:
>>
>>> It's extremely inefficient by comparison. We host our application on
>>> beefy servers with 32 cores and 64G of ram and I commonly see poor system
>>> performance with less than 25% cpu utilization.
>>>
>>> On Sun, Dec 20, 2020, 2:22 PM Mithun Bhattacharya <mi...@gmail.com>
>>> wrote:
>>>
>>>> Agreed prefork is recommended but what is the problem with that ?
>>>>
>>>> On Sun, Dec 20, 2020 at 12:47 PM John Dunlap <Jo...@lariat.co> wrote:
>>>>
>>>>> Our app segfaults at random of we use anything other than prefork.
>>>>>
>>>>> On Sun, Dec 20, 2020, 1:32 PM Mithun Bhattacharya <mi...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I am confused - you like threads so Perl is bad ? I am very happy
>>>>>> forking away and yes I work a lot with non thread safe DBI connections
>>>>>> without any issues.
>>>>>>
>>>>>> On Sun, Dec 20, 2020 at 11:53 AM John Dunlap <Jo...@lariat.co> wrote:
>>>>>>
>>>>>>> In my opinion, no one should build new projects in Perl. The world
>>>>>>> is increasingly trending towards parallelism and higher numbers of cpu
>>>>>>> cores and Perl is poorly positioned to leverage these advancements. Many of
>>>>>>> Perl's dependencies are not thread safe and mod_perl forces you to use
>>>>>>> mpm_prefork. My organization has started moving away from Perl to Elixir
>>>>>>> for these reasons.
>>>>>>>
>>>>>>> On Tue, Aug 4, 2020, 3:37 AM James Smith <js...@sanger.ac.uk> wrote:
>>>>>>>
>>>>>>>> Perl is a great solution for web development.
>>>>>>>>
>>>>>>>> Others will disagree but the best way I still believe is using
>>>>>>>> mod_perl - but only if you use it's full power - and you probably need a
>>>>>>>> special sort of mind set to use - but that can be said for any language.
>>>>>>>>
>>>>>>>> From experience - it may be fractionally slower than small
>>>>>>>> "standalone" apps that dancer etc are good at, but it is (a) much, much
>>>>>>>> more stable {dancer etc does not cope well with either large requests or
>>>>>>>> lots of small requests}, and (b) if you have a large code base and/or a
>>>>>>>> large number of services then it generally uses much less compute power
>>>>>>>> than the others {can easily handle multiple services on a single apache
>>>>>>>> instance}
>>>>>>>>
>>>>>>>> Where it really gains is the hooks into the apache process - being
>>>>>>>> able to add functionality easily at any stage in the request process, from
>>>>>>>> path translation, AAA stages, pre-processing, to post-processing and
>>>>>>>> logging, and also to interact with other languages at any stage - e.g. can
>>>>>>>> handle pre-processing & post-processing around a script written in another
>>>>>>>> language (e.g. PHP, Java) or produced by another webserver integrated by
>>>>>>>> mod_proxy.
>>>>>>>>
>>>>>>>> It isn't really a framework though like dancer or mojolicious and
>>>>>>>> thus has its own advantages and disadvantages.
>>>>>>>>
>>>>>>>> You would to some extent have to roll your own code to produce the
>>>>>>>> pages themselves although there are libraries out there to do lots of it.
>>>>>>>>
>>>>>>>> We have an in house library whose embryonic stages were written
>>>>>>>> over 20 years ago - and has now been stable for around 12-13 years and
>>>>>>>> works strong...
>>>>>>>>
>>>>>>>> James
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Wesley Peng <me...@yonghua.org>
>>>>>>>> Sent: 04 August 2020 06:43
>>>>>>>> To: modperl@perl.apache.org
>>>>>>>> Subject: suggestions for perl as web development language [EXT]
>>>>>>>>
>>>>>>>> greetings,
>>>>>>>>
>>>>>>>> My team use all of perl, ruby, python for scripting stuff.
>>>>>>>> perl is stronger for system admin tasks, and data analysis etc.
>>>>>>>> But for web development, it seems to be not as popular as others.
>>>>>>>> It has less selective frameworks, and even we can't get the right
>>>>>>>> people to do the webdev job with perl.
>>>>>>>> Do you think in today we will give up perl/modperl as web
>>>>>>>> development language, and choose the alternatives instead?
>>>>>>>>
>>>>>>>> Thanks & Regards
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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.
>>>>>>>
>>>>>>>
Re: suggestions for perl as web development language [EXT]
Posted by Mithun Bhattacharya <mi...@gmail.com>.
You would have to define poor system performance - are you doing anything
cpu intensive at all ? Maybe your RAM is being the bottleneck ?
On Sun, Dec 20, 2020 at 2:28 PM John Dunlap <Jo...@lariat.co> wrote:
> It's extremely inefficient by comparison. We host our application on beefy
> servers with 32 cores and 64G of ram and I commonly see poor system
> performance with less than 25% cpu utilization.
>
> On Sun, Dec 20, 2020, 2:22 PM Mithun Bhattacharya <mi...@gmail.com>
> wrote:
>
>> Agreed prefork is recommended but what is the problem with that ?
>>
>> On Sun, Dec 20, 2020 at 12:47 PM John Dunlap <Jo...@lariat.co> wrote:
>>
>>> Our app segfaults at random of we use anything other than prefork.
>>>
>>> On Sun, Dec 20, 2020, 1:32 PM Mithun Bhattacharya <mi...@gmail.com>
>>> wrote:
>>>
>>>> I am confused - you like threads so Perl is bad ? I am very happy
>>>> forking away and yes I work a lot with non thread safe DBI connections
>>>> without any issues.
>>>>
>>>> On Sun, Dec 20, 2020 at 11:53 AM John Dunlap <Jo...@lariat.co> wrote:
>>>>
>>>>> In my opinion, no one should build new projects in Perl. The world is
>>>>> increasingly trending towards parallelism and higher numbers of cpu cores
>>>>> and Perl is poorly positioned to leverage these advancements. Many of
>>>>> Perl's dependencies are not thread safe and mod_perl forces you to use
>>>>> mpm_prefork. My organization has started moving away from Perl to Elixir
>>>>> for these reasons.
>>>>>
>>>>> On Tue, Aug 4, 2020, 3:37 AM James Smith <js...@sanger.ac.uk> wrote:
>>>>>
>>>>>> Perl is a great solution for web development.
>>>>>>
>>>>>> Others will disagree but the best way I still believe is using
>>>>>> mod_perl - but only if you use it's full power - and you probably need a
>>>>>> special sort of mind set to use - but that can be said for any language.
>>>>>>
>>>>>> From experience - it may be fractionally slower than small
>>>>>> "standalone" apps that dancer etc are good at, but it is (a) much, much
>>>>>> more stable {dancer etc does not cope well with either large requests or
>>>>>> lots of small requests}, and (b) if you have a large code base and/or a
>>>>>> large number of services then it generally uses much less compute power
>>>>>> than the others {can easily handle multiple services on a single apache
>>>>>> instance}
>>>>>>
>>>>>> Where it really gains is the hooks into the apache process - being
>>>>>> able to add functionality easily at any stage in the request process, from
>>>>>> path translation, AAA stages, pre-processing, to post-processing and
>>>>>> logging, and also to interact with other languages at any stage - e.g. can
>>>>>> handle pre-processing & post-processing around a script written in another
>>>>>> language (e.g. PHP, Java) or produced by another webserver integrated by
>>>>>> mod_proxy.
>>>>>>
>>>>>> It isn't really a framework though like dancer or mojolicious and
>>>>>> thus has its own advantages and disadvantages.
>>>>>>
>>>>>> You would to some extent have to roll your own code to produce the
>>>>>> pages themselves although there are libraries out there to do lots of it.
>>>>>>
>>>>>> We have an in house library whose embryonic stages were written over
>>>>>> 20 years ago - and has now been stable for around 12-13 years and works
>>>>>> strong...
>>>>>>
>>>>>> James
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Wesley Peng <me...@yonghua.org>
>>>>>> Sent: 04 August 2020 06:43
>>>>>> To: modperl@perl.apache.org
>>>>>> Subject: suggestions for perl as web development language [EXT]
>>>>>>
>>>>>> greetings,
>>>>>>
>>>>>> My team use all of perl, ruby, python for scripting stuff.
>>>>>> perl is stronger for system admin tasks, and data analysis etc.
>>>>>> But for web development, it seems to be not as popular as others.
>>>>>> It has less selective frameworks, and even we can't get the right
>>>>>> people to do the webdev job with perl.
>>>>>> Do you think in today we will give up perl/modperl as web development
>>>>>> language, and choose the alternatives instead?
>>>>>>
>>>>>> Thanks & Regards
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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.
>>>>>
>>>>>
Re: suggestions for perl as web development language [EXT]
Posted by Mithun Bhattacharya <mi...@gmail.com>.
Agreed prefork is recommended but what is the problem with that ?
On Sun, Dec 20, 2020 at 12:47 PM John Dunlap <Jo...@lariat.co> wrote:
> Our app segfaults at random of we use anything other than prefork.
>
> On Sun, Dec 20, 2020, 1:32 PM Mithun Bhattacharya <mi...@gmail.com>
> wrote:
>
>> I am confused - you like threads so Perl is bad ? I am very happy forking
>> away and yes I work a lot with non thread safe DBI connections without any
>> issues.
>>
>> On Sun, Dec 20, 2020 at 11:53 AM John Dunlap <Jo...@lariat.co> wrote:
>>
>>> In my opinion, no one should build new projects in Perl. The world is
>>> increasingly trending towards parallelism and higher numbers of cpu cores
>>> and Perl is poorly positioned to leverage these advancements. Many of
>>> Perl's dependencies are not thread safe and mod_perl forces you to use
>>> mpm_prefork. My organization has started moving away from Perl to Elixir
>>> for these reasons.
>>>
>>> On Tue, Aug 4, 2020, 3:37 AM James Smith <js...@sanger.ac.uk> wrote:
>>>
>>>> Perl is a great solution for web development.
>>>>
>>>> Others will disagree but the best way I still believe is using mod_perl
>>>> - but only if you use it's full power - and you probably need a special
>>>> sort of mind set to use - but that can be said for any language.
>>>>
>>>> From experience - it may be fractionally slower than small "standalone"
>>>> apps that dancer etc are good at, but it is (a) much, much more stable
>>>> {dancer etc does not cope well with either large requests or lots of small
>>>> requests}, and (b) if you have a large code base and/or a large number of
>>>> services then it generally uses much less compute power than the others
>>>> {can easily handle multiple services on a single apache instance}
>>>>
>>>> Where it really gains is the hooks into the apache process - being able
>>>> to add functionality easily at any stage in the request process, from path
>>>> translation, AAA stages, pre-processing, to post-processing and logging,
>>>> and also to interact with other languages at any stage - e.g. can handle
>>>> pre-processing & post-processing around a script written in another
>>>> language (e.g. PHP, Java) or produced by another webserver integrated by
>>>> mod_proxy.
>>>>
>>>> It isn't really a framework though like dancer or mojolicious and thus
>>>> has its own advantages and disadvantages.
>>>>
>>>> You would to some extent have to roll your own code to produce the
>>>> pages themselves although there are libraries out there to do lots of it.
>>>>
>>>> We have an in house library whose embryonic stages were written over 20
>>>> years ago - and has now been stable for around 12-13 years and works
>>>> strong...
>>>>
>>>> James
>>>>
>>>> -----Original Message-----
>>>> From: Wesley Peng <me...@yonghua.org>
>>>> Sent: 04 August 2020 06:43
>>>> To: modperl@perl.apache.org
>>>> Subject: suggestions for perl as web development language [EXT]
>>>>
>>>> greetings,
>>>>
>>>> My team use all of perl, ruby, python for scripting stuff.
>>>> perl is stronger for system admin tasks, and data analysis etc.
>>>> But for web development, it seems to be not as popular as others.
>>>> It has less selective frameworks, and even we can't get the right
>>>> people to do the webdev job with perl.
>>>> Do you think in today we will give up perl/modperl as web development
>>>> language, and choose the alternatives instead?
>>>>
>>>> Thanks & Regards
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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.
>>>
>>>
Re: suggestions for perl as web development language [EXT]
Posted by Mithun Bhattacharya <mi...@gmail.com>.
I am confused - you like threads so Perl is bad ? I am very happy forking
away and yes I work a lot with non thread safe DBI connections without any
issues.
On Sun, Dec 20, 2020 at 11:53 AM John Dunlap <Jo...@lariat.co> wrote:
> In my opinion, no one should build new projects in Perl. The world is
> increasingly trending towards parallelism and higher numbers of cpu cores
> and Perl is poorly positioned to leverage these advancements. Many of
> Perl's dependencies are not thread safe and mod_perl forces you to use
> mpm_prefork. My organization has started moving away from Perl to Elixir
> for these reasons.
>
> On Tue, Aug 4, 2020, 3:37 AM James Smith <js...@sanger.ac.uk> wrote:
>
>> Perl is a great solution for web development.
>>
>> Others will disagree but the best way I still believe is using mod_perl -
>> but only if you use it's full power - and you probably need a special sort
>> of mind set to use - but that can be said for any language.
>>
>> From experience - it may be fractionally slower than small "standalone"
>> apps that dancer etc are good at, but it is (a) much, much more stable
>> {dancer etc does not cope well with either large requests or lots of small
>> requests}, and (b) if you have a large code base and/or a large number of
>> services then it generally uses much less compute power than the others
>> {can easily handle multiple services on a single apache instance}
>>
>> Where it really gains is the hooks into the apache process - being able
>> to add functionality easily at any stage in the request process, from path
>> translation, AAA stages, pre-processing, to post-processing and logging,
>> and also to interact with other languages at any stage - e.g. can handle
>> pre-processing & post-processing around a script written in another
>> language (e.g. PHP, Java) or produced by another webserver integrated by
>> mod_proxy.
>>
>> It isn't really a framework though like dancer or mojolicious and thus
>> has its own advantages and disadvantages.
>>
>> You would to some extent have to roll your own code to produce the pages
>> themselves although there are libraries out there to do lots of it.
>>
>> We have an in house library whose embryonic stages were written over 20
>> years ago - and has now been stable for around 12-13 years and works
>> strong...
>>
>> James
>>
>> -----Original Message-----
>> From: Wesley Peng <me...@yonghua.org>
>> Sent: 04 August 2020 06:43
>> To: modperl@perl.apache.org
>> Subject: suggestions for perl as web development language [EXT]
>>
>> greetings,
>>
>> My team use all of perl, ruby, python for scripting stuff.
>> perl is stronger for system admin tasks, and data analysis etc.
>> But for web development, it seems to be not as popular as others.
>> It has less selective frameworks, and even we can't get the right people
>> to do the webdev job with perl.
>> Do you think in today we will give up perl/modperl as web development
>> language, and choose the alternatives instead?
>>
>> Thanks & Regards
>>
>>
>>
>>
>> --
>> 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.
>
>
Re: suggestions for perl as web development language [EXT]
Posted by John Dunlap <Jo...@lariat.co>.
In my opinion, no one should build new projects in Perl. The world is
increasingly trending towards parallelism and higher numbers of cpu cores
and Perl is poorly positioned to leverage these advancements. Many of
Perl's dependencies are not thread safe and mod_perl forces you to use
mpm_prefork. My organization has started moving away from Perl to Elixir
for these reasons.
On Tue, Aug 4, 2020, 3:37 AM James Smith <js...@sanger.ac.uk> wrote:
> Perl is a great solution for web development.
>
> Others will disagree but the best way I still believe is using mod_perl -
> but only if you use it's full power - and you probably need a special sort
> of mind set to use - but that can be said for any language.
>
> From experience - it may be fractionally slower than small "standalone"
> apps that dancer etc are good at, but it is (a) much, much more stable
> {dancer etc does not cope well with either large requests or lots of small
> requests}, and (b) if you have a large code base and/or a large number of
> services then it generally uses much less compute power than the others
> {can easily handle multiple services on a single apache instance}
>
> Where it really gains is the hooks into the apache process - being able to
> add functionality easily at any stage in the request process, from path
> translation, AAA stages, pre-processing, to post-processing and logging,
> and also to interact with other languages at any stage - e.g. can handle
> pre-processing & post-processing around a script written in another
> language (e.g. PHP, Java) or produced by another webserver integrated by
> mod_proxy.
>
> It isn't really a framework though like dancer or mojolicious and thus has
> its own advantages and disadvantages.
>
> You would to some extent have to roll your own code to produce the pages
> themselves although there are libraries out there to do lots of it.
>
> We have an in house library whose embryonic stages were written over 20
> years ago - and has now been stable for around 12-13 years and works
> strong...
>
> James
>
> -----Original Message-----
> From: Wesley Peng <me...@yonghua.org>
> Sent: 04 August 2020 06:43
> To: modperl@perl.apache.org
> Subject: suggestions for perl as web development language [EXT]
>
> greetings,
>
> My team use all of perl, ruby, python for scripting stuff.
> perl is stronger for system admin tasks, and data analysis etc.
> But for web development, it seems to be not as popular as others.
> It has less selective frameworks, and even we can't get the right people
> to do the webdev job with perl.
> Do you think in today we will give up perl/modperl as web development
> language, and choose the alternatives instead?
>
> Thanks & Regards
>
>
>
>
> --
> 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.
AW: suggestions for perl as web development language [EXT]
Posted by Andreas Mock <an...@web.de>.
Hi all,
we also have a big code base whose starting point is more than two decades ago.
If you have developers who know their stuff and all the internal developed modules
and helpers you're good to go. BUT: We do have problems to get young, fresh
perl developers. Why? This language is simply unattractive to young people.
If I had to start a web application today on an empty field I wouldn't choose perl.
There is another point. When we started all logic was done in the backend.
Nowadays much is done in the browser itself with Javascript. You need this
Javascript knowhow in any case. And when you have it there is no big step
to using this in the backend too.
So, in my opinion there is a relevant difference between starting a project
or maintaining an (very) old one. Maintaining an old code base where you're
stuck to years of old code is not attractive to new developers in any case.
mod_perl? The opinions may vary. But we're trying to get rid of it. In the
old days mod_perl with apache was the one and only process doing
everything. Now it's common to have serveral tiers. In the front a
load balancer which probably also terminates SSL. Some lightweight
servers serving static stuff as fast as possible, and one or more servers which
act as application server. As soon as several stages of request processing
are not done in Apache (e.g. Rewriting, Dispatching, Logging) you only
use one stage of Apache to produce the content. And this can be done
with a native perl application server.
Don't understand me wrong. We program in Perl, we know Perl more or less,
we have a big code base in Perl. But I won't start a new project on an empty (!)
field with it. But our field is NOT empty because we have so many known own
libraries and modules for all the common cross application requirements that
it would last very long to build these in a different language.
At the end you need people to do it. And you have to see how much legacy
code base and knowledge is there.
Regards
Andreas
-----Ursprüngliche Nachricht-----
Von: James Smith <js...@sanger.ac.uk>
Gesendet: Dienstag, 4. August 2020 09:37
An: Wesley Peng <me...@yonghua.org>; modperl@perl.apache.org
Betreff: RE: suggestions for perl as web development language [EXT]
Perl is a great solution for web development.
Others will disagree but the best way I still believe is using mod_perl - but only if you use it's full power - and you probably need a special sort of mind set to use - but that can be said for any language.
From experience - it may be fractionally slower than small "standalone" apps that dancer etc are good at, but it is (a) much, much more stable {dancer etc does not cope well with either large requests or lots of small requests}, and (b) if you have a large code base and/or a large number of services then it generally uses much less compute power than the others {can easily handle multiple services on a single apache instance}
Where it really gains is the hooks into the apache process - being able to add functionality easily at any stage in the request process, from path translation, AAA stages, pre-processing, to post-processing and logging, and also to interact with other languages at any stage - e.g. can handle pre-processing & post-processing around a script written in another language (e.g. PHP, Java) or produced by another webserver integrated by mod_proxy.
It isn't really a framework though like dancer or mojolicious and thus has its own advantages and disadvantages.
You would to some extent have to roll your own code to produce the pages themselves although there are libraries out there to do lots of it.
We have an in house library whose embryonic stages were written over 20 years ago - and has now been stable for around 12-13 years and works strong...
James
-----Original Message-----
From: Wesley Peng <me...@yonghua.org>
Sent: 04 August 2020 06:43
To: modperl@perl.apache.org
Subject: suggestions for perl as web development language [EXT]
greetings,
My team use all of perl, ruby, python for scripting stuff.
perl is stronger for system admin tasks, and data analysis etc.
But for web development, it seems to be not as popular as others.
It has less selective frameworks, and even we can't get the right people to do the webdev job with perl.
Do you think in today we will give up perl/modperl as web development language, and choose the alternatives instead?
Thanks & Regards
--
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.
Re: suggestions for perl as web development language [EXT]
Posted by Ruben Safir <ru...@mrbrklyn.com>.
On Wed, Aug 05, 2020 at 10:32:39AM +1000, dcook@prosentient.com.au wrote:
> I don't really see the utility of this thread, since these are just circular
> arguments based primarily on opinion, and no one is going to convince
> someone else that their opinion is wrong.
>
> That said, I'll just point out one thing about the earlier comment "How many
> platforms can survive 30 years. Mod_Perl/Apache."
>
> Mod_perl is 24 years old (http://perl.apache.org/about/history.html), Apache
> httpd is 25 years old (https://httpd.apache.org/ABOUT_APACHE.html), and Perl
> is roughly 32 years old (https://en.wikipedia.org/wiki/Perl).
>
> At this point, no Mod_Perl/Apache platforms has survived 30 years. I have 1
> Mod_Perl/Apache platform left and it is about 9 years old, and its lifespan
> is currently based on inertia.
When one reads replies like this you tend to just /dev/null to sender
and shrug your shoulders.
Thanks for working out the exact math for us. Your points are
excellent.
RE: suggestions for perl as web development language [EXT]
Posted by dc...@prosentient.com.au.
I don't really see the utility of this thread, since these are just circular
arguments based primarily on opinion, and no one is going to convince
someone else that their opinion is wrong.
That said, I'll just point out one thing about the earlier comment "How many
platforms can survive 30 years. Mod_Perl/Apache."
Mod_perl is 24 years old (http://perl.apache.org/about/history.html), Apache
httpd is 25 years old (https://httpd.apache.org/ABOUT_APACHE.html), and Perl
is roughly 32 years old (https://en.wikipedia.org/wiki/Perl).
At this point, no Mod_Perl/Apache platforms has survived 30 years. I have 1
Mod_Perl/Apache platform left and it is about 9 years old, and its lifespan
is currently based on inertia. At some point, it will be replaced by a new
system written in a programming language for which the system owner (ie not
me) can shop around, unless the dollar cost of doing that is greater than
letting inertia continue.
One other comment. The worst performing parts of my Mod_perl/Apache
application have nothing to do with Mod_perl or Apache. They have to do with
poor quality code and poor database schema design completed by other
developers nearly a decade ago. I could run the same application using
Starman and Nginx, and it would still have the exact same problems. You can
take any tool and craft a poor solution. Likewise, you can take many tools
and craft a great solution.
I have no complaints about Mod_perl/Apache per se, but - like Perl - they're
aging. I already use Starman with other projects, and at some point I'll
replace mod_perl with it, as I know it better and I know more people who
know it better. I'm also using a Catalyst framework, so it's pretty much
plug and play.
Note also that it's easier to get a specific version of Starman than it is
to get a specific version of Mod_perl/Apache in a particular OS.
Anyway, with the exception of those aforementioned dates, that's just my
opinion.
David Cook
-----Original Message-----
From: Ruben Safir <ru...@mrbrklyn.com>
Sent: Wednesday, 5 August 2020 5:14 AM
To: André Warnier (tomcat/perl) <aw...@ice-sa.com>
Cc: modperl@perl.apache.org
Subject: Re: suggestions for perl as web development language [EXT]
On Tue, Aug 04, 2020 at 05:04:50PM +0200, André Warnier (tomcat/perl) wrote:
> On 04.08.2020 11:31, paul trader wrote:
> >On Tue, 4 Aug 2020 at 07:36, James Smith opined:
> >
> >JS:Others will disagree but the best way I still believe is using
> >mod_perl
> >JS:- but only if you use it's full power - and you probably need a
> >special JS:sort of mind set to use - but that can be said for any
language.
> >
> >i will second this motion. mod_perls ability to hook into any step
> >of the process apache uses to serve up a page makes it easy to design
> >a web solution that can be tailored for any solution.
> >
>
> Let me agree and add to that.
>
> If your purpose is simply to write "classic web applications" (in the
> sense of user interface etc), then there are probably nowadays easier
> and "more modern" tools than mod_perl; and indeed it is a problem to
> find young programmers who already know perl.
> (It is not difficult however for a good young programmer, to learn
> perl. And I would always prefer a good young programmer who doesn't
> know perl yet, over a not so good young programmer who knows
> everything except perl.)
>
> On the other hand, if your kind of project involves a very tight
> integration with all aspects of Apache httpd, then there really isn't
> any other tool than mod_perl to do it.
> It is difficult in a short message like this to detail all the ways
> that you can interact with Apache httpd to get things done, but have a
> look at the schema here :
>
> https://www.askapache.com/s/s.askapache.net/httpd/modules/modsecurity-
> apache_2.1.4/doc/html-multipage/04-processing-phases.html
>
> and imagine that, with mod_perl, you can interact with Apache httpd
> and control virtually everything that happens within any of those
> boxes (and even between them).
> Together, Apache httpd + mod_perl are a tool for creating complex
> web-based applications, which has no equivalent anywhere (not with any
> other webserver, not with any other programming language, not with any
> kind of OS)(in the open-source/free world).
> In addition, using mod_perl does not prevent you from using any other
> Apache add-on module or any other development tool in addition (in
> whatever programming language you choose). mod_perl just allows you to
> do more, and faster.
>
> A possible problem with mod_perl may be its continued support,
> considering the kind of discussions (hopefully temporary) going on at
> the moment in the perl 5.x/7.x development community.
> But I believe that there is such a wide existing base of solid web
> applications based on perl, mod_perl and the (also incomparable) CPAN
> library, that any idea of dropping support for them, would be for some
> time quite far in the future.
>
Everything depends....
Consider this though, when whipping up your new JSOm superwidget dodad
enterprise project...
How many platforms can survive 30 years. Mod_Perl/Apache.
How many platforms can be taken seriously with regard to privacy?
If I am doing a serious enterprise for something like healthcare, you need
to consider mod_perl for the longevity and security.
Concurancy is a problem that the modperl team and perl team should fix.
> P.S. As an example : I am at the moment working on expanding an
> Apache/mod_perl user authentication module, that has to be able to
> authenticate users using either of HTTP Basic, LDAP, SAML, SPNEGO
> (Windows), OpenId, SiteMinder (tm), client IP and and login-form based
> authentication, while delivering a consistent "user profile"
> to follow-up web applications.
> And I cannot think of any other tool than Apache/mod_perl which would
allow me to do this.
> (except this : https://metacpan.org/pod/Apache2::AuthAny, but that is
> also mod_perl based)
--
So many immigrant groups have swept through our town that Brooklyn, like
Atlantis, reaches mythological proportions in the mind of the world - RI
Safir 1998 http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com
- Leadership Development in Free Software http://www2.mrbrklyn.com/resources
- Unpublished Archive http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and extermination camps, but
incompatible with living as a free human being. -RI Safir 2013
Re: suggestions for perl as web development language [EXT]
Posted by Ruben Safir <ru...@mrbrklyn.com>.
On Tue, Aug 04, 2020 at 05:04:50PM +0200, André Warnier (tomcat/perl) wrote:
> On 04.08.2020 11:31, paul trader wrote:
> >On Tue, 4 Aug 2020 at 07:36, James Smith opined:
> >
> >JS:Others will disagree but the best way I still believe is using mod_perl
> >JS:- but only if you use it's full power - and you probably need a special
> >JS:sort of mind set to use - but that can be said for any language.
> >
> >i will second this motion. mod_perls ability to hook into any step of the
> >process apache uses to serve up a page makes it easy to design a web
> >solution that can be tailored for any solution.
> >
>
> Let me agree and add to that.
>
> If your purpose is simply to write "classic web applications" (in
> the sense of user interface etc), then there are probably nowadays
> easier and "more modern" tools than mod_perl; and indeed it is a
> problem to find young programmers who already know perl.
> (It is not difficult however for a good young programmer, to learn
> perl. And I would always prefer a good young programmer who doesn't
> know perl yet, over a not so good young programmer who knows
> everything except perl.)
>
> On the other hand, if your kind of project involves a very tight
> integration with all aspects of Apache httpd, then there really
> isn't any other tool than mod_perl to do it.
> It is difficult in a short message like this to detail all the ways
> that you can interact with Apache httpd to get things done, but have
> a look at the schema here :
>
> https://www.askapache.com/s/s.askapache.net/httpd/modules/modsecurity-apache_2.1.4/doc/html-multipage/04-processing-phases.html
>
> and imagine that, with mod_perl, you can interact with Apache httpd
> and control virtually everything that happens within any of those
> boxes (and even between them).
> Together, Apache httpd + mod_perl are a tool for creating complex
> web-based applications, which has no equivalent anywhere (not with
> any other webserver, not with any other programming language, not
> with any kind of OS)(in the open-source/free world).
> In addition, using mod_perl does not prevent you from using any
> other Apache add-on module or any other development tool in addition
> (in whatever programming language you choose). mod_perl just allows
> you to do more, and faster.
>
> A possible problem with mod_perl may be its continued support,
> considering the kind of discussions (hopefully temporary) going on
> at the moment in the perl 5.x/7.x development community.
> But I believe that there is such a wide existing base of solid web
> applications based on perl, mod_perl and the (also incomparable)
> CPAN library, that any idea of dropping support for them, would be
> for some time quite far in the future.
>
Everything depends....
Consider this though, when whipping up your new JSOm superwidget dodad
enterprise project...
How many platforms can survive 30 years. Mod_Perl/Apache.
How many platforms can be taken seriously with regard to privacy?
If I am doing a serious enterprise for something like healthcare, you
need to consider mod_perl for the longevity and security.
Concurancy is a problem that the modperl team and perl team should fix.
> P.S. As an example : I am at the moment working on expanding an
> Apache/mod_perl user authentication module, that has to be able to
> authenticate users using either of HTTP Basic, LDAP, SAML, SPNEGO
> (Windows), OpenId, SiteMinder (tm), client IP and and login-form
> based authentication, while delivering a consistent "user profile"
> to follow-up web applications.
> And I cannot think of any other tool than Apache/mod_perl which would allow me to do this.
> (except this : https://metacpan.org/pod/Apache2::AuthAny, but that is also mod_perl based)
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com
Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Re: suggestions for perl as web development language [EXT]
Posted by "André Warnier (tomcat/perl)" <aw...@ice-sa.com>.
On 04.08.2020 11:31, paul trader wrote:
> On Tue, 4 Aug 2020 at 07:36, James Smith opined:
>
> JS:Others will disagree but the best way I still believe is using mod_perl
> JS:- but only if you use it's full power - and you probably need a special
> JS:sort of mind set to use - but that can be said for any language.
>
> i will second this motion. mod_perls ability to hook into any step of the
> process apache uses to serve up a page makes it easy to design a web
> solution that can be tailored for any solution.
>
Let me agree and add to that.
If your purpose is simply to write "classic web applications" (in the sense of user
interface etc), then there are probably nowadays easier and "more modern" tools than
mod_perl; and indeed it is a problem to find young programmers who already know perl.
(It is not difficult however for a good young programmer, to learn perl. And I would
always prefer a good young programmer who doesn't know perl yet, over a not so good young
programmer who knows everything except perl.)
On the other hand, if your kind of project involves a very tight integration with all
aspects of Apache httpd, then there really isn't any other tool than mod_perl to do it.
It is difficult in a short message like this to detail all the ways that you can interact
with Apache httpd to get things done, but have a look at the schema here :
https://www.askapache.com/s/s.askapache.net/httpd/modules/modsecurity-apache_2.1.4/doc/html-multipage/04-processing-phases.html
and imagine that, with mod_perl, you can interact with Apache httpd and control virtually
everything that happens within any of those boxes (and even between them).
Together, Apache httpd + mod_perl are a tool for creating complex web-based applications,
which has no equivalent anywhere (not with any other webserver, not with any other
programming language, not with any kind of OS)(in the open-source/free world).
In addition, using mod_perl does not prevent you from using any other Apache add-on module
or any other development tool in addition (in whatever programming language you choose).
mod_perl just allows you to do more, and faster.
A possible problem with mod_perl may be its continued support, considering the kind of
discussions (hopefully temporary) going on at the moment in the perl 5.x/7.x development
community.
But I believe that there is such a wide existing base of solid web applications based on
perl, mod_perl and the (also incomparable) CPAN library, that any idea of dropping support
for them, would be for some time quite far in the future.
P.S. As an example : I am at the moment working on expanding an Apache/mod_perl user
authentication module, that has to be able to authenticate users using either of HTTP
Basic, LDAP, SAML, SPNEGO (Windows), OpenId, SiteMinder (tm), client IP and and login-form
based authentication, while delivering a consistent "user profile" to follow-up web
applications.
And I cannot think of any other tool than Apache/mod_perl which would allow me to do this.
(except this : https://metacpan.org/pod/Apache2::AuthAny, but that is also mod_perl based)
RE: suggestions for perl as web development language [EXT]
Posted by paul trader <fl...@igolinux.com>.
On Tue, 4 Aug 2020 at 07:36, James Smith opined:
JS:Others will disagree but the best way I still believe is using mod_perl
JS:- but only if you use it's full power - and you probably need a special
JS:sort of mind set to use - but that can be said for any language.
i will second this motion. mod_perls ability to hook into any step of the
process apache uses to serve up a page makes it easy to design a web
solution that can be tailored for any solution.
regards, paul
--
Paul Trader.....ptrader@igolinux.com
IGO Linux Solutions
'Linux for the rest of us'
http://www.igolinux.com
Re: suggestions for perl as web development language [EXT]
Posted by Jan Kasprzak <ka...@fi.muni.cz>.
Hello,
James Smith wrote:
: Perl is a great solution for web development.
:
: Others will disagree but the best way I still believe is using mod_perl
: - but only if you use it's full power - and you probably need a special
: sort of mind set to use - but that can be said for any language.
Agreed. We have a codebase spanning 20 years, 2.3M LoC (without
comments). Some of it even pre-dates mod_perl (written originally for CGI.pm),
but mostly it uses code based on RegistryCooker as its underlying
infrastructure.
I just don't see a clean path towards HTTP/3 QUIC multi-session
connections in mod_perl. Sure, a reverse proxy will do, but it might be
better to do it natively. Do you know about any development of Apache+mod_perl
related to HTTP/2 or HTTP/3?
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| http://www.fi.muni.cz/~kas/ GPG: 4096R/A45477D5 |
IORING_OP_NOP ... the benefits of doing nothing asynchronously are minimal,
but sometimes a placeholder is useful. --Jonathan Corbet at LWN