Re: Shared var between processes
On 21.10.2017 21:20, john edstrom wrote: What about IPC::Shareable? Its for shared memory. I've used it before, but not with Apache. I'm no sure that works well under Windows. (The whole point for me of Apache/perl/mod_perl being that it is multi-platform) There is also memcache, but that's a whole setup, and maybe overkill here. JE On Sat, 2017-10-21 at 08:53 +0200, André Warnier (tomcat) wrote: On 20.10.2017 17:15, Adam Prime wrote: On 17-10-20 05:17 AM, André Warnier (tomcat) wrote: On 20.10.2017 10:50, Ben RUBSON wrote: On 20 Oct 2017 10:38, André Warnier (tomcat) wrote: I believe that there is much more of a performance hit, when asking the server to set up an environment ($ENV) for sub-processes, than via the PerlSetVar mechanism. You don't need to use $ENV. If you're using handlers you could use $r->server()->server_hostname. You could certainly create a big hash at startup and grab stuff out of it that way, where the top level key is the hostname. Assuming that you wanted to do this, where would you put this big hash, so that it is persistent across requests, and can be accessed by mod_perl handlers ? (I have my own scheme to do this, but I'm curious about maybe a better / less "hacky" way) If the data that you want to store is just strings though, this might be overkill. If, however, you want to create deeper datastructures from a somewhere, then this would be a perfectly acceptable way to do that. PerlSetVar is great with just strings, but not for anything any more complicated than that. It does have to be static configuration. All the other limitations that André mentioned are completely accurate though. Adam
Re: Shared var between processes
On 21 Oct 2017 08:53, André Warnier (tomcat) wrote: On 20.10.2017 17:15, Adam Prime wrote: On 17-10-20 05:17 AM, André Warnier (tomcat) wrote: On 20.10.2017 10:50, Ben RUBSON wrote: On 20 Oct 2017 10:38, André Warnier (tomcat) wrote: I believe that there is much more of a performance hit, when asking the server to set up an environment ($ENV) for sub-processes, than via the PerlSetVar mechanism. You don't need to use $ENV. If you're using handlers you could use $r->server()->server_hostname. You could certainly create a big hash at startup and grab stuff out of it that way, where the top level key is the hostname. Assuming that you wanted to do this, where would you put this big hash, so that it is persistent across requests, and can be accessed by mod_perl handlers ? If it's a read-only hash, then a startup script (PerlPostConfigRequire) as Adam proposed before seems to be the right way. Ben
Re: Shared var between processes
On 22.10.2017 09:45, Ben RUBSON wrote: On 21 Oct 2017 08:53, André Warnier (tomcat) wrote: On 20.10.2017 17:15, Adam Prime wrote: On 17-10-20 05:17 AM, André Warnier (tomcat) wrote: On 20.10.2017 10:50, Ben RUBSON wrote: On 20 Oct 2017 10:38, André Warnier (tomcat) wrote: I believe that there is much more of a performance hit, when asking the server to set up an environment ($ENV) for sub-processes, than via the PerlSetVar mechanism. You don't need to use $ENV. If you're using handlers you could use $r->server()->server_hostname. You could certainly create a big hash at startup and grab stuff out of it that way, where the top level key is the hostname. Assuming that you wanted to do this, where would you put this big hash, so that it is persistent across requests, and can be accessed by mod_perl handlers ? If it's a read-only hash, then a startup script (PerlPostConfigRequire) as Adam proposed before seems to be the right way. Yes, but where exactly do you keep that hash, so that it is accessible later on by mod_perl handlers ? (across requests)
Re: Shared var between processes
In our case, we do not use Windows for anything. Even our desktops are Linux. We already employ Redis, which performs the same function as memcache, however, this doesn't really solve the problem because each virtualhost also relies on its own redis database so, even in that case, we would still need a per virtualhost configuration mechanism to tell us which redis database to use. At present, I kinda like Ben Rubson's suggestion of a read only hash in a startup script which is keyed by hostname On Sun, Oct 22, 2017 at 6:29 AM, André Warnier (tomcat) wrote: > On 22.10.2017 09:45, Ben RUBSON wrote: > >> On 21 Oct 2017 08:53, André Warnier (tomcat) wrote: >> >> On 20.10.2017 17:15, Adam Prime wrote: >>> On 17-10-20 05:17 AM, André Warnier (tomcat) wrote: > On 20.10.2017 10:50, Ben RUBSON wrote: > >> On 20 Oct 2017 10:38, André Warnier (tomcat) wrote: >> > I believe that there is much more of a performance hit, when asking > the server to set up > an environment ($ENV) for sub-processes, than via the PerlSetVar > mechanism. > You don't need to use $ENV. If you're using handlers you could use $r->server()->server_hostname. You could certainly create a big hash at startup and grab stuff out of it that way, where the top level key is the hostname. >>> >>> Assuming that you wanted to do this, where would you put this big hash, >>> so that it is >>> persistent across requests, and can be accessed by mod_perl handlers ? >>> >> >> If it's a read-only hash, then a startup script (PerlPostConfigRequire) >> as Adam proposed >> before seems to be the right way. >> > > Yes, but where exactly do you keep that hash, so that it is accessible > later on by mod_perl handlers ? (across requests) > > -- John Dunlap *CTO | Lariat * *Direct:* *j...@lariat.co * *Customer Service:* 877.268.6667 supp...@lariat.co
Re: Shared var between processes
On 22.10.2017 18:59, John Dunlap wrote:
In our case, we do not use Windows for anything. Even our desktops are Linux.
We already
employ Redis, which performs the same function as memcache, however, this
doesn't really
solve the problem because each virtualhost also relies on its own redis
database so, even
in that case, we would still need a per virtualhost configuration mechanism to
tell us
which redis database to use.
At present, I kinda like Ben Rubson's suggestion of a read only hash in a
startup script
which is keyed by hostname
Yes, no doubt about that. But this does not answer the question : where do you store this
hash (or a reference to it), so that a handler, later, would have access to it ?
startup_script :
my $big_hash = {
hostname1 => { ... },
hostname2 => { ... },
};
# save $big_hash "somewhere"
exit;
... later ...
sub handler {
# how do I access $big_hash ? (where is it ?)
return OK;
}
On Sun, Oct 22, 2017 at 6:29 AM, André Warnier (tomcat) mailto:a...@ice-sa.com>> wrote:
On 22.10.2017 09:45, Ben RUBSON wrote:
On 21 Oct 2017 08:53, André Warnier (tomcat) wrote:
On 20.10.2017 17:15, Adam Prime wrote:
On 17-10-20 05:17 AM, André Warnier (tomcat) wrote:
On 20.10.2017 10:50, Ben RUBSON wrote:
On 20 Oct 2017 10:38, André Warnier (tomcat) wrote:
I believe that there is much more of a performance hit,
when asking
the server to set up
an environment ($ENV) for sub-processes, than via the
PerlSetVar
mechanism.
You don't need to use $ENV. If you're using handlers you could
use
$r->server()->server_hostname.
You could certainly create a big hash at startup and grab stuff
out of it
that way, where
the top level key is the hostname.
Assuming that you wanted to do this, where would you put this big
hash, so
that it is
persistent across requests, and can be accessed by mod_perl
handlers ?
If it's a read-only hash, then a startup script (PerlPostConfigRequire)
as Adam
proposed
before seems to be the right way.
Yes, but where exactly do you keep that hash, so that it is accessible
later on by
mod_perl handlers ? (across requests)
--
John Dunlap
/CTO | Lariat/
/
/
/*Direct:*/
/j...@lariat.co /
/
*Customer Service:*/
877.268.6667
supp...@lariat.co
Re: Shared var between processes
At present, I am pulling the values from PerlSetVar and constructing this
hash in a lexical scoped variable. The hash gets a new entry every time the
worker handles a request for a new virtualhost
On Oct 22, 2017 5:15 PM, "André Warnier (tomcat)" wrote:
> On 22.10.2017 18:59, John Dunlap wrote:
>
>> In our case, we do not use Windows for anything. Even our desktops are
>> Linux. We already
>> employ Redis, which performs the same function as memcache, however, this
>> doesn't really
>> solve the problem because each virtualhost also relies on its own redis
>> database so, even
>> in that case, we would still need a per virtualhost configuration
>> mechanism to tell us
>> which redis database to use.
>>
>> At present, I kinda like Ben Rubson's suggestion of a read only hash in a
>> startup script
>> which is keyed by hostname
>>
>
> Yes, no doubt about that. But this does not answer the question : where do
> you store this hash (or a reference to it), so that a handler, later, would
> have access to it ?
>
> startup_script :
>
> my $big_hash = {
> hostname1 => { ... },
> hostname2 => { ... },
> };
> # save $big_hash "somewhere"
> exit;
>
> ... later ...
>
> sub handler {
> # how do I access $big_hash ? (where is it ?)
>
> return OK;
> }
>
>
>
>
>
>> On Sun, Oct 22, 2017 at 6:29 AM, André Warnier (tomcat) > > wrote:
>>
>> On 22.10.2017 09:45, Ben RUBSON wrote:
>>
>> On 21 Oct 2017 08:53, André Warnier (tomcat) wrote:
>>
>> On 20.10.2017 17:15, Adam Prime wrote:
>>
>> On 17-10-20 05:17 AM, André Warnier (tomcat) wrote:
>>
>> On 20.10.2017 10:50, Ben RUBSON wrote:
>>
>> On 20 Oct 2017 10:38, André Warnier (tomcat)
>> wrote:
>>
>> I believe that there is much more of a performance
>> hit, when asking
>> the server to set up
>> an environment ($ENV) for sub-processes, than via the
>> PerlSetVar
>> mechanism.
>>
>>
>> You don't need to use $ENV. If you're using handlers you
>> could use
>> $r->server()->server_hostname.
>>
>> You could certainly create a big hash at startup and grab
>> stuff out of it
>> that way, where
>> the top level key is the hostname.
>>
>>
>> Assuming that you wanted to do this, where would you put this
>> big hash, so
>> that it is
>> persistent across requests, and can be accessed by mod_perl
>> handlers ?
>>
>>
>> If it's a read-only hash, then a startup script
>> (PerlPostConfigRequire) as Adam
>> proposed
>> before seems to be the right way.
>>
>>
>> Yes, but where exactly do you keep that hash, so that it is
>> accessible later on by
>> mod_perl handlers ? (across requests)
>>
>>
>>
>>
>> --
>> John Dunlap
>> /CTO | Lariat/
>> /
>> /
>> /*Direct:*/
>> /j...@lariat.co /
>> /
>> *Customer Service:*/
>> 877.268.6667
>> supp...@lariat.co
>>
>
>
Re: Shared var between processes
On 22 Oct 2017 23:15, André Warnier (tomcat) wrote:
On 22.10.2017 18:59, John Dunlap wrote:
In our case, we do not use Windows for anything. Even our desktops are
Linux. We already
employ Redis, which performs the same function as memcache, however,
this doesn't really
solve the problem because each virtualhost also relies on its own redis
database so, even
in that case, we would still need a per virtualhost configuration
mechanism to tell us
which redis database to use.
At present, I kinda like Ben Rubson's suggestion of a read only hash in
a startup script
which is keyed by hostname
Yes, no doubt about that. But this does not answer the question : where
do you store this hash (or a reference to it), so that a handler, later,
would have access to it ?
startup_script :
my $big_hash = {
hostname1 => { ... },
hostname2 => { ... },
};
# save $big_hash "somewhere"
exit;
... later ...
sub handler {
# how do I access $big_hash ? (where is it ?)
return OK;
}
You can use Startup.pm like this :
package Startup;
use strict;
use warnings;
use base qw(Exporter);
our @EXPORT_OK = qw(%config);
our %config;
$config{'VH1'}{'foo'} = 'nicevalue';
1;
Then in your other scripts :
use Startup qw(%config);
my $var = $config{'VH1'}{'foo'};
Or without a package, if your vars are rather simple, you could use $ENV...
Ben
