Re^2: How do I make a PSGI program do costly initialisation only once per process, not per thread?

unless I’m missing something

Indeed; you did not run thrall and couldn't make the crucial observations of the difference to plackup yourself.

With plackup, the initialisation happens only once, when main is called. It is easy to notice that the server only starts accepting connections three seconds after executing plackup. So the characteristics of the bad performance are at server start-up, only once, happening under the sysadmin's control - this is altogether acceptable. An end user never gets to experience it: either the server is down, or it's up and always responding fast. The example program does not show it, but there's one db connection.

With thrall, the server starts accepting connections almost immediately. However, each request runs the initialisation separately. I surmise this happens for each spawned thread until the pool is filled, afterwards requests are handled fast on each thread. So the characteristics of the bad performance are at unforeseeable times after the server has been started, up to --max-workers several times, happening under no one's control - this is altogether not acceptable. The user experience is spotty: works fast for most requests, especially when the server had already been running for some amount of requests, but when bad luck strikes and the request happens to be handled by a new thread, the server responds slowly. The example program does not show it, but there are up to --max-workers db connections, and the operations team does not appreciate that.

Comment on Re^2: How do I make a PSGI program do costly initialisation only once per process, not per thread? Select or Download Code

Replies are listed 'Best First'.
Re^3: How do I make a PSGI program do costly initialisation only once per process, not per thread? by Corion (Patriarch) on Jun 01, 2017 at 14:54 UTC
The simple approach is to prime the cache of worker threads by spawning your server and then making requests to your server from `localhost` just so that each thread connects to the database. Otherwise, you will have to consult the documentation of your server as to what hooks it offers and how to take advantage of them. Looking at Thrall::Server, it seems that it simply creates a new thread in `->_create_thread`. You could override that or do your initialisation in a BEGIN block, or use a threads::shared variable to share information between your threads.	[reply] [d/l] [select]
Re^3: How do I make a PSGI program do costly initialisation only once per process, not per thread? by vr (Curate) on Jun 01, 2017 at 13:51 UTC
To comment out line #38 (`loader => 'Delayed'`) in thrall.bat? Setting environment variable `PERL_THRALL_DEBUG=1`, and adding something like `say "...in main, thread is ", threads-> tid;` into "main" of your app might help to debug. Will this change to .bat break anything? I don't know, but...	[reply] [d/l] [select]
Re^4: How do I make a PSGI program do costly initialisation only once per process, not per thread? by daxim (Curate) on Jun 07, 2017 at 11:02 UTC
comment out line #38 (loader => 'Delayed') in thrall.bat You hit the nail on the head, bravo! So to make this crystal clear, the loader type is responsible for the difference in initialisation, not the server type itself, and with thrall, the delayed loading is on purpose. Will this change to .bat break anything? Yes, very much. It appears there is a lot of thread-unsafe code in my application. Let me show y'all a bizarre example: `use JSON qw(encode_json); my $app = sub { return [200, [], [encode_json [] ]] };` [download] With plackup, the response is `[]`. With thrall but no Delayed loader, the response is `Internal Server Error`, the exception `hash- or arrayref expected (not a simple scalar, use allow_nonref to allow this) at …`.	[reply] [d/l] [select]