Re: suggestions for perl as web development language

[Ashish Mukherjee]

What about dancer?

On Tue, 4 Aug 2020, 12:10 Rolf Schaufelberger,  wrote:

> I would not consider mod_perl for new projects, but instead highly
> recommend using mojolicious https://mojolicious.org/
>
>
> Am 04.08.2020 um 07:42 schrieb Wesley Peng :
>
> 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
>
>
> Rolf Schaufelberger
>
>
>

RE: suggestions for perl as web development language [EXT]

[James Smith]

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  
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]

[Jan Kasprzak]

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  |
| 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

AW: suggestions for perl as web development language [EXT]

[Andreas Mock]

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  
Gesendet: Dienstag, 4. August 2020 09:37
An: Wesley Peng ; 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 
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]

[paul trader]

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.ptra...@igolinux.com
IGO Linux Solutions
'Linux for the rest of us'
http://www.igolinux.com

Re: suggestions for perl as web development language

[John Dunlap]

The fundamental and, in my opinion, fatal flaws of mod_per are as follows:
1) Concurrency. mod_perl is pretty close to forced to use mpm_prefork
because very few perl dependencies are thread safe.
2) mod_perl cannot provide web sockets.

Due to these reasons, my organization has started looking at ways to move
away from mod_perl.

On Tue, Aug 4, 2020 at 5:43 AM Wesley Peng  wrote:

> 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
>
>

-- 
John Dunlap
*CTO | Lariat *

*Direct:*
*j...@lariat.co *

*Customer Service:*
877.268.6667
supp...@lariat.co

Re: suggestions for perl as web development language [EXT]

[tomcat/perl]

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]

[James Smith]

From: John Dunlap 
Sent: 04 August 2020 15:30
To: Wesley Peng 
Cc: mod_perl list 
Subject: Re: suggestions for perl as web development language [EXT]

The fundamental and, in my opinion, fatal flaws of mod_per are as follows:
> 1) Concurrency. mod_perl is pretty close to forced to use mpm_prefork because 
> very few perl dependencies are thread safe.

Concurrency in extreme conditions - is actually better when it comes to 
mod_perl than a number of other solutions – e.g. nginx/starman. Apache/mod_perl 
is much better at handling large numbers of simultaneous requests than the 
systems which fork a number of small processes at start up to handle requests. 
You either have to fork a large number of these or pray you don’t get large 
numbers of simultaneous requests. Some of our systems have long return times 
for queries due to the terra/petabyte scale of some of our backend servers.

> 2) mod_perl cannot provide web sockets.

True – we haven’t really found an excuse for web-sockets although our front end 
“Application Delivery Controller” (which sits in the DMZ) can manage proxying 
requests that need sockets one way and others that don’t another way.
There are still a lot of issues with web-sockets – due to not all proxies 
handling these requests and so have to limit their use in a lot our cases [ a 
lot of our users are on networks that sit behind proxy/cache servers ]

> Due to these reasons, my organization has started looking at ways to move 
> away from mod_perl.

We are using more off the shelf packages for some of our applications – e.g. 
Wordpress as a CMS/Object manager, and yes we are also moving to more front-end 
centric applications. But many of our fundamental pieces of code are still 
working in Apache/mod_perl as it is a better, more-reliable language to work 
with.


On Tue, Aug 4, 2020 at 5:43 AM Wesley Peng 
mailto:m...@yonghua.org>> wrote:
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


--
John Dunlap
CTO | Lariat

Direct:
j...@lariat.co

Customer Service:
877.268.6667
supp...@lariat.co
[cid:image001.png@01D66A7C.046364C0]



-- 
 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]

[Joseph He]

My company uses Perl for web development. It handles real time payment
transactions without any problem. Good software is made by the people not
by the language.

Joseph

On Tue, Aug 4, 2020 at 10:28 AM James Smith  wrote:

>
>
>
>
> *From:* John Dunlap 
> *Sent:* 04 August 2020 15:30
> *To:* Wesley Peng 
> *Cc:* mod_perl list 
> *Subject:* Re: suggestions for perl as web development language [EXT]
>
>
>
> The fundamental and, in my opinion, fatal flaws of mod_per are as follows:
>
> > 1) Concurrency. mod_perl is pretty close to forced to use mpm_prefork
> because very few perl dependencies are thread safe.
>
>
>
> Concurrency in extreme conditions - is actually better when it comes to
> mod_perl than a number of other solutions – e.g. nginx/starman.
> Apache/mod_perl is much better at handling large numbers of simultaneous
> requests than the systems which fork a number of small processes at start
> up to handle requests. You either have to fork a large number of these or
> pray you don’t get large numbers of simultaneous requests. Some of our
> systems have long return times for queries due to the terra/petabyte scale
> of some of our backend servers.
>
>
>
> > 2) mod_perl cannot provide web sockets.
>
>
>
> True – we haven’t really found an excuse for web-sockets although our
> front end “Application Delivery Controller” (which sits in the DMZ) can
> manage proxying requests that need sockets one way and others that don’t
> another way.
>
> There are still a lot of issues with web-sockets – due to not all proxies
> handling these requests and so have to limit their use in a lot our cases [
> a lot of our users are on networks that sit behind proxy/cache servers ]
>
>
>
> > Due to these reasons, my organization has started looking at ways to
> move away from mod_perl.
>
>
>
> We are using more off the shelf packages for some of our applications –
> e.g. Wordpress as a CMS/Object manager, and yes we are also moving to more
> front-end centric applications. But many of our fundamental pieces of code
> are still working in Apache/mod_perl as it is a better, more-reliable
> language to work with.
>
>
>
>
>
> On Tue, Aug 4, 2020 at 5:43 AM Wesley Peng  wrote:
>
> 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
>
>
>
> --
>
> 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.
>

Re: suggestions for perl as web development language [EXT]

[Mark Blackman]

> On 4 Aug 2020, at 17:42, Joseph He  wrote:
> 
> My company uses Perl for web development. It handles real time payment 
> transactions without any problem. Good software is made by the people not by 
> the language.
> 

Agreed, Perl is still fine for server-side work. mod_perl adds less value than 
it used to, though. You can get most of the benefits of mod_perl without the 
complexity. It’s only if you have to do really really unusual things in the 
request cycle where mod_perl helps a lot.

- Mark

Re: suggestions for perl as web development language [EXT]

[Mithun Bhattacharya]

And the point is it is getting very hard to find good perl programmers. It
is much easier to find python programmers who can get the job done.

On Tue, Aug 4, 2020 at 11:43 AM Joseph He  wrote:

> My company uses Perl for web development. It handles real time payment
> transactions without any problem. Good software is made by the people not
> by the language.
>
> Joseph
>
> On Tue, Aug 4, 2020 at 10:28 AM James Smith  wrote:
>
>>
>>
>>
>>
>> *From:* John Dunlap 
>> *Sent:* 04 August 2020 15:30
>> *To:* Wesley Peng 
>> *Cc:* mod_perl list 
>> *Subject:* Re: suggestions for perl as web development language [EXT]
>>
>>
>>
>> The fundamental and, in my opinion, fatal flaws of mod_per are as follows:
>>
>> > 1) Concurrency. mod_perl is pretty close to forced to use mpm_prefork
>> because very few perl dependencies are thread safe.
>>
>>
>>
>> Concurrency in extreme conditions - is actually better when it comes to
>> mod_perl than a number of other solutions – e.g. nginx/starman.
>> Apache/mod_perl is much better at handling large numbers of simultaneous
>> requests than the systems which fork a number of small processes at start
>> up to handle requests. You either have to fork a large number of these or
>> pray you don’t get large numbers of simultaneous requests. Some of our
>> systems have long return times for queries due to the terra/petabyte scale
>> of some of our backend servers.
>>
>>
>>
>> > 2) mod_perl cannot provide web sockets.
>>
>>
>>
>> True – we haven’t really found an excuse for web-sockets although our
>> front end “Application Delivery Controller” (which sits in the DMZ) can
>> manage proxying requests that need sockets one way and others that don’t
>> another way.
>>
>> There are still a lot of issues with web-sockets – due to not all proxies
>> handling these requests and so have to limit their use in a lot our cases [
>> a lot of our users are on networks that sit behind proxy/cache servers ]
>>
>>
>>
>> > Due to these reasons, my organization has started looking at ways to
>> move away from mod_perl.
>>
>>
>>
>> We are using more off the shelf packages for some of our applications –
>> e.g. Wordpress as a CMS/Object manager, and yes we are also moving to more
>> front-end centric applications. But many of our fundamental pieces of code
>> are still working in Apache/mod_perl as it is a better, more-reliable
>> language to work with.
>>
>>
>>
>>
>>
>> On Tue, Aug 4, 2020 at 5:43 AM Wesley Peng  wrote:
>>
>> 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
>>
>>
>>
>> --
>>
>> 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.
>>
>

Re: suggestions for perl as web development language [EXT]

[Mithun Bhattacharya]

mod_perl does have value because it does a more efficient utilization of
resources - this is important when fast response time and scalability is
important. The complexity is a known problem but it is not a mystery box
either - there is enough documentation which explains what has to happen
and what could have gone wrong.

On Tue, Aug 4, 2020 at 11:52 AM Mark Blackman  wrote:

>
>
> > On 4 Aug 2020, at 17:42, Joseph He  wrote:
> >
> > My company uses Perl for web development. It handles real time payment
> transactions without any problem. Good software is made by the people not
> by the language.
> >
>
> Agreed, Perl is still fine for server-side work. mod_perl adds less value
> than it used to, though. You can get most of the benefits of mod_perl
> without the complexity. It’s only if you have to do really really unusual
> things in the request cycle where mod_perl helps a lot.
>
> - Mark

Re: suggestions for perl as web development language [EXT]

[Ruben Safir]

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]

[Ruben Safir]

On Tue, Aug 04, 2020 at 11:42:34AM -0500, Joseph He wrote:
> My company uses Perl for web development. It handles real time payment
> transactions without any problem. Good software is made by the people not
> by the language.
> 

Well, there is that...


> Joseph
> 
> On Tue, Aug 4, 2020 at 10:28 AM James Smith  wrote:
> 
> >
> >
> >
> >
> > *From:* John Dunlap 
> > *Sent:* 04 August 2020 15:30
> > *To:* Wesley Peng 
> > *Cc:* mod_perl list 
> > *Subject:* Re: suggestions for perl as web development language [EXT]
> >
> >
> >
> > The fundamental and, in my opinion, fatal flaws of mod_per are as follows:
> >
> > > 1) Concurrency. mod_perl is pretty close to forced to use mpm_prefork
> > because very few perl dependencies are thread safe.
> >
> >
> >
> > Concurrency in extreme conditions - is actually better when it comes to
> > mod_perl than a number of other solutions – e.g. nginx/starman.
> > Apache/mod_perl is much better at handling large numbers of simultaneous
> > requests than the systems which fork a number of small processes at start
> > up to handle requests. You either have to fork a large number of these or
> > pray you don’t get large numbers of simultaneous requests. Some of our
> > systems have long return times for queries due to the terra/petabyte scale
> > of some of our backend servers.
> >
> >
> >
> > > 2) mod_perl cannot provide web sockets.
> >
> >
> >
> > True – we haven’t really found an excuse for web-sockets although our
> > front end “Application Delivery Controller” (which sits in the DMZ) can
> > manage proxying requests that need sockets one way and others that don’t
> > another way.
> >
> > There are still a lot of issues with web-sockets – due to not all proxies
> > handling these requests and so have to limit their use in a lot our cases [
> > a lot of our users are on networks that sit behind proxy/cache servers ]
> >
> >
> >
> > > Due to these reasons, my organization has started looking at ways to
> > move away from mod_perl.
> >
> >
> >
> > We are using more off the shelf packages for some of our applications –
> > e.g. Wordpress as a CMS/Object manager, and yes we are also moving to more
> > front-end centric applications. But many of our fundamental pieces of code
> > are still working in Apache/mod_perl as it is a better, more-reliable
> > language to work with.
> >
> >
> >
> >
> >
> > On Tue, Aug 4, 2020 at 5:43 AM Wesley Peng  wrote:
> >
> > 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
> >
> >
> >
> > --
> >
> > 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.
> >



-- 
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]

[Mark Blackman]

> On 4 Aug 2020, at 17:58, Mithun Bhattacharya  wrote:
> 
> mod_perl does have value because it does a more efficient utilization of 
> resources - this is important when fast response time and scalability is 
> important. The complexity is a known problem but it is not a mystery box 
> either - there is enough documentation which explains what has to happen and 
> what could have gone wrong.

mod_perl’s relative efficiency can be achieved by other well-known means.

Re: suggestions for perl as web development language [EXT]

[Mithun Bhattacharya]

I am genuinely curious what are these other "well known" means ?

On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  wrote:

>
>
> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  wrote:
> >
> > mod_perl does have value because it does a more efficient utilization of
> resources - this is important when fast response time and scalability is
> important. The complexity is a known problem but it is not a mystery box
> either - there is enough documentation which explains what has to happen
> and what could have gone wrong.
>
> mod_perl’s relative efficiency can be achieved by other well-known means.

Re: suggestions for perl as web development language [EXT]

[Mark Blackman]

> On 4 Aug 2020, at 21:41, Mithun Bhattacharya  wrote:
> 
> I am genuinely curious what are these other "well known" means ?
> 
> On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  > wrote:
> 
> 
> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  > > wrote:
> > 
> > mod_perl does have value because it does a more efficient utilization of 
> > resources - this is important when fast response time and scalability is 
> > important. The complexity is a known problem but it is not a mystery box 
> > either - there is enough documentation which explains what has to happen 
> > and what could have gone wrong.
> 
> mod_perl’s relative efficiency can be achieved by other well-known means.

That would depend on what you mean by  "efficient utilisation of resources”.  
You can get the same general effect, more simply, by running a high-performing 
pre-forking Perl web application server and a web server with a simple 
configuration in front of it ,instead of a complicated Apache+mod_perl 
installation.

That also buys you a nice separation of concerns, the web server handles all 
the complicated host or path rewrites and access control and the Perl app 
focuses on responding to the, now-sanitised, fully normalized, HTTP requests.

- Mark

Re: suggestions for perl as web development language [EXT]

[Mithun Bhattacharya]

Ours is a REST based service so every request has business logic and an
apache+mod_perl instance actually has a better segregation of the
webserver and Perl code - we don't worry about handling the HTTP request
and managing children. We trust Apache will do the right thing and if
something breaks we have a large community of people who can help. All we
worry about is our business logic which well no one can help if we don't
know what we have coded :)

Would you like to share a Perl based webserver which can be guaranteed to
be comparable to apache in terms of reliability and stability ?

On Tue, Aug 4, 2020 at 3:48 PM Mark Blackman  wrote:

>
>
> On 4 Aug 2020, at 21:41, Mithun Bhattacharya  wrote:
>
> I am genuinely curious what are these other "well known" means ?
>
> On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  wrote:
>
>>
>>
>> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  wrote:
>> >
>> > mod_perl does have value because it does a more efficient utilization
>> of resources - this is important when fast response time and scalability is
>> important. The complexity is a known problem but it is not a mystery box
>> either - there is enough documentation which explains what has to happen
>> and what could have gone wrong.
>>
>> mod_perl’s relative efficiency can be achieved by other well-known means.
>
>
> That would depend on what you mean by  "efficient utilisation of
> resources”.  You can get the same general effect, more simply, by running a
> high-performing pre-forking Perl web application server and a web server
> with a simple configuration in front of it ,instead of a complicated
> Apache+mod_perl installation.
>
> That also buys you a nice separation of concerns, the web server handles
> all the complicated host or path rewrites and access control and the Perl
> app focuses on responding to the, now-sanitised, fully normalized, HTTP
> requests.
>
> - Mark
>
>
>
>

Re: suggestions for perl as web development language [EXT]

[Mark Blackman]

> On 4 Aug 2020, at 21:55, Mithun Bhattacharya  wrote:
> 
> Ours is a REST based service so every request has business logic and an 
> apache+mod_perl instance actually has a better segregation of the webserver 
> and Perl code - we don't worry about handling the HTTP request and managing 
> children. We trust Apache will do the right thing and if something breaks we 
> have a large community of people who can help. All we worry about is our 
> business logic which well no one can help if we don't know what we have coded 
> :)
> 
> Would you like to share a Perl based webserver which can be guaranteed to be 
> comparable to apache in terms of reliability and stability ?
> 
> On Tue, Aug 4, 2020 at 3:48 PM Mark Blackman  > wrote:
> 
> 
>> On 4 Aug 2020, at 21:41, Mithun Bhattacharya > > wrote:
>> 
>> I am genuinely curious what are these other "well known" means ?
>> 
>> On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman > > wrote:
>> 
>> 
>> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya > > > wrote:
>> > 
>> > mod_perl does have value because it does a more efficient utilization of 
>> > resources - this is important when fast response time and scalability is 
>> > important. The complexity is a known problem but it is not a mystery box 
>> > either - there is enough documentation which explains what has to happen 
>> > and what could have gone wrong.
>> 
>> mod_perl’s relative efficiency can be achieved by other well-known means.
> 
> That would depend on what you mean by  "efficient utilisation of resources”.  
> You can get the same general effect, more simply, by running a 
> high-performing pre-forking Perl web application server and a web server with 
> a simple configuration in front of it ,instead of a complicated 
> Apache+mod_perl installation.
> 
> That also buys you a nice separation of concerns, the web server handles all 
> the complicated host or path rewrites and access control and the Perl app 
> focuses on responding to the, now-sanitised, fully normalized, HTTP requests.
> 
> - Mark

You would still have something like Apache or Nginx handling the direct 
connection to the client and after all clean-up/rewrite/ACL logic is applied, 
then the HTTP request is passed onto something like 
https://metacpan.org/pod/Starman 

- Mark

Re: suggestions for perl as web development language [EXT]

[Mithun Bhattacharya]

I am not sure I understand - by the time we have decided we need perl why
not go for Apache and even consider an alternate ?

The mod_perl setup can't be the only criteria - we created a sample service
and demonstrated it to everyone in the team what needs to happen and now we
have services cropping up like mushrooms.

On Tue, Aug 4, 2020 at 4:05 PM Mark Blackman  wrote:

>
>
> On 4 Aug 2020, at 21:55, Mithun Bhattacharya  wrote:
>
> Ours is a REST based service so every request has business logic and an
> apache+mod_perl instance actually has a better segregation of the
> webserver and Perl code - we don't worry about handling the HTTP request
> and managing children. We trust Apache will do the right thing and if
> something breaks we have a large community of people who can help. All we
> worry about is our business logic which well no one can help if we don't
> know what we have coded :)
>
> Would you like to share a Perl based webserver which can be guaranteed to
> be comparable to apache in terms of reliability and stability ?
>
> On Tue, Aug 4, 2020 at 3:48 PM Mark Blackman  wrote:
>
>>
>>
>> On 4 Aug 2020, at 21:41, Mithun Bhattacharya  wrote:
>>
>> I am genuinely curious what are these other "well known" means ?
>>
>> On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  wrote:
>>
>>>
>>>
>>> > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  wrote:
>>> >
>>> > mod_perl does have value because it does a more efficient utilization
>>> of resources - this is important when fast response time and scalability is
>>> important. The complexity is a known problem but it is not a mystery box
>>> either - there is enough documentation which explains what has to happen
>>> and what could have gone wrong.
>>>
>>> mod_perl’s relative efficiency can be achieved by other well-known means.
>>
>>
>> That would depend on what you mean by  "efficient utilisation of
>> resources”.  You can get the same general effect, more simply, by running a
>> high-performing pre-forking Perl web application server and a web server
>> with a simple configuration in front of it ,instead of a complicated
>> Apache+mod_perl installation.
>>
>> That also buys you a nice separation of concerns, the web server handles
>> all the complicated host or path rewrites and access control and the Perl
>> app focuses on responding to the, now-sanitised, fully normalized, HTTP
>> requests.
>>
>> - Mark
>>
>
> You would still have something like Apache or Nginx handling the direct
> connection to the client and after all clean-up/rewrite/ACL logic is
> applied, then the HTTP request is passed onto something like
> https://metacpan.org/pod/Starman
>
> - Mark
>
>

RE: suggestions for perl as web development language [EXT]

[James Smith]

Don’t talk to me about nginx/starman – it results in most of the errors with 
concurrency issues we see where I work – but doesn’t report the issues! We just 
see them when users can’t get responses.

The code written in mod_perl had no issues with about 25% of the resources. 
Starman fails under a large numbers of concurrent connections; admittedly some 
of requests can take seconds if not minutes to return (querying terra & peta 
byte scale databases) so it isn’t difficult to generate lots of concurrent 
queries.


From: Mark Blackman 
Sent: 04 August 2020 22:05
To: Mithun Bhattacharya 
Cc: Joseph He ; James Smith ; John 
Dunlap ; Wesley Peng ; mod_perl list 

Subject: Re: suggestions for perl as web development language [EXT]




On 4 Aug 2020, at 21:55, Mithun Bhattacharya 
mailto:mit...@gmail.com>> wrote:

Ours is a REST based service so every request has business logic and an 
apache+mod_perl instance actually has a better segregation of the webserver and 
Perl code - we don't worry about handling the HTTP request and managing 
children. We trust Apache will do the right thing and if something breaks we 
have a large community of people who can help. All we worry about is our 
business logic which well no one can help if we don't know what we have coded :)

Would you like to share a Perl based webserver which can be guaranteed to be 
comparable to apache in terms of reliability and stability ?

On Tue, Aug 4, 2020 at 3:48 PM Mark Blackman 
mailto:m...@blackmans.org>> wrote:



On 4 Aug 2020, at 21:41, Mithun Bhattacharya 
mailto:mit...@gmail.com>> wrote:

I am genuinely curious what are these other "well known" means ?

On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman 
mailto:m...@blackmans.org>> wrote:


> On 4 Aug 2020, at 17:58, Mithun Bhattacharya 
> mailto:mit...@gmail.com>> wrote:
>
> mod_perl does have value because it does a more efficient utilization of 
> resources - this is important when fast response time and scalability is 
> important. The complexity is a known problem but it is not a mystery box 
> either - there is enough documentation which explains what has to happen and 
> what could have gone wrong.

mod_perl’s relative efficiency can be achieved by other well-known means.

That would depend on what you mean by  "efficient utilisation of resources”.  
You can get the same general effect, more simply, by running a high-performing 
pre-forking Perl web application server and a web server with a simple 
configuration in front of it ,instead of a complicated Apache+mod_perl 
installation.

That also buys you a nice separation of concerns, the web server handles all 
the complicated host or path rewrites and access control and the Perl app 
focuses on responding to the, now-sanitised, fully normalized, HTTP requests.

- Mark

You would still have something like Apache or Nginx handling the direct 
connection to the client and after all clean-up/rewrite/ACL logic is applied, 
then the HTTP request is passed onto something like 
https://metacpan.org/pod/Starman 
[metacpan.org]

- Mark




-- 
 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]

[dcook]

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  
Sent: Wednesday, 5 August 2020 5:14 AM
To: André Warnier (tomcat/perl) 
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, wh

Re: suggestions for perl as web development language [EXT]

[Wesley Peng]

Joseph He wrote:
My company uses Perl for web development. It handles real time payment 
transactions without any problem. Good software is made by the people 
not by the language.


Maybe I am weak on this point, but how perl handle types more strictly?
for example,

123 + '456'

this is permitted in perl, and this is dangerous. It is not possible in 
other strong types language.


Thanks.

Re: suggestions for perl as web development language [EXT]

[Wesley Peng]

Hi

Mark Blackman wrote:

mod_perl’s relative efficiency can be achieved by other well-known means.


for example?

thank you.

Re: suggestions for perl as web development language [EXT]

[Ruben Safir]

On Tue, Aug 04, 2020 at 09:48:48PM +0100, Mark Blackman wrote:
> 
> 
> > On 4 Aug 2020, at 21:41, Mithun Bhattacharya  wrote:
> > 
> > I am genuinely curious what are these other "well known" means ?
> > 
> > On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  > > wrote:
> > 
> > 
> > > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  > > > wrote:
> > > 
> > > mod_perl does have value because it does a more efficient utilization of 
> > > resources - this is important when fast response time and scalability is 
> > > important. The complexity is a known problem but it is not a mystery box 
> > > either - there is enough documentation which explains what has to happen 
> > > and what could have gone wrong.
> > 
> > mod_perl’s relative efficiency can be achieved by other well-known means.
> 
> That would depend on what you mean by  "efficient utilisation of resources”.  
> You can get the same general effect, more simply, by running a 
> high-performing pre-forking Perl web application server and a web server with 
> a simple configuration in front of it ,instead of a complicated 
> Apache+mod_perl installation.
> 
> That also buys you a nice separation of concerns, the web server handles all 
> the complicated host or path rewrites and access control and the Perl app 
> focuses on responding to the, now-sanitised, fully normalized, HTTP requests.
> 

Not really and the separtion is not a concern, it is an asset, the most
important one.

To get faster, you would need to move off apache.


> - Mark
> 
> 
> 

-- 
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]

[Mithun Bhattacharya]

Just because the language lets you to relax doesn't mean you
shouldn't apply strict validation of all data being worked on :) I don't
care about it in a two line cron job but more critical components spend a
lot of time on data validation - I am pretty much working in paranoid mode.

If you use Moose you can automatically apply data type checking.

On Tue, Aug 4, 2020 at 7:47 PM Wesley Peng  wrote:

>
>
> Joseph He wrote:
> > My company uses Perl for web development. It handles real time payment
> > transactions without any problem. Good software is made by the people
> > not by the language.
>
> Maybe I am weak on this point, but how perl handle types more strictly?
> for example,
>
> 123 + '456'
>
> this is permitted in perl, and this is dangerous. It is not possible in
> other strong types language.
>
> Thanks.
>

Re: suggestions for perl as web development language [EXT]

[Mithun Bhattacharya]

The question is move off to what ? I don't see alternatives being shared
which blows an apache+mod_perl setup out of the water.

On Tue, Aug 4, 2020 at 7:56 PM Ruben Safir  wrote:

> On Tue, Aug 04, 2020 at 09:48:48PM +0100, Mark Blackman wrote:
> >
> >
> > > On 4 Aug 2020, at 21:41, Mithun Bhattacharya  wrote:
> > >
> > > I am genuinely curious what are these other "well known" means ?
> > >
> > > On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  > wrote:
> > >
> > >
> > > > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  > wrote:
> > > >
> > > > mod_perl does have value because it does a more efficient
> utilization of resources - this is important when fast response time and
> scalability is important. The complexity is a known problem but it is not a
> mystery box either - there is enough documentation which explains what has
> to happen and what could have gone wrong.
> > >
> > > mod_perl’s relative efficiency can be achieved by other well-known
> means.
> >
> > That would depend on what you mean by  "efficient utilisation of
> resources”.  You can get the same general effect, more simply, by running a
> high-performing pre-forking Perl web application server and a web server
> with a simple configuration in front of it ,instead of a complicated
> Apache+mod_perl installation.
> >
> > That also buys you a nice separation of concerns, the web server handles
> all the complicated host or path rewrites and access control and the Perl
> app focuses on responding to the, now-sanitised, fully normalized, HTTP
> requests.
> >
>
> Not really and the separtion is not a concern, it is an asset, the most
> important one.
>
> To get faster, you would need to move off apache.
>
>
> > - Mark
> >
> >
> >
>
> --
> 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]

[Ruben Safir]

On Wed, Aug 05, 2020 at 10:32:39AM +1000, dc...@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]

[jbiskofski]

Mod Perl is awesome. That said, the cool kids today are all about Plack.

Google: Dancer, Mojolicious, Catalyst. These allow you to plugin to all
parts of the HTTP protocol, but obviously not to modify apache
configuration.
Excelent, stable, FAST, production ready HTTP server: Starman
Even faster, but not as proven: Twiggy.

The most common setup would be with an Nginx process in front.

I had a hard time accepting this was a good configuration because for 20
years I had thought of webservers as big giant compiled systems (apache),
but apparently you can now create something just as fast in Perl.



On Tue, Aug 4, 2020 at 5:59 PM Mithun Bhattacharya  wrote:

> The question is move off to what ? I don't see alternatives being shared
> which blows an apache+mod_perl setup out of the water.
>
> On Tue, Aug 4, 2020 at 7:56 PM Ruben Safir  wrote:
>
>> On Tue, Aug 04, 2020 at 09:48:48PM +0100, Mark Blackman wrote:
>> >
>> >
>> > > On 4 Aug 2020, at 21:41, Mithun Bhattacharya 
>> wrote:
>> > >
>> > > I am genuinely curious what are these other "well known" means ?
>> > >
>> > > On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman > > wrote:
>> > >
>> > >
>> > > > On 4 Aug 2020, at 17:58, Mithun Bhattacharya > > wrote:
>> > > >
>> > > > mod_perl does have value because it does a more efficient
>> utilization of resources - this is important when fast response time and
>> scalability is important. The complexity is a known problem but it is not a
>> mystery box either - there is enough documentation which explains what has
>> to happen and what could have gone wrong.
>> > >
>> > > mod_perl’s relative efficiency can be achieved by other well-known
>> means.
>> >
>> > That would depend on what you mean by  "efficient utilisation of
>> resources”.  You can get the same general effect, more simply, by running a
>> high-performing pre-forking Perl web application server and a web server
>> with a simple configuration in front of it ,instead of a complicated
>> Apache+mod_perl installation.
>> >
>> > That also buys you a nice separation of concerns, the web server
>> handles all the complicated host or path rewrites and access control and
>> the Perl app focuses on responding to the, now-sanitised, fully normalized,
>> HTTP requests.
>> >
>>
>> Not really and the separtion is not a concern, it is an asset, the most
>> important one.
>>
>> To get faster, you would need to move off apache.
>>
>>
>> > - Mark
>> >
>> >
>> >
>>
>> --
>> 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]

[Ruben Safir]

On Tue, Aug 04, 2020 at 07:59:01PM -0500, Mithun Bhattacharya wrote:
> The question is move off to what ? I don't see alternatives being shared
> which blows an apache+mod_perl setup out of the water.
> 


Maybe JBoss

really there is none.  mod_perl turns apache into an application server,
and there is not much like it, where it can get you right into the heart
of the Apache response cycle.

If you want something that talks to 3 jsom servers and exposes your data
all over the net, you can do this with mod_perl, but it is not something
that would interest most mod_perl coders.


> On Tue, Aug 4, 2020 at 7:56 PM Ruben Safir  wrote:
> 
> > On Tue, Aug 04, 2020 at 09:48:48PM +0100, Mark Blackman wrote:
> > >
> > >
> > > > On 4 Aug 2020, at 21:41, Mithun Bhattacharya  wrote:
> > > >
> > > > I am genuinely curious what are these other "well known" means ?
> > > >
> > > > On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  > > wrote:
> > > >
> > > >
> > > > > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  > > wrote:
> > > > >
> > > > > mod_perl does have value because it does a more efficient
> > utilization of resources - this is important when fast response time and
> > scalability is important. The complexity is a known problem but it is not a
> > mystery box either - there is enough documentation which explains what has
> > to happen and what could have gone wrong.
> > > >
> > > > mod_perl’s relative efficiency can be achieved by other well-known
> > means.
> > >
> > > That would depend on what you mean by  "efficient utilisation of
> > resources”.  You can get the same general effect, more simply, by running a
> > high-performing pre-forking Perl web application server and a web server
> > with a simple configuration in front of it ,instead of a complicated
> > Apache+mod_perl installation.
> > >
> > > That also buys you a nice separation of concerns, the web server handles
> > all the complicated host or path rewrites and access control and the Perl
> > app focuses on responding to the, now-sanitised, fully normalized, HTTP
> > requests.
> > >
> >
> > Not really and the separtion is not a concern, it is an asset, the most
> > important one.
> >
> > To get faster, you would need to move off apache.
> >
> >
> > > - Mark
> > >
> > >
> > >
> >
> > --
> > 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
> >
> >

-- 
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]

[Mithun Bhattacharya]

Haha my service is meant to be a blackbox - of course it talks to three
different REST services :)

On Tue, Aug 4, 2020 at 8:05 PM Ruben Safir  wrote:

> On Tue, Aug 04, 2020 at 07:59:01PM -0500, Mithun Bhattacharya wrote:
> > The question is move off to what ? I don't see alternatives being shared
> > which blows an apache+mod_perl setup out of the water.
> >
>
>
> Maybe JBoss
>
> really there is none.  mod_perl turns apache into an application server,
> and there is not much like it, where it can get you right into the heart
> of the Apache response cycle.
>
> If you want something that talks to 3 jsom servers and exposes your data
> all over the net, you can do this with mod_perl, but it is not something
> that would interest most mod_perl coders.
>
>
> > On Tue, Aug 4, 2020 at 7:56 PM Ruben Safir  wrote:
> >
> > > On Tue, Aug 04, 2020 at 09:48:48PM +0100, Mark Blackman wrote:
> > > >
> > > >
> > > > > On 4 Aug 2020, at 21:41, Mithun Bhattacharya 
> wrote:
> > > > >
> > > > > I am genuinely curious what are these other "well known" means ?
> > > > >
> > > > > On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman  > > > wrote:
> > > > >
> > > > >
> > > > > > On 4 Aug 2020, at 17:58, Mithun Bhattacharya  > > > wrote:
> > > > > >
> > > > > > mod_perl does have value because it does a more efficient
> > > utilization of resources - this is important when fast response time
> and
> > > scalability is important. The complexity is a known problem but it is
> not a
> > > mystery box either - there is enough documentation which explains what
> has
> > > to happen and what could have gone wrong.
> > > > >
> > > > > mod_perl’s relative efficiency can be achieved by other well-known
> > > means.
> > > >
> > > > That would depend on what you mean by  "efficient utilisation of
> > > resources”.  You can get the same general effect, more simply, by
> running a
> > > high-performing pre-forking Perl web application server and a web
> server
> > > with a simple configuration in front of it ,instead of a complicated
> > > Apache+mod_perl installation.
> > > >
> > > > That also buys you a nice separation of concerns, the web server
> handles
> > > all the complicated host or path rewrites and access control and the
> Perl
> > > app focuses on responding to the, now-sanitised, fully normalized, HTTP
> > > requests.
> > > >
> > >
> > > Not really and the separtion is not a concern, it is an asset, the most
> > > important one.
> > >
> > > To get faster, you would need to move off apache.
> > >
> > >
> > > > - Mark
> > > >
> > > >
> > > >
> > >
> > > --
> > > 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
> > >
> > >
>
> --
> 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]

[Wesley Peng]

jbiskofski wrote:

Excelent, stable, FAST, production ready HTTP server: Starman


yes starman is good. we use it for rest-api service, the app code is 
dancer, whose backend server is starman.


if we need more concurrent handlers, a simple front-proxy like nginx 
would be deployed.


regards.

Re: suggestions for perl as web development language [EXT]

[Mithun Bhattacharya]

Mojo is good but it is specifically for fast non blocking services. If you
are trying to pull up old monolithic applications into the service based
world it might take significant rewrite or you use apache/mod_perl :)

On Tue, Aug 4, 2020 at 8:05 PM jbiskofski  wrote:

> Mod Perl is awesome. That said, the cool kids today are all about Plack.
>
> Google: Dancer, Mojolicious, Catalyst. These allow you to plugin to all
> parts of the HTTP protocol, but obviously not to modify apache
> configuration.
> Excelent, stable, FAST, production ready HTTP server: Starman
> Even faster, but not as proven: Twiggy.
>
> The most common setup would be with an Nginx process in front.
>
> I had a hard time accepting this was a good configuration because for 20
> years I had thought of webservers as big giant compiled systems (apache),
> but apparently you can now create something just as fast in Perl.
>
>
>
> On Tue, Aug 4, 2020 at 5:59 PM Mithun Bhattacharya 
> wrote:
>
>> The question is move off to what ? I don't see alternatives being shared
>> which blows an apache+mod_perl setup out of the water.
>>
>> On Tue, Aug 4, 2020 at 7:56 PM Ruben Safir  wrote:
>>
>>> On Tue, Aug 04, 2020 at 09:48:48PM +0100, Mark Blackman wrote:
>>> >
>>> >
>>> > > On 4 Aug 2020, at 21:41, Mithun Bhattacharya 
>>> wrote:
>>> > >
>>> > > I am genuinely curious what are these other "well known" means ?
>>> > >
>>> > > On Tue, Aug 4, 2020 at 3:37 PM Mark Blackman >> > wrote:
>>> > >
>>> > >
>>> > > > On 4 Aug 2020, at 17:58, Mithun Bhattacharya >> > wrote:
>>> > > >
>>> > > > mod_perl does have value because it does a more efficient
>>> utilization of resources - this is important when fast response time and
>>> scalability is important. The complexity is a known problem but it is not a
>>> mystery box either - there is enough documentation which explains what has
>>> to happen and what could have gone wrong.
>>> > >
>>> > > mod_perl’s relative efficiency can be achieved by other well-known
>>> means.
>>> >
>>> > That would depend on what you mean by  "efficient utilisation of
>>> resources”.  You can get the same general effect, more simply, by running a
>>> high-performing pre-forking Perl web application server and a web server
>>> with a simple configuration in front of it ,instead of a complicated
>>> Apache+mod_perl installation.
>>> >
>>> > That also buys you a nice separation of concerns, the web server
>>> handles all the complicated host or path rewrites and access control and
>>> the Perl app focuses on responding to the, now-sanitised, fully normalized,
>>> HTTP requests.
>>> >
>>>
>>> Not really and the separtion is not a concern, it is an asset, the most
>>> important one.
>>>
>>> To get faster, you would need to move off apache.
>>>
>>>
>>> > - Mark
>>> >
>>> >
>>> >
>>>
>>> --
>>> 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
>>>
>>>

Question about deployment of math computing

[Wesley Peng]

Hi

We do math programming (so called machine learning today) in webserver.
The response would be slow, generally it will take 100ms~500ms to finish 
a request.
For this use case, shall we deploy the code within preforked modperl ,or 
event-driven server like dancer/starman?
(we don't use DB like mysql or other slow IO storage server, all 
arguments were passed to webserver by HTTP POST from client).


Thank you.

Re: Question about deployment of math computing

[Mithun Bhattacharya]

Do you really need a webserver which is providing a blocking service ?

Assuming you are doing some sort of map reduce you would be better of
creating a job queue and placing requests into it. You would have a
separate consumer of the queue which could scale up or down depending upon
how long the job queue is.

On Tue, Aug 4, 2020 at 8:23 PM Wesley Peng  wrote:

> Hi
>
> We do math programming (so called machine learning today) in webserver.
> The response would be slow, generally it will take 100ms~500ms to finish
> a request.
> For this use case, shall we deploy the code within preforked modperl ,or
> event-driven server like dancer/starman?
> (we don't use DB like mysql or other slow IO storage server, all
> arguments were passed to webserver by HTTP POST from client).
>
> Thank you.
>

Re: Question about deployment of math computing

[Wesley Peng]

Hi

Mithun Bhattacharya wrote:

Do you really need a webserver which is providing a blocking service ?


yes, this is a prediction server, which would be deployed in PROD 
environment, the client application would request the prediction server 
for results as scores. You can think it as online recommendation systems.


regards.

RE: Question about deployment of math computing

[dcook]

As Mithun suggested, it's going to be slow regardless of which web server 
option you choose. 

It depends on your application, but if it's a user-facing web application, one 
way would be to have your client application make an API call to your backend, 
the backend enqueues the job in the queue, the queue worker/consumer does the 
work and puts the result in a result store, and your application front-end 
either asynchronously polls (using Javascript) or has a refresh button that 
lets the user check for their predictions/recommendations. 

Or if you don't want to use the job queue, 100-500ms isn't too bad to just do 
an AJAX call from the front-end to your Mod_perl API backend. Have your web 
page load quickly, then do the slow work asynchronously (one way or another). 
That's how most modern user-facing web apps work, and it works pretty well.  

If your app isn't human-facing, then I don't see why a little delay would be a 
problem?

David Cook

-Original Message-
From: Wesley Peng  
Sent: Wednesday, 5 August 2020 11:46 AM
To: modperl@perl.apache.org
Subject: Re: Question about deployment of math computing

Hi

Mithun Bhattacharya wrote:
> Do you really need a webserver which is providing a blocking service ?

yes, this is a prediction server, which would be deployed in PROD environment, 
the client application would request the prediction server for results as 
scores. You can think it as online recommendation systems.

regards.



signature.asc
Description: PGP signature

Re: Question about deployment of math computing

[Wesley Peng]

Hi

dc...@prosentient.com.au wrote:

If your app isn't human-facing, then I don't see why a little delay would be a 
problem?


Our app is not human facing. The application by other department will 
request the result from our app via HTTP.


The company has huge big-data stack deployed, such as 
Hadoop/Flink/Storm/Spark etc, all these solutions have been existing 
there. The data traffic each day is as huge as xx PB.


But, those stacks have complicated privileges control layer, they are 
most time running as backend service, for example, offline analysis, 
feature engineering, and some real time streaming.


We train the modes in backend, and use the stacks mentioned above.

But, once the mode finished training, they will be pushed to online as 
prediction service and serve as HTTP API, b/c third party apps will only 
like to request the interface via HTTP way.


Thanks.

RE: Question about deployment of math computing

[dcook]

That's interesting. After re-reading your earlier email, I think that I 
misunderstood what you were saying.

Since this is a mod_perl listserv, I imagine that the advice will always be to 
use mod_perl rather than starman? 

Personally, I'd say either option would be fine. In my experience, the key 
advantage of mod_perl or starman (say over CGI) is that you can pre-load 
libraries into memory at web server startup time, and that processes are 
persistent (although they do have limited lifetimes of course).

You could use a framework like Catalyst or Mojolicious (note Dancer is another 
framework, but I haven't worked with it) which can support different web 
servers, and then try the different options to see what suits you best. 

One thing to note would be that usually people put a reverse proxy in front of 
starman like Apache or Nginx (partially for serving static assets but other 
reasons as well). Your stack could be less complicated if you just went the 
mod_perl/Apache route. 

That said, what OS are you planning to use? It's worth checking if mod_perl is 
easily available in your target OS's package repositories. I think Red Hat 
dropped mod_perl starting with RHEL 8, although EPEL 8 now has mod_perl in it. 
Something to think about.

David Cook

-Original Message-
From: Wesley Peng  
Sent: Wednesday, 5 August 2020 1:00 PM
To: dc...@prosentient.com.au; modperl@perl.apache.org
Subject: Re: Question about deployment of math computing

Hi

dc...@prosentient.com.au wrote:
> If your app isn't human-facing, then I don't see why a little delay would be 
> a problem?

Our app is not human facing. The application by other department will request 
the result from our app via HTTP.

The company has huge big-data stack deployed, such as Hadoop/Flink/Storm/Spark 
etc, all these solutions have been existing there. The data traffic each day is 
as huge as xx PB.

But, those stacks have complicated privileges control layer, they are most time 
running as backend service, for example, offline analysis, feature engineering, 
and some real time streaming.

We train the modes in backend, and use the stacks mentioned above.

But, once the mode finished training, they will be pushed to online as 
prediction service and serve as HTTP API, b/c third party apps will only like 
to request the interface via HTTP way.

Thanks.



signature.asc
Description: PGP signature

Re: Question about deployment of math computing

[Wesley Peng]

Hi

dc...@prosentient.com.au wrote:

That's interesting. After re-reading your earlier email, I think that I 
misunderstood what you were saying.

Since this is a mod_perl listserv, I imagine that the advice will always be to 
use mod_perl rather than starman?

Personally, I'd say either option would be fine. In my experience, the key 
advantage of mod_perl or starman (say over CGI) is that you can pre-load 
libraries into memory at web server startup time, and that processes are 
persistent (although they do have limited lifetimes of course).

You could use a framework like Catalyst or Mojolicious (note Dancer is another 
framework, but I haven't worked with it) which can support different web 
servers, and then try the different options to see what suits you best.

One thing to note would be that usually people put a reverse proxy in front of 
starman like Apache or Nginx (partially for serving static assets but other 
reasons as well). Your stack could be less complicated if you just went the 
mod_perl/Apache route.

That said, what OS are you planning to use? It's worth checking if mod_perl is 
easily available in your target OS's package repositories. I think Red Hat 
dropped mod_perl starting with RHEL 8, although EPEL 8 now has mod_perl in it. 
Something to think about.


We use ubuntu 16.04 and 18.04.

We do use dancer/starman in product env, but the service only handle 
light weight API requests, for example, a restful api for data validation.


While our math computing is heavy weight service, each request will take 
a lot time to finish, so I think should it be deployed in dancer?


Since the webserver behind dancer is starman by default, starman is 
event driven, it uses very few processes ,and the process can't scale 
up/down automatically.


We deploy starman with 5 processes by default. when 5 requests coming, 
all 5 starman processes are so busy to compute them, so the next request 
will be blocked. is it?


But apache mp is working as prefork way, generally it can have as many 
as thousands of processes if the resource is permitted. And the process 
management can scale up/down the children automatically.


So my real question is, for a CPU consuming service, the event driven 
service like starman, has no advantage than preforked service like Apache.


Am I right?

Thanks.

RE: Question about deployment of math computing

[dcook]

Hi Wesley,

I don't know all the ins and outs of Starman. I do know that Starman is a 
preforking web server, which uses Net::Server::PreFork under the hood. You 
configure the number of preforked workers to correspond with your CPU and 
memory limits for that server. 

As per the Starman documentation 
(https://metacpan.org/pod/release/MIYAGAWA/Starman-0.4015/lib/Starman.pm), you 
should put a frontend server/reverse proxy (like Nginx) in front of Starman. 
Nginx is often recommended because it's event-driven. The idea being that a few 
Nginx workers (rather than those thousands of Apache processes you mentioned) 
can handle a very large volume of HTTP requests, and then Nginx intelligently 
passes those requests to the backend server (e.g. Starman). 

Of course, no matter what, you can still get timeouts if the backend server 
isn't responding fast enough, but typically the backend process is going as 
fast as it can. At that point, your only option is to scale up. You can do that 
by using Nginx as a load balancer and horizontally scaling your Starman 
instances, or you can put more CPUs on that machine, and configure Starman to 
prefork more workers.

Let's say you use Mod_Perl/Apache instead of Starman/Nginx. At the end of the 
day, you still need to think about how many concurrent requests you're needing 
to serve and how many CPUs you have available. If you've configured Apache to 
have too many processes, you're going to overwhelm your server with tasks. You 
need to use reasonable constraints. 

But remember that this isn't specific to Perl/Starman/Nginx/Apache/mod_perl. 
These are concepts that translate to any stack regardless of programming 
language and web server. (Of course, languages like Node.js and Golang have 
some very cool features for dealing with blocking I/O, so that you can make the 
most of the resources you have. That being said, Perl has Mojo/Mojolicious, 
which claims to do non-blocking I/O in Perl. I have yet to try it though. I'm 
skeptical, but could give it a try.)

At the end of the day, it depends on the workload that you're trying to cater 
to.

David Cook

-Original Message-
From: Wesley Peng  
Sent: Wednesday, 5 August 2020 1:31 PM
To: dc...@prosentient.com.au; modperl@perl.apache.org
Subject: Re: Question about deployment of math computing

Hi

dc...@prosentient.com.au wrote:
> That's interesting. After re-reading your earlier email, I think that I 
> misunderstood what you were saying.
> 
> Since this is a mod_perl listserv, I imagine that the advice will always be 
> to use mod_perl rather than starman?
> 
> Personally, I'd say either option would be fine. In my experience, the key 
> advantage of mod_perl or starman (say over CGI) is that you can pre-load 
> libraries into memory at web server startup time, and that processes are 
> persistent (although they do have limited lifetimes of course).
> 
> You could use a framework like Catalyst or Mojolicious (note Dancer is 
> another framework, but I haven't worked with it) which can support different 
> web servers, and then try the different options to see what suits you best.
> 
> One thing to note would be that usually people put a reverse proxy in front 
> of starman like Apache or Nginx (partially for serving static assets but 
> other reasons as well). Your stack could be less complicated if you just went 
> the mod_perl/Apache route.
> 
> That said, what OS are you planning to use? It's worth checking if mod_perl 
> is easily available in your target OS's package repositories. I think Red Hat 
> dropped mod_perl starting with RHEL 8, although EPEL 8 now has mod_perl in 
> it. Something to think about.

We use ubuntu 16.04 and 18.04.

We do use dancer/starman in product env, but the service only handle light 
weight API requests, for example, a restful api for data validation.

While our math computing is heavy weight service, each request will take a lot 
time to finish, so I think should it be deployed in dancer?

Since the webserver behind dancer is starman by default, starman is event 
driven, it uses very few processes ,and the process can't scale up/down 
automatically.

We deploy starman with 5 processes by default. when 5 requests coming, all 5 
starman processes are so busy to compute them, so the next request will be 
blocked. is it?

But apache mp is working as prefork way, generally it can have as many as 
thousands of processes if the resource is permitted. And the process management 
can scale up/down the children automatically.

So my real question is, for a CPU consuming service, the event driven service 
like starman, has no advantage than preforked service like Apache.

Am I right?

Thanks.



signature.asc
Description: PGP signature

Re: Question about deployment of math computing

[Wesley Peng]

Thank you David. That makes thing clear. I have made mistake to think 
starman was event driven, who is really preforked.


I think any preforked server could serve our depolyment better.

Regards.


dc...@prosentient.com.au wrote:

Hi Wesley,

I don't know all the ins and outs of Starman. I do know that Starman is a 
preforking web server, which uses Net::Server::PreFork under the hood. You 
configure the number of preforked workers to correspond with your CPU and 
memory limits for that server.

As per the Starman documentation 
(https://metacpan.org/pod/release/MIYAGAWA/Starman-0.4015/lib/Starman.pm), you 
should put a frontend server/reverse proxy (like Nginx) in front of Starman. 
Nginx is often recommended because it's event-driven. The idea being that a few 
Nginx workers (rather than those thousands of Apache processes you mentioned) 
can handle a very large volume of HTTP requests, and then Nginx intelligently 
passes those requests to the backend server (e.g. Starman).

Of course, no matter what, you can still get timeouts if the backend server 
isn't responding fast enough, but typically the backend process is going as 
fast as it can. At that point, your only option is to scale up. You can do that 
by using Nginx as a load balancer and horizontally scaling your Starman 
instances, or you can put more CPUs on that machine, and configure Starman to 
prefork more workers.

Let's say you use Mod_Perl/Apache instead of Starman/Nginx. At the end of the 
day, you still need to think about how many concurrent requests you're needing 
to serve and how many CPUs you have available. If you've configured Apache to 
have too many processes, you're going to overwhelm your server with tasks. You 
need to use reasonable constraints.

But remember that this isn't specific to Perl/Starman/Nginx/Apache/mod_perl. 
These are concepts that translate to any stack regardless of programming 
language and web server. (Of course, languages like Node.js and Golang have 
some very cool features for dealing with blocking I/O, so that you can make the 
most of the resources you have. That being said, Perl has Mojo/Mojolicious, 
which claims to do non-blocking I/O in Perl. I have yet to try it though. I'm 
skeptical, but could give it a try.)

At the end of the day, it depends on the workload that you're trying to cater 
to.

David Cook

-Original Message-
From: Wesley Peng 
Sent: Wednesday, 5 August 2020 1:31 PM
To: dc...@prosentient.com.au; modperl@perl.apache.org
Subject: Re: Question about deployment of math computing

Hi

dc...@prosentient.com.au wrote:

That's interesting. After re-reading your earlier email, I think that I 
misunderstood what you were saying.

Since this is a mod_perl listserv, I imagine that the advice will always be to 
use mod_perl rather than starman?

Personally, I'd say either option would be fine. In my experience, the key 
advantage of mod_perl or starman (say over CGI) is that you can pre-load 
libraries into memory at web server startup time, and that processes are 
persistent (although they do have limited lifetimes of course).

You could use a framework like Catalyst or Mojolicious (note Dancer is another 
framework, but I haven't worked with it) which can support different web 
servers, and then try the different options to see what suits you best.

One thing to note would be that usually people put a reverse proxy in front of 
starman like Apache or Nginx (partially for serving static assets but other 
reasons as well). Your stack could be less complicated if you just went the 
mod_perl/Apache route.

That said, what OS are you planning to use? It's worth checking if mod_perl is 
easily available in your target OS's package repositories. I think Red Hat 
dropped mod_perl starting with RHEL 8, although EPEL 8 now has mod_perl in it. 
Something to think about.


We use ubuntu 16.04 and 18.04.

We do use dancer/starman in product env, but the service only handle light 
weight API requests, for example, a restful api for data validation.

While our math computing is heavy weight service, each request will take a lot 
time to finish, so I think should it be deployed in dancer?

Since the webserver behind dancer is starman by default, starman is event 
driven, it uses very few processes ,and the process can't scale up/down 
automatically.

We deploy starman with 5 processes by default. when 5 requests coming, all 5 
starman processes are so busy to compute them, so the next request will be 
blocked. is it?

But apache mp is working as prefork way, generally it can have as many as 
thousands of processes if the resource is permitted. And the process management 
can scale up/down the children automatically.

So my real question is, for a CPU consuming service, the event driven service 
like starman, has no advantage than preforked service like Apache.

Am I right?

Thanks.