Mailing List Archive

Shared var between processes
Hi,

I'm trying to share a var between the different processes of my prefork
Apache.

I then tried the following idea :
$r->server()->dir_config('var','val');
Unfortunately, $r->server()->dir_config('var') is not shared among the
processes.
I would have thought config was stored at the very first Apache process
(the parent) level.

Other solution is IPC::Shareable (one more module to load :-/)

Any other solution ?
I would have been happy with an Apache-only way to do this (like I tried
above).

I need the var to be set only one time to a constant random value, then to
be read by the different processes.
I then also thought about an environment variable set when Apache starts,
and then given to Perl using "PerlSetVar var ${VAR}".
But 1. var value would be disclosed into Apache env which I want to avoid,
2. PerlSetVar at every request is perhaps not really perfect in terms of
performance.

Thank you very much for your help !

Ben
Re: Shared var between processes [ In reply to ]
If it doesn't need to change then you should be able to set it in
PerlPostConfigRequire code, and it will then be available to all
children in copy on write memory (ie any change will only affect the
process that changed it.)

https://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_File

Adam


On 17-10-19 12:11 PM, Ben RUBSON wrote:
> Hi,
>
> I'm trying to share a var between the different processes of my prefork
> Apache.
>
> I then tried the following idea :
> $r->server()->dir_config('var','val');
> Unfortunately, $r->server()->dir_config('var') is not shared among the
> processes.
> I would have thought config was stored at the very first Apache process
> (the parent) level.
>
> Other solution is IPC::Shareable (one more module to load :-/)
>
> Any other solution ?
> I would have been happy with an Apache-only way to do this (like I tried
> above).
>
> I need the var to be set only one time to a constant random value, then
> to be read by the different processes.
> I then also thought about an environment variable set when Apache
> starts, and then given to Perl using "PerlSetVar var ${VAR}".
> But 1. var value would be disclosed into Apache env which I want to
> avoid, 2. PerlSetVar at every request is perhaps not really perfect in
> terms of performance.
>
> Thank you very much for your help !
>
> Ben
>
Re: Shared var between processes [ In reply to ]
Nice, perfect, just tested, working perfectly !
Thank you very much Adam !

Ben


On 19 Oct 2017 18:39, Adam Prime wrote:

> If it doesn't need to change then you should be able to set it in
> PerlPostConfigRequire code, and it will then be available to all children
> in copy on write memory (ie any change will only affect the process that
> changed it.)
>
> https://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_File
>
> Adam
>
>
> On 17-10-19 12:11 PM, Ben RUBSON wrote:
>> Hi,
>> I'm trying to share a var between the different processes of my prefork
>> Apache.
>> I then tried the following idea :
>> $r->server()->dir_config('var','val');
>> Unfortunately, $r->server()->dir_config('var') is not shared among the
>> processes.
>> I would have thought config was stored at the very first Apache process
>> (the parent) level.
>> Other solution is IPC::Shareable (one more module to load :-/)
>> Any other solution ?
>> I would have been happy with an Apache-only way to do this (like I tried
>> above).
>> I need the var to be set only one time to a constant random value, then
>> to be read by the different processes.
>> I then also thought about an environment variable set when Apache
>> starts, and then given to Perl using "PerlSetVar var ${VAR}".
>> But 1. var value would be disclosed into Apache env which I want to
>> avoid, 2. PerlSetVar at every request is perhaps not really perfect in
>> terms of performance.
>> Thank you very much for your help !
>> Ben
Re: Shared var between processes [ In reply to ]
To piggy back onto this question, what is the best way to do this such that
the values of the variables are different for every virtual host? In our
model, all virtual hosts shared the same interpreter pool but we need to
have different configuration variables on a per virtualhost basis.
Currently, we are using PerlSetVar for this purpose.

On Thu, Oct 19, 2017 at 3:57 PM, Ben RUBSON <ben.rubson@gmail.com> wrote:

> Nice, perfect, just tested, working perfectly !
> Thank you very much Adam !
>
> Ben
>
>
>
> On 19 Oct 2017 18:39, Adam Prime wrote:
>
> If it doesn't need to change then you should be able to set it in
>> PerlPostConfigRequire code, and it will then be available to all children
>> in copy on write memory (ie any change will only affect the process that
>> changed it.)
>>
>> https://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_File
>>
>> Adam
>>
>>
>> On 17-10-19 12:11 PM, Ben RUBSON wrote:
>>
>>> Hi,
>>> I'm trying to share a var between the different processes of my prefork
>>> Apache.
>>> I then tried the following idea :
>>> $r->server()->dir_config('var','val');
>>> Unfortunately, $r->server()->dir_config('var') is not shared among the
>>> processes.
>>> I would have thought config was stored at the very first Apache process
>>> (the parent) level.
>>> Other solution is IPC::Shareable (one more module to load :-/)
>>> Any other solution ?
>>> I would have been happy with an Apache-only way to do this (like I tried
>>> above).
>>> I need the var to be set only one time to a constant random value, then
>>> to be read by the different processes.
>>> I then also thought about an environment variable set when Apache
>>> starts, and then given to Perl using "PerlSetVar var ${VAR}".
>>> But 1. var value would be disclosed into Apache env which I want to
>>> avoid, 2. PerlSetVar at every request is perhaps not really perfect in
>>> terms of performance.
>>> Thank you very much for your help !
>>> Ben
>>>
>>
>
>


--
John Dunlap
*CTO | Lariat *

*Direct:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co
Re: Shared var between processes [ In reply to ]
On 19.10.2017 22:02, John Dunlap wrote:
> To piggy back onto this question, what is the best way to do this such that the values of
> the variables are different for every virtual host? In our model, all virtual hosts shared
> the same interpreter pool but we need to have different configuration variables on a per
> virtualhost basis. Currently, we are using PerlSetVar for this purpose.

And that seems the right way to me.

As log as you remember that a VirtualHost is not really a "process". It is a
"configuration block", which any Apache process/thread starting to handle a HTTP request
will first "load", before it starts processing a request destined to that VirtualHost.
In that configuration block, somewhere there is the digested form of that
PerlSetVar name "value"
directive.
By (dynamically) retrieving this "value" by means of a
$value = $r->dir_config(name)
you are just retrieving (dynamically, now) the (fixed) "value" set (earlier) in that
configuration directive, and assigning this value to the local variable $value.
After that, any change which you may make to $value, is purely local and never re-written
into the VirtualHost configuration block.
So the next HTTP request, even if it is for the same VirtualHost, will still see the
original "value" that was set in the configuration file.

It is only when you want to modify this value at some point, and to "leak" this new value
to other HTTP requests, that things become a bit more complicated.

Schematically :
1) the HTTP request "arrives" at the Apache httpd main process
2) the httpd main process looks for (or starts) a child process or thread, to handle this
request, and hands it off to that child. The main httpd now goes back to listening
forother requests.
3) the selected child parses the request, and (via the "Host:" header), determines to
which VirtualHost this is addressed
4) the child loads the configuration of that particular VirtualHost
5) the child starts processing the HTTP request, in function of this now-loaded configuration
(and thus also only the PerlSetVar directives that are part of the configuration of /that/
VirtualHost; it never sees the directives of the other VirtuaHosts)




>
> On Thu, Oct 19, 2017 at 3:57 PM, Ben RUBSON <ben.rubson@gmail.com
> <mailto:ben.rubson@gmail.com>> wrote:
>
> Nice, perfect, just tested, working perfectly !
> Thank you very much Adam !
>
> Ben
>
>
>
> On 19 Oct 2017 18:39, Adam Prime wrote:
>
> If it doesn't need to change then you should be able to set it in
> PerlPostConfigRequire code, and it will then be available to all children in copy
> on write memory (ie any change will only affect the process that changed it.)
>
> https://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_File
> <https://perl.apache.org/docs/2.0/user/handlers/server.html#Startup_File>
>
> Adam
>
>
> On 17-10-19 12:11 PM, Ben RUBSON wrote:
>
> Hi,
> I'm trying to share a var between the different processes of my prefork Apache.
> I then tried the following idea :
> $r->server()->dir_config('var','val');
> Unfortunately, $r->server()->dir_config('var') is not shared among the processes.
> I would have thought config was stored at the very first Apache process (the
> parent) level.
> Other solution is IPC::Shareable (one more module to load :-/)
> Any other solution ?
> I would have been happy with an Apache-only way to do this (like I tried above).
> I need the var to be set only one time to a constant random value, then to be
> read by the different processes.
> I then also thought about an environment variable set when Apache starts, and
> then given to Perl using "PerlSetVar var ${VAR}".
> But 1. var value would be disclosed into Apache env which I want to avoid, 2.
> PerlSetVar at every request is perhaps not really perfect in terms of performance.
> Thank you very much for your help !
> Ben
>
>
>
>
>
>
> --
> John Dunlap
> /CTO | Lariat/
> /
> /
> /*Direct:*/
> /john@lariat.co <mailto:john@lariat.co>/
> /
> *Customer Service:*/
> 877.268.6667
> support@lariat.co <mailto:support@lariat.co>
Re: Shared var between processes [ In reply to ]
On 20 Oct 2017 10:38, André Warnier (tomcat) wrote:

> On 19.10.2017 22:02, John Dunlap wrote:
>> To piggy back onto this question, what is the best way to do this such
>> that the values of
>> the variables are different for every virtual host? In our model, all
>> virtual hosts shared
>> the same interpreter pool but we need to have different configuration
>> variables on a per
>> virtualhost basis. Currently, we are using PerlSetVar for this purpose.
>
> And that seems the right way to me.

What about a startup file, as proposed by Adam, which would return John's
configuration variables according to $ENV{'SERVER_NAME'} ? (using a
switch/case for example)
Each virtualhost would then have its own configuration variables, having a
uniq startup file for the whole server.

Would it be more performant than the PerlSetVar solution ? (doc sometimes
warns about PerlSet* performance)

Thx !

Ben
Re: Shared var between processes [ In reply to ]
On 20.10.2017 10:50, Ben RUBSON wrote:
> On 20 Oct 2017 10:38, André Warnier (tomcat) wrote:
>
>> On 19.10.2017 22:02, John Dunlap wrote:
>>> To piggy back onto this question, what is the best way to do this such that the values of
>>> the variables are different for every virtual host? In our model, all virtual hosts shared
>>> the same interpreter pool but we need to have different configuration variables on a per
>>> virtualhost basis. Currently, we are using PerlSetVar for this purpose.
>>
>> And that seems the right way to me.
>
> What about a startup file, as proposed by Adam, which would return John's configuration
> variables according to $ENV{'SERVER_NAME'} ? (using a switch/case for example)
> Each virtualhost would then have its own configuration variables, having a uniq startup
> file for the whole server.
>
> Would it be more performant than the PerlSetVar solution ? (doc sometimes warns about
> PerlSet* performance)
>
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.

In any case, we use the PerlSetVar mechanism extensively, for dozens of servers and/or
VirtualHosts,
and there has never been any noticeable performance issue linked to this.

Think about the mechanism : the Apache httpd configuration files get read and parsed
*once*, at the time of the server start (or server "reload"). After that, everything is
stored in some large pre-parsed configuration table, with sub-sections for each
VirtualHost. This table is copied to (or shared by) each Apache sub-process (or thread),
always.
When one of these sub-processes makes a dir_config() call, this just looks into this
pre-processed configuration table.
In comparison, the mechanism involving the environment has to set up this environment
repeatedly (at least each time a new Apache sub-process is started). (It also would have
to do this for each cgi-bin script call, if it was not handled under mod_perl).
That is bound to be less efficient than the configuration method.

Also, I do not see what advantage there would be for having a set of separate
supplementary files that need to be read and parsed separately, as compared to having that
stuff in the Apache configuration files in the first place.
(Except maybe if you do not have full access to the Apache configuration files, in terms
of permissions e.g.; but that can be solved in other ways).
It seems much more maintainable (and documentable) to have everything in one place.

The only real issue with PerlSetVar, is that of course it only is "retrievable" by perl things
running under mod_perl. (You could not retrieve such a value from a shell script running
as a cgi-bin for example; so if you have a mixture of such things, you may /still/ need to
use $ENV, for the non-perl things).
Re: Shared var between processes [ In reply to ]
On 20 Oct 2017 11:17, André Warnier (tomcat) wrote:

> On 20.10.2017 10:50, Ben RUBSON wrote:
>> On 20 Oct 2017 10:38, André Warnier (tomcat) wrote:
>>
>>> On 19.10.2017 22:02, John Dunlap wrote:
>>>> To piggy back onto this question, what is the best way to do this such
>>>> that the values of
>>>> the variables are different for every virtual host? In our model, all
>>>> virtual hosts shared
>>>> the same interpreter pool but we need to have different configuration
>>>> variables on a per
>>>> virtualhost basis. Currently, we are using PerlSetVar for this purpose.
>>>
>>> And that seems the right way to me.
>>
>> What about a startup file, as proposed by Adam, which would return
>> John's configuration
>> variables according to $ENV{'SERVER_NAME'} ? (using a switch/case for
>> example)
>> Each virtualhost would then have its own configuration variables, having
>> a uniq startup
>> file for the whole server.
>>
>> Would it be more performant than the PerlSetVar solution ? (doc
>> sometimes warns about
>> PerlSet* performance)
> 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.
>
> (...)
>
> In comparison, the mechanism involving the environment has to set up this
> environment repeatedly (at least each time a new Apache sub-process is
> started).

Thank you for your deeply detailed answer André !

I think mod_perl already sets $ENV by default, at least $ENV{'SERVER_NAME'}
is set.
Is there an additional cost to simply read $ENV{'SERVER-NAME'} ?
Goal would then be to set another variable according to it.

(that said, there is also $s->server_hostname() to retrieve server name)

> It seems much more maintainable (and documentable) to have everything in
> one place.

I agree :)

Thank you !

Ben
Re: Shared var between processes [ In reply to ]
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. 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 [ In reply to ]
On 20.10.2017 11:36, Ben RUBSON wrote:
> On 20 Oct 2017 11:17, André Warnier (tomcat) wrote:
>
>> On 20.10.2017 10:50, Ben RUBSON wrote:
>>> On 20 Oct 2017 10:38, André Warnier (tomcat) wrote:
>>>
>>>> On 19.10.2017 22:02, John Dunlap wrote:
>>>>> To piggy back onto this question, what is the best way to do this such that the
>>>>> values of
>>>>> the variables are different for every virtual host? In our model, all virtual hosts
>>>>> shared
>>>>> the same interpreter pool but we need to have different configuration variables on a per
>>>>> virtualhost basis. Currently, we are using PerlSetVar for this purpose.
>>>>
>>>> And that seems the right way to me.
>>>
>>> What about a startup file, as proposed by Adam, which would return John's configuration
>>> variables according to $ENV{'SERVER_NAME'} ? (using a switch/case for example)
>>> Each virtualhost would then have its own configuration variables, having a uniq startup
>>> file for the whole server.
>>>
>>> Would it be more performant than the PerlSetVar solution ? (doc sometimes warns about
>>> PerlSet* performance)
>> 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.
>>
>> (...)
>>
>> In comparison, the mechanism involving the environment has to set up this environment
>> repeatedly (at least each time a new Apache sub-process is started).
>
> Thank you for your deeply detailed answer André !
>
> I think mod_perl already sets $ENV by default, at least $ENV{'SERVER_NAME'} is set.
> Is there an additional cost to simply read $ENV{'SERVER-NAME'} ?
> Goal would then be to set another variable according to it.
>
> (that said, there is also $s->server_hostname() to retrieve server name)

Ok, this tells us that you are using mod_perl for more than just running perl cgi-bin
scripts, apparently.

That whole question of "environment" probably deserves a more comprehensive analysis and
description, because some of its aspects are a bit confusing (for example, what exactly is
an "Apache environment variable").

I'm just going to list some aspects here, and not really try to go in depth about them (in
part because there are many things which still puzzle me too). (Sufficiently advanced
technology cannot easily be distinguished from magic).

First, there are the values which are set in the environment of Apache httpd itself, by
whatever startup script starts Apache. (See for example, under Linux/Unix, the
/etc/Apache2/envvars script; and under Windows, the "system" and "user" variables).
Presumably, these values are duplicated whenever Apache forks itself into "children".

Second, there are values which Apache httpd sets up in the environment of the
sub-processes which it starts by itself. One example of this is when Apache httpd runs a
cgi-bin script (whether this is a perl cgi-bin script or else).

Then there are values which are set up by an Apache configuration directive "SetEnv" (or
via some other slightly more obscure mechanisms like mod_rewrite).
This is described in the Apache httpd documentation (for SetEnv/SetEnvIf) as :
"Sets an internal environment variable, which is then available to Apache HTTP Server
modules, and passed on to CGI scripts and SSI pages."

Then there are values set up when mod_perl starts up within Apache, via the "PerlRequire"
and/or "PerlSetEnv" directives which you may find (under Linux Debian/Ubuntu) in
/etc/apache2/mods-enabled/perl.conf.
Those, presumably, apply to the perl interpreter(s) which are loaded as a "side-effect" of
loading mod_perl. And they would presumably apply to anything run by mod_perl later on,
but not by non-perl "things".
A question there, is whether such values would be available to a process started by a perl
"exec" or "system" instruction run from a mod_perl handler.

Then there are the "PerlSetVar" directives, which are not really any kind of environment
values at all, but are just stored in whatever structure (at the Apache level, or only at
the mod_perl level) results from Apache (and mod_perl) parsing the Apache configuration
files. (And can be retrieved via "dir_config()").

Then there are whatever modifications you own mod_perl code may do to the content of %ENV
(and whether this is persistent or not across requests handled by the same child process;
or whether that is passed into the environment of sub-processes run via "system()" e.g.).

Then there are some perl variables which you may declare (within a handler) as "package
variables" and which (due to the fact that the perl interpreter does not restart at each
request), are kind of persistent and shared between requests (but only within the lifetime
of one Apache child). And thus, at least "delicate" to use.

Then there are values which you can store in "$r->notes()" or "$r->pnotes()", which are,
as far as I am aware, only persistent along the processing of one request.

(And in the above list, I am probably still forgetting a couple of places where you can
store things).

It is a bit confusing sometimes to try to figure out the "scope" of these things..

I am using a bit of each of the above in my own web applications, but I must admit that
this is based more on common sense, and intuition, and some generic understanding of how
Apache and mod_perl work, rather than on any precise and comprehensive existing
documentation which one could refer to.
(Or at least, I haven't found such documentation until now).
Re: Shared var between processes [ In reply to ]
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 [ In reply to ]
What about IPC::Shareable? Its for shared memory. I've used it before,
but not with Apache.

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
--
john edstrom <edstrom@teleport.com>
Re: Shared var between processes [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 reply to ]
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) <aw@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:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co
Re: Shared var between processes [ In reply to ]
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) <aw@ice-sa.com
> <mailto:aw@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:*/
> /john@lariat.co <mailto:john@lariat.co>/
> /
> *Customer Service:*/
> 877.268.6667
> support@lariat.co <mailto:support@lariat.co>
Re: Shared var between processes [ In reply to ]
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)" <aw@ice-sa.com> 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) <aw@ice-sa.com
>> <mailto:aw@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:*/
>> /john@lariat.co <mailto:john@lariat.co>/
>> /
>> *Customer Service:*/
>> 877.268.6667
>> support@lariat.co <mailto:support@lariat.co>
>>
>
>
Re: Shared var between processes [ In reply to ]
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