MESSAGE
| DATE | 2020-12-20 |
| FROM | Mithun Bhattacharya
|
| SUBJECT | Re: [Hangout - NYLXS] suggestions for perl as web development
|
From hangout-bounces-at-nylxs.com Tue Dec 22 15:34:18 2020
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: from www2.mrbrklyn.com (www2.mrbrklyn.com [96.57.23.82])
by mrbrklyn.com (Postfix) with ESMTP id E235B164032;
Tue, 22 Dec 2020 15:34:16 -0500 (EST)
X-Original-To: hangout-at-www2.mrbrklyn.com
Delivered-To: hangout-at-www2.mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 1000)
id 80A05163FC1; Tue, 22 Dec 2020 15:32:28 -0500 (EST)
Resent-From: Ruben Safir
Resent-Date: Tue, 22 Dec 2020 15:32:28 -0500
Resent-Message-ID: <20201222203228.GR17865-at-www2.mrbrklyn.com>
Resent-To: hangout-at-mrbrklyn.com
X-Original-To: ruben-at-mrbrklyn.com
Delivered-To: ruben-at-mrbrklyn.com
Received: from mxout1-ec2-va.apache.org (mxout1-ec2-va.apache.org
[3.227.148.255]) by mrbrklyn.com (Postfix) with ESMTP id 2BE57164022
for ; Sun, 20 Dec 2020 17:28:51 -0500 (EST)
Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153])
by mxout1-ec2-va.apache.org (ASF Mail Server at
mxout1-ec2-va.apache.org) with SMTP id 420C144F07
for ; Sun, 20 Dec 2020 22:28:51 +0000 (UTC)
Received: (qmail 1932 invoked by uid 500); 20 Dec 2020 22:28:50 -0000
Mailing-List: contact modperl-help-at-perl.apache.org; run by ezmlm
Precedence: bulk
Delivered-To: mailing list modperl-at-perl.apache.org
Received: (qmail 1921 invoked by uid 99); 20 Dec 2020 22:28:50 -0000
Received: from spamproc1-he-fi.apache.org (HELO spamproc1-he-fi.apache.org)
(95.217.134.168)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 20 Dec 2020 22:28:50 +0000
Received: from localhost (localhost [127.0.0.1])
by spamproc1-he-fi.apache.org (ASF Mail Server at spamproc1-he-fi.apache.org)
with ESMTP id C275BC0110
for ; Sun, 20 Dec 2020 22:28:49 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at spamproc1-he-fi.apache.org
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=6.31
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, SPF_PASS=-0.001]
autolearn=disabled
Authentication-Results: spamproc1-he-fi.apache.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from mx1-he-de.apache.org ([116.203.227.195])
by localhost (spamproc1-he-fi.apache.org [95.217.134.168]) (amavisd-new,
port 10024) with ESMTP id HlE-94jn7P2C for ;
Sun, 20 Dec 2020 22:28:48 +0000 (UTC)
Received-SPF: Pass (mailfrom) identity=mailfrom;
client-ip=2607:f8b0:4864:20::e34; helo=mail-vs1-xe34.google.com;
envelope-from=mithnb-at-gmail.com; receiver=
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com
[IPv6:2607:f8b0:4864:20::e34])
by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS
id EEAE27FBA7
for ; Sun, 20 Dec 2020 22:28:47 +0000 (UTC)
Received: by mail-vs1-xe34.google.com with SMTP id e15so4425720vsa.0
for ; Sun, 20 Dec 2020 14:28:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=XOANW5m86K2IrlXhn1MMNiEqVjBk2o3wy8lGFz7Zchc=;
b=bxFDvfniX0azFnxoPoFrEq/a2pPvYUQH9YzDuK9u8Aq6wFBkpZdPA2nyWBme2AAQhM
bPBgxt7w77Ga4z8LTp8dx3T6rXr+Y1GBlAfezybdgj4giTr3EXFvFqkgk0nZZYaR6NVM
WZ6pdPSK+3UIKqsNpk7HGRXLVGabQlzE9RSJ+eevstTWRPIftHQp4Xsuq/4SUc1Cmqet
ljSOdYXl3uBTLVhDsLb+dcBi+vDJIvMqnScGPIMfcJzJoaXANgzwCG6cr1ud0XgnsEMI
/8tA6h0bE2j3ieXIIECgin3aI4Zkjl4N5DcjXqaKRyCNEm6ZMx6TVLigJnNcENGdKzjP
AWaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=XOANW5m86K2IrlXhn1MMNiEqVjBk2o3wy8lGFz7Zchc=;
b=TXCoNNj0PeA24qTfMZpPVCOc/0+MyBxwfLqsl7C9QVSDi9GRJnkMpFoohtLoi7RKHM
e4Eb2lpwfdJW/gLPPNSBvOSPsc0OF1TYslkM0a2x3tEi4EqV1PIekFePgwHSXqALYbRm
EcnyCKhxzaZAMyInBAQaXQ1Y9Mkn881fArPrfLZYNCv3NzqGYkKl4hIPcKhBPqh9/VGn
fmvEJi1VcJtt3Gu9MNWsWcM3w8FhnkJFcuKf3Aw7p/+TCqOnpMPOhNpwWe7djMIlExDO
F68017FruXTibvRwaE9QgHHyX8FLxe36VAKVJeipy5oFIMoD6dGPJBQZzcQxOB4I7BK6
RAig==
X-Gm-Message-State: AOAM530tifCTifT35KAA71alYGQDZBkWiUWMz7feDayJJW+XfxaJfDqV
1eQcdgLk/q78/xyU/hPiP9N7OOrdUPU/ipl0g1nq4ERQlNE=
X-Google-Smtp-Source: ABdhPJzly2r4lYhcq9CamBJZplZUM5Cyca9EjUisEUoHaTPE98NFOoKz6gP5RfwqL3LmZDYLlRBgpN1p34tmuBDL0/U=
X-Received: by 2002:a67:1dc4:: with SMTP id d187mr10066998vsd.53.1608503326194;
Sun, 20 Dec 2020 14:28:46 -0800 (PST)
MIME-Version: 1.0
References:
<27779c3e56564c73a7fa49b49cc3f9f0-at-sanger.ac.uk>
In-Reply-To:
From: Mithun Bhattacharya
Date: Sun, 20 Dec 2020 16:28:35 -0600
Message-ID:
To: mod_perl list
Subject: Re: [Hangout - NYLXS] suggestions for perl as web development
language [EXT]
X-BeenThere: hangout-at-nylxs.com
X-Mailman-Version: 2.1.30rc1
List-Id: NYLXS Tech Talk and Politics
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Content-Type: multipart/mixed; boundary="===============0409146619=="
Errors-To: hangout-bounces-at-nylxs.com
Sender: "Hangout"
--===============0409146619==
Content-Type: multipart/alternative; boundary="00000000000060bf4705b6ecddd8"
--00000000000060bf4705b6ecddd8
Content-Type: text/plain; charset="UTF-8"
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 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
> 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 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
>>> wrote:
>>>
>>>> Agreed prefork is recommended but what is the problem with that ?
>>>>
>>>> On Sun, Dec 20, 2020 at 12:47 PM John Dunlap wrote:
>>>>
>>>>> Our app segfaults at random of we use anything other than prefork.
>>>>>
>>>>> On Sun, Dec 20, 2020, 1:32 PM Mithun Bhattacharya
>>>>> 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 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 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
>>>>>>>> Sent: 04 August 2020 06:43
>>>>>>>> To: modperl-at-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.
>>>>>>>
>>>>>>>
--00000000000060bf4705b6ecddd8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Running individual functions in independent=C2=A0threads c=
an't be a solution for performance optimization - at least I have never=
heard such a thing, maybe others can pitch in.
l_quote"> 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">r=3D"auto">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 p=
oint 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 indivi=
dual function calls in separate threads. Perl, by contrast, will only have =
a single thread per request.
=3D"ltr" class=3D"gmail_attr">On Sun, Dec 20, 2020, 3:33 PM Mithun Bhattach= arya < mithnb-at-gmail=
.com> wrote: gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">You would have to define poor system performance - are=
you doing anything cpu intensive at all ? Maybe your RAM is being the bott=
leneck ?
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=3D"auto">It's extremely inefficient by comparison. We host our applica=
tion on beefy servers with 32 cores and 64G of ram and I commonly see poor =
system performance with less than 25% cpu utilization.
=3D"gmail_quote"> = left:1px solid rgb(204,204,204);padding-left:1ex">Agreed p=
refork is recommended but what is the problem with that ?
ss=3D"gmail_quote"> On Sun, Dec 20, 20= 20 at 12:47 PM John Dunlap < eferrer noreferrer" target=3D"_blank">John-at-lariat.co> wrote: v> r-left:1px solid rgb(204,204,204);padding-left:1ex">Our a=
pp segfaults at random of we use anything other than prefork.
class=3D"gmail_quote">x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=3D"ltr">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 with=
out any issues.
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">In my opinion, no one should build =
new projects in Perl. The world is increasingly trending towards parallelis=
m and higher numbers of cpu cores and Perl is poorly positioned to leverage=
these advancements. Many of Perl's dependencies are not thread safe an=
d mod_perl forces you to use mpm_prefork. My organization has started movin=
g away from Perl to Elixir for these reasons.
quote"> On Tue, Aug 4, 2020, 3:37 AM J= ames Smith < rrer noreferrer" target=3D"_blank">js5-at-sanger.ac.uk> wrote: > -left:1px solid rgb(204,204,204);padding-left:1ex">Perl is a great solution=
for web development.
Others will disagree but the best way I still believe is using mod_perl - b=
ut only if you use it's full power - and you probably need a special so=
rt 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 stab=
le {dancer etc does not cope well with either large requests or lots of sma=
ll requests}, and (b) if you have a large code base and/or a large number o=
f 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 tra=
nslation, AAA stages, pre-processing, to post-processing and logging, and a=
lso to interact with other languages at any stage - e.g. can handle pre-pro=
cessing & post-processing around a script written in another language (=
e.g. PHP, Java) or produced by another webserver integrated by mod_proxy.r>
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 th=
emselves although there are libraries out there to do lots of it.
We have an in house library whose embryonic stages were written over 20 yea=
rs ago - and has now been stable for around 12-13 years and works strong...=
James
-----Original Message-----
From: Wesley Peng <oreferrer noreferrer noreferrer" target=3D"_blank">me-at-yonghua.org> <=
br>
Sent: 04 August 2020 06:43
To: noreferrer noreferrer" target=3D"_blank">modperl-at-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 peopl=
e to do the webdev job with perl.
Do you think in today we will give up perl/modperl as web development langu=
age, and choose the alternatives instead?
Thanks & Regards
--
=C2=A0The Wellcome Sanger Institute is operated by Genome Research
=C2=A0Limited, a charity registered in England with number 1021457 and a r>
=C2=A0company registered in England with number 2742969, whose registered <=
br>
=C2=A0office is 215 Euston Road, London, NW1 2BE.
--00000000000060bf4705b6ecddd8--
--===============0409146619==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
--===============0409146619==--
--===============0409146619==
Content-Type: multipart/alternative; boundary="00000000000060bf4705b6ecddd8"
--00000000000060bf4705b6ecddd8
Content-Type: text/plain; charset="UTF-8"
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 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
> 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 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
>>> wrote:
>>>
>>>> Agreed prefork is recommended but what is the problem with that ?
>>>>
>>>> On Sun, Dec 20, 2020 at 12:47 PM John Dunlap wrote:
>>>>
>>>>> Our app segfaults at random of we use anything other than prefork.
>>>>>
>>>>> On Sun, Dec 20, 2020, 1:32 PM Mithun Bhattacharya
>>>>> 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 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 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
>>>>>>>> Sent: 04 August 2020 06:43
>>>>>>>> To: modperl-at-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.
>>>>>>>
>>>>>>>
--00000000000060bf4705b6ecddd8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Running individual functions in independent=C2=A0threads c=
an't be a solution for performance optimization - at least I have never=
heard such a thing, maybe others can pitch in.
l_quote"> 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">r=3D"auto">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 p=
oint 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 indivi=
dual function calls in separate threads. Perl, by contrast, will only have =
a single thread per request.
=3D"ltr" class=3D"gmail_attr">On Sun, Dec 20, 2020, 3:33 PM Mithun Bhattach= arya < mithnb-at-gmail=
.com> wrote: gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">You would have to define poor system performance - are=
you doing anything cpu intensive at all ? Maybe your RAM is being the bott=
leneck ?
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=3D"auto">It's extremely inefficient by comparison. We host our applica=
tion on beefy servers with 32 cores and 64G of ram and I commonly see poor =
system performance with less than 25% cpu utilization.
=3D"gmail_quote"> = left:1px solid rgb(204,204,204);padding-left:1ex">Agreed p=
refork is recommended but what is the problem with that ?
ss=3D"gmail_quote"> On Sun, Dec 20, 20= 20 at 12:47 PM John Dunlap < eferrer noreferrer" target=3D"_blank">John-at-lariat.co> wrote: v> r-left:1px solid rgb(204,204,204);padding-left:1ex">Our a=
pp segfaults at random of we use anything other than prefork.
class=3D"gmail_quote">x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=3D"ltr">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 with=
out any issues.
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">In my opinion, no one should build =
new projects in Perl. The world is increasingly trending towards parallelis=
m and higher numbers of cpu cores and Perl is poorly positioned to leverage=
these advancements. Many of Perl's dependencies are not thread safe an=
d mod_perl forces you to use mpm_prefork. My organization has started movin=
g away from Perl to Elixir for these reasons.
quote"> On Tue, Aug 4, 2020, 3:37 AM J= ames Smith < rrer noreferrer" target=3D"_blank">js5-at-sanger.ac.uk> wrote: > -left:1px solid rgb(204,204,204);padding-left:1ex">Perl is a great solution=
for web development.
Others will disagree but the best way I still believe is using mod_perl - b=
ut only if you use it's full power - and you probably need a special so=
rt 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 stab=
le {dancer etc does not cope well with either large requests or lots of sma=
ll requests}, and (b) if you have a large code base and/or a large number o=
f 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 tra=
nslation, AAA stages, pre-processing, to post-processing and logging, and a=
lso to interact with other languages at any stage - e.g. can handle pre-pro=
cessing & post-processing around a script written in another language (=
e.g. PHP, Java) or produced by another webserver integrated by mod_proxy.r>
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 th=
emselves although there are libraries out there to do lots of it.
We have an in house library whose embryonic stages were written over 20 yea=
rs ago - and has now been stable for around 12-13 years and works strong...=
James
-----Original Message-----
From: Wesley Peng <oreferrer noreferrer noreferrer" target=3D"_blank">me-at-yonghua.org> <=
br>
Sent: 04 August 2020 06:43
To: noreferrer noreferrer" target=3D"_blank">modperl-at-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 peopl=
e to do the webdev job with perl.
Do you think in today we will give up perl/modperl as web development langu=
age, and choose the alternatives instead?
Thanks & Regards
--
=C2=A0The Wellcome Sanger Institute is operated by Genome Research
=C2=A0Limited, a charity registered in England with number 1021457 and a r>
=C2=A0company registered in England with number 2742969, whose registered <=
br>
=C2=A0office is 215 Euston Road, London, NW1 2BE.
--00000000000060bf4705b6ecddd8--
--===============0409146619==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Hangout mailing list
Hangout-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout
--===============0409146619==--
|
|
