When does it make sense to preload modules when starting Starman?

[karlgoethebier]

To be honest: I have no idea. Reading the less or more friendly manuals didn’t help me very much to jump to a conclusion.

Thank you very much in advance for any hint and advice.

Best regards, Karl.

[Corion]

IMO it makes sense to preload modules if these modules take a long time to initialize and you have a good chance of sharing their data among the forked copies.

Examples I can think of are caching some (largish) resources in memory, or modules that autogenerate lots of code.

Database connections sound interesting, but usually, DBI database handles need to be reinitialized after a fork() call, so that won't work.

[karlgoethebier]

"... modules take a long time to initialize..."

Ja, ja or yes sure as you like. This is what common sense tells us.

But consider this funny little study i recently posted:

# app.psgi
use strict;
use warnings;
use Plack::Request;
use Plack::App::URLMap;
use JSON::Tiny qw(encode_json);

my $slash = sub {
    my $env = shift;
    my $json = encode_json {nose => 'cuke'};
    my $status  = 200;
    my $request = Plack::Request->new($env);
    my $headers = [
        'Content-Type'   => 'application/json',
        'Content-Length' => length $json,
    ];
    my $body = [ $json ];
    [ $status, $headers, $body ];
};

my $urlmap = Plack::App::URLMap->new;

$urlmap->mount( "/" => $slash );

my $app = $urlmap->to_app;

__END__

Preloading the Plack stuff? JSON::Tiny might be cheap but who knows.

It is really difficult to find answers for these questions.

And what if i daemonize Starman? The switches for this task are confusing.

Thanks for your kind reply and best regards, Karl.

P.S.: I asked the author. Probably he will enlight us.

[LanX]

> > "... modules take a long time to initialize..."

> It is really difficult to find answers for these questions.

Is it? To benchmark initialization, measure time in BEGIN, CHECK and INIT blocks.

From what I heard is Moose a good candidate.

[perlfan]

preloading in general makes sense when you are able to amortize the upfront penalty from start up over the lifetime of the running application. So if you have a highly stable application that's never restarted, then it's probably worth a few minutes of "warm up" time at the start. If you're going to be restarting often or the preload is simply too much work for the reward, then you're better off lazily loading at runtime via require.

Update - I thought I should add what I knew to be true (at some point) and isn't a secret, cPanel pays people a a lot of money to maintain a build infrastructure that uses B::C to generate a binary from Perl simply to improve start up time of their administrative daemon, cpservd. Basically, many MBs of initializations and module loads are shoved into a BEGIN{}. The binary is the state of the perl start up through BEGIN (like what you get by invoking perl -c). My point is that this is also an option - if you have a lot of stuff to preload, B::C can be used to get you into a state where start up actually picks up after BEGIN.

[karlgoethebier]

Holy Joe! I just wanted to be on the Bright Side of Life.

Something like starman -Mstrict -Mwarnings -MPlack::Request -MPlack::App::URLMap -MPlack::App::URLMap. If the syntax is so. Untested. "Fire up and forget about it" was the basic theme. But i guess that i'm forced to do some forensics. Sometimes some things go totally wrong with a good cause. I wrote a very friendly email to the author. Result: undef. Regards, Karl