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) <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 <j...@lariat.co>* *Customer Service:* 877.268.6667 supp...@lariat.co
