Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

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

by Your Mother (Archbishop)
on Jun 01, 2017 at 11:17 UTC ( [id://1191831]=note: print w/replies, xml ) Need Help??


in reply to How do I make a PSGI program do costly initialisation only once per process, not per thread?

You’re measuring oddly or the wrong part, maybe? It will never take less than 3 seconds to connect to the mock DB server, because that’s just what the code calls for. The connection to the webapp and its responses are not related though—the $app sub is initialized, holding a DB handle, ready to execute—and seems to be perfectly zippy unless I’m missing something–

moo@cow[21]~>plackup pm-1191821 HTTP::Server::PSGI: Accepting connections at http://0:5000/ -- moo@cow[701]~>time curl http://0:5000/ connect took 3.1313986862815 seconds 0.004u 0.004s 0:00.00 0.0% 0+0k 0+0io 0pf+0w

Here it the same with some internal timing code–

use Time::HiRes qw( sleep gettimeofday tv_interval ); # ... sub main { state $db_handle = mock_connect(+shift); sub { my $t0 = [ gettimeofday ]; [ 200, [], [ sprintf "Application sub took %.6f seconds\n", tv_interval( $t0, [ gettimeofday ] ) ] ]; }; } # ... __END__ moo@cow[56]~>curl http://0:5000/ Application sub took 0.000001 seconds moo@cow[57]~>curl http://0:5000/ Application sub took 0.000002 seconds

Replies are listed 'Best First'.
Re^2: How do I make a PSGI program do costly initialisation only once per process, not per thread?
by daxim (Curate) on Jun 01, 2017 at 13:10 UTC
    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.

      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.

      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...
        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 [] ]] };
        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 ….

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1191831]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (8)
As of 2024-03-28 09:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found