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).
