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 <m...@blackmans.org> Sent: 04 August 2020 22:05 To: Mithun Bhattacharya <mit...@gmail.com> Cc: Joseph He <joseph.he.2...@gmail.com>; James Smith <j...@sanger.ac.uk>; John Dunlap <j...@lariat.co>; Wesley Peng <m...@yonghua.org>; mod_perl list <modperl@perl.apache.org> Subject: Re: suggestions for perl as web development language [EXT] On 4 Aug 2020, at 21:55, Mithun Bhattacharya <mit...@gmail.com<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 <m...@blackmans.org<mailto:m...@blackmans.org>> wrote: On 4 Aug 2020, at 21:41, Mithun Bhattacharya <mit...@gmail.com<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 <m...@blackmans.org<mailto:m...@blackmans.org>> wrote: > On 4 Aug 2020, at 17:58, Mithun Bhattacharya > <mit...@gmail.com<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]<https://urldefense.proofpoint.com/v2/url?u=https-3A__metacpan.org_pod_Starman&d=DwMFaQ&c=D7ByGjS34AllFgecYw0iC6Zq7qlm8uclZFI0SqQnqBo&r=oH2yp0ge1ecj4oDX0XM7vQ&m=9Iq3_XmWnDBY_X_sLWU5TBxlUOACnWsTzq5FSwl4lps&s=-fjwi06iac3C4zq2yJFdm8lAb8927XTfCwOHbFBwvzk&e=> - 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.
