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 <j...@lariat.co> wrote:
> It's extremely inefficient by comparison. We host our application on beefy
> servers with 32 cores and 64G of ram and I commonly see poor system
> performance with less than 25% cpu utilization.
>
> On Sun, Dec 20, 2020, 2:22 PM Mithun Bhattacharya <mit...@gmail.com>
> wrote:
>
>> Agreed prefork is recommended but what is the problem with that ?
>>
>> On Sun, Dec 20, 2020 at 12:47 PM John Dunlap <j...@lariat.co> wrote:
>>
>>> Our app segfaults at random of we use anything other than prefork.
>>>
>>> On Sun, Dec 20, 2020, 1:32 PM Mithun Bhattacharya <mit...@gmail.com>
>>> wrote:
>>>
>>>> I am confused - you like threads so Perl is bad ? I am very happy
>>>> forking away and yes I work a lot with non thread safe DBI connections
>>>> without any issues.
>>>>
>>>> On Sun, Dec 20, 2020 at 11:53 AM John Dunlap <j...@lariat.co> wrote:
>>>>
>>>>> In my opinion, no one should build new projects in Perl. The world is
>>>>> increasingly trending towards parallelism and higher numbers of cpu cores
>>>>> and Perl is poorly positioned to leverage these advancements. Many of
>>>>> Perl's dependencies are not thread safe and mod_perl forces you to use
>>>>> mpm_prefork. My organization has started moving away from Perl to Elixir
>>>>> for these reasons.
>>>>>
>>>>> On Tue, Aug 4, 2020, 3:37 AM James Smith <j...@sanger.ac.uk> wrote:
>>>>>
>>>>>> Perl is a great solution for web development.
>>>>>>
>>>>>> Others will disagree but the best way I still believe is using
>>>>>> mod_perl - but only if you use it's full power - and you probably need a
>>>>>> special sort of mind set to use - but that can be said for any language.
>>>>>>
>>>>>> From experience - it may be fractionally slower than small
>>>>>> "standalone" apps that dancer etc are good at, but it is (a) much, much
>>>>>> more stable {dancer etc does not cope well with either large requests or
>>>>>> lots of small requests}, and (b) if you have a large code base and/or a
>>>>>> large number of services then it generally uses much less compute power
>>>>>> than the others {can easily handle multiple services on a single apache
>>>>>> instance}
>>>>>>
>>>>>> Where it really gains is the hooks into the apache process - being
>>>>>> able to add functionality easily at any stage in the request process,
>>>>>> from
>>>>>> path translation, AAA stages, pre-processing, to post-processing and
>>>>>> logging, and also to interact with other languages at any stage - e.g.
>>>>>> can
>>>>>> handle pre-processing & post-processing around a script written in
>>>>>> another
>>>>>> language (e.g. PHP, Java) or produced by another webserver integrated by
>>>>>> mod_proxy.
>>>>>>
>>>>>> It isn't really a framework though like dancer or mojolicious and
>>>>>> thus has its own advantages and disadvantages.
>>>>>>
>>>>>> You would to some extent have to roll your own code to produce the
>>>>>> pages themselves although there are libraries out there to do lots of it.
>>>>>>
>>>>>> We have an in house library whose embryonic stages were written over
>>>>>> 20 years ago - and has now been stable for around 12-13 years and works
>>>>>> strong...
>>>>>>
>>>>>> James
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Wesley Peng <m...@yonghua.org>
>>>>>> Sent: 04 August 2020 06:43
>>>>>> To: modperl@perl.apache.org
>>>>>> Subject: suggestions for perl as web development language [EXT]
>>>>>>
>>>>>> greetings,
>>>>>>
>>>>>> My team use all of perl, ruby, python for scripting stuff.
>>>>>> perl is stronger for system admin tasks, and data analysis etc.
>>>>>> But for web development, it seems to be not as popular as others.
>>>>>> It has less selective frameworks, and even we can't get the right
>>>>>> people to do the webdev job with perl.
>>>>>> Do you think in today we will give up perl/modperl as web development
>>>>>> language, and choose the alternatives instead?
>>>>>>
>>>>>> Thanks & Regards
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> The Wellcome Sanger Institute is operated by Genome Research
>>>>>> Limited, a charity registered in England with number 1021457 and a
>>>>>> company registered in England with number 2742969, whose registered
>>>>>> office is 215 Euston Road, London, NW1 2BE.
>>>>>
>>>>>
