The issue, at least for us, has very little to do with static files as we are already serving them from a CDN(AWS Cloudfront). We have a very large ember.js application which, on our more complicated screens, can hit the server 5+ times fetching data just to render the page(all 5+ requests are initiated simultaneously). We follow a SOFEA(Service Oriented Front End Architecture) design pattern so we try to build a web service API in mod_perl and then call it from ember-data. We can then tell our customers that anything they can do through our UI can also be done through our API. This helps us kill 2 birds with 1 stone. However, this also means that we can't create web service endpoints which have a 1:1 correspondence with our UI and we often have to hit the server 5-6 times to render the page(once for each drop down box, once per data grid, etc). In this use case, the concurrency limitations of mod_perl and http/1.1 have become an issue for us. We've tried throwing bigger servers and memory caches at the problem but that isn't always enough at peak hours. It's rare that a week goes by that someone doesn't report slowness at one point or another. Our best remaining options are to decrease the number of customers(our application uses a sharded tenancy model) on each server or attempt to scale horizontally(which would require some rework to stop storing files on the web server) and both options increase our hosting costs. We've had extensive discussions about this problem internally and, In the absence of a better MPM and http/2 support, our best option appears to be putting a more performant web server in front of Apache, proxying dynamic requests to Apache, and re-writing our more commonly used endpoints in a language with a better concurrency model. However, taking that step would effectively begin our migration away from perl. I know mod_perl has a lot of features that aren't available in other languages but none of them are an absolute necessity in our use case and I will be unable to justify staying on mod_perl if it means ceding fundamental technical advantages to our competitors. I was hopeful that sponsoring some development could improve mod_perl's concurrency model but if mod_perl and http/2 are "fundamentally incompatible", as Mark said, then perhaps we have outgrown mod_perl.
On Wed, Feb 6, 2019 at 9:30 AM Pavel Merdin <pvl1-removt...@merdin.com> wrote: > Hi. > Sorry I'm late in taking a part in the conversation. > > I agree with Mark on many points. > Just wanted to add that if static content is served via a CDN (which it > should ideally) then maybe there is not much point rushing to support > HTTP/2 purely for dynamic content. I'm sure HTTP/1.1 will stay for a while > anyway. > If static content is served by the same server then it perfectly makes > sense to add something like nginx to the frontend to serve static content. > It can also even cache some slow changing dynamic content if needed (making > user experience better). > Even with custom authentication handlers nginx supports internal > redirects, so it's possible to free up perl a process and still serve > static files via nginx no matter how slow the clients are to get it. > > On Mon, 28 Jan 2019 at 20:38, Mark Blackman <m...@blackmans.org> wrote: > >> >> >> On 27 Jan 2019, at 20:13, William A Rowe Jr <wr...@rowe-clan.net> wrote: >> >> On Fri, Jan 25, 2019 at 11:35 AM John Dunlap <j...@lariat.co> wrote: >> >>> I'm in the process of optimizing our web application for performance and >>> one thing that I was really excited to try was mod_http2 because it allows >>> the browser to send multiple requests through the same TCP connection with >>> compressed headers. However, when I enabled it and restarted apache I was >>> greeted with this: >>> >>> [Fri Jan 25 12:30:57.813355 2019] [http2:warn] [pid 10186] AH10034: The >>> mpm module (prefork.c) is not supported by mod_http2. The mpm determines >>> how things are processed in your server. HTTP/2 has more demands in this >>> regard and the currently selected mpm will just not do. This is an advisory >>> warning. Your server will continue to work, but the HTTP/2 protocol will be >>> inactive. >>> >> >> To this question, the answer should be blatantly obvious; http2 doesn't >> simply support multiple requests (connection: keepalive solved that) >> but supports parallel requests. This clearly isn't compatible with any >> single-threaded/single-worker per connection strategy. >> >> A hybrid mod_prefork could be coded to dispatch all worker requests >> across to distinct worker processes for a single connection, but I >> don't anticipate anyone interested in doing such development. >> >> >>> The last time I tried to use either mpm_worker or mpm_event my >>> application was plagued by seemingly random segfaults. Are there any plans >>> to support other MPM's? If not, the benefits of HTTP2 appear to be >>> permanently out of reach for our mod_perl applications and that, honestly, >>> might force us into seriously reevaluating our technology stack. :( >>> >> >> Your compatibility with the worker MPM is likely much stronger than >> with the event MPM; however... all request workers can behave in a >> "free threaded" manner under mod_http2, eliminating the relative >> simplicity of the worker MPM. Working out each and any of these >> specific segfaults occurs is the only way to improve the situation. >> >> For the general mod_perl activity to increase, the Apache Perl Project >> needs active volunteers and contributions. Consider this entire thread >> an open invitation to participate. >> >> >> Given that Perl is single-threaded by design and history and has no >> reliable support for threading, I think that mod_perl and direct http/2 >> support in the same instance are probably fundamentally incompatible. I.e. >> if you have 10 perl threads running (each in a single process), then it >> doesn’t matter if you can multiplex 20 http/2 connections, they will all >> just block. If you’re very attached to mod_perl, you should already be >> using a 2-tier strategy anyway, with N fat mod_perl Apache instances >> handling only HTTP/1.1 requests and a second front-end proxy layer of >> whatever front-end proxy makes sense handling HTTP/2 requests for both >> static and dynamic content requests. This was standard advice 20 years ago >> as far as I recall and is even more prudent now. >> >> - Mark >> > -- John Dunlap *CTO | Lariat * *Direct:* *j...@lariat.co <j...@lariat.co>* *Customer Service:* 877.268.6667 supp...@lariat.co
