Probably an obvious question, but I just want to be certain.
If I have multiple virtual-hosts on a server, should each vhost have it’s own
rt database created, such as ‘rt3_’ - or can they all use the same
database: ‘rt3’?
I get the feeling either way would work, but I’m wondering what the “best
practice” would be - advice?
If the vhosts in question were wholly separate/non-associated
domains/users/accounts/whatever, it seems that sharing the same database
would be a poor choice.
Probably an obvious question, but I just want to be certain.
If I have multiple virtual-hosts on a server, should each vhost have it’s own
rt database created, such as ‘rt3_’ - or can they all use the same
database: ‘rt3’?
I get the feeling either way would work, but I’m wondering what the “best
practice” would be - advice?
If the vhosts in question were wholly separate/non-associated
domains/users/accounts/whatever, it seems that sharing the same database
would be a poor choice.
If I understand your question correctly, you MUST
have separate databases, although you can certainly share the
same database engine. The whole point of separate instances
is so they can be, well, separate. Use the same database,
and all your instances will have exactly the same queues,
tickets, users, and so on.
If I have multiple virtual-hosts on a server, should each vhost have it’s
own rt database created, such as ‘rt3_’ - or can they all use the
same database: ‘rt3’?
> If I understand your question correctly, you MUST
> have separate databases,
>
Thanks - and uh yeah, you understood my question correctly, as ridiculous as
it was.
Due to a rather creative interpretation of the $rtname option, I had got the
sudden notion that there was a possibility that RT was (somehow) able to
internally separate different instances within the same database…
If I have multiple virtual-hosts on a server, should each vhost have it’s
own rt database created, such as ‘rt3_’ - or can they all use the
same database: ‘rt3’?
> If I understand your question correctly, you MUST
> have separate databases,
>
Thanks - and uh yeah, you understood my question correctly, as ridiculous as
it was.
Due to a rather creative interpretation of the $rtname option, I had got the
sudden notion that there was a possibility that RT was (somehow) able to
internally separate different instances within the same database…
You also need separate RT/perl instances. If you are using mod_perl
you will need to switch to FastCGI.
Hello!On Sun, 2006-02-19 at 13:54 -0500, Todd Chapman wrote:
You also need separate RT/perl instances. If you are using mod_perl
you will need to switch to FastCGI.
… or fire up two separate instances of apache running with separate
config files on separate ports; this will then give you two separate
mod_perl instances. My colleague Russell worked this out.
… or fire up two separate instances of apache running with separate
config files on separate ports; this will then give you two separate
mod_perl instances. My colleague Russell worked this out.
Would this be possible to do (with mod_perl) per virtual host?
Paulo Matos
|Sys & Net Admin | Centro de Informática |
|Faculdade de Ciências e Tecnologia | Tel: +351-21-2948596 |
|Universidade Nova de Lisboa | Fax: +351-21-2948548 |
|P-2829-516 Caparica | e-Mail: pjsm@fct.unl.pt |
… or fire up two separate instances of apache running with separate
config files on separate ports; this will then give you two separate
mod_perl instances. My colleague Russell worked this out.
Would this be possible to do (with mod_perl) per virtual host?
No. (See the wiki). mod_perl, itself, loads once per
apache server, so is shared among all virtual hosts
of that parent apache process. Therefore all virtual hosts
have the same RT library, including the RT config file,
and therefore use the same RT instance.
Hello!On Wed, 2006-03-08 at 15:18 +0000, Paulo Matos wrote:
On Tue, 21 Feb 2006, Jim Meyer wrote:
… or fire up two separate instances of apache running with separate
config files on separate ports; this will then give you two separate
mod_perl instances. My colleague Russell worked this out.
Would this be possible to do (with mod_perl) per virtual host?
I don’t think so. In a virtual host setup, there’s one common instance
of apache running forked into multiple children, all sharing on instance
of the perl interpreter (libperl.so) running, thus you’re tied to one RT
install … or so my understanding goes.
As I mentioned, it was my colleague who researched the details and he
came to the conclusion that it wasn’t possible.
Would this be possible to do (with mod_perl) per virtual host?
No. (See the wiki). mod_perl, itself, loads once per
apache server, so is shared among all virtual hosts
of that parent apache process. Therefore all virtual hosts
have the same RT library, including the RT config file,
and therefore use the same RT instance.
Strange?
What about mod_perl2 config directives:
PerlOptions +Parent
or
PerlOptions +Clone
I’ve never played with mod_perl2. Yes, the docs seems to
indicate this would work.
Continuing to display my ignorance I’d think this means
that each apache child would then have a perl interpreter
and namespace for each RT instance. So if you have 10 RT
instances, one of which is really busy, you might spawn
20 apache children, each of which has 10 perl interpreters.
As opposed to fcgi, where you could have 20 fcgi processes
for the busy RT instance, and 1 each for the other 9
RT instances, therefore 29 fcgi/perl interpreters in memory,
as opposed to 200. Although a lot would be paged out.
Would this be possible to do (with mod_perl) per virtual host?
No. (See the wiki). mod_perl, itself, loads once per
apache server, so is shared among all virtual hosts
of that parent apache process. Therefore all virtual hosts
have the same RT library, including the RT config file,
and therefore use the same RT instance.
Strange?
What about mod_perl2 config directives:
PerlOptions +Parent
or
PerlOptions +Clone
I’ve never played with mod_perl2. Yes, the docs seems to
indicate this would work.
And it’s really works.
Bob, I think next paragraph is wrong, AFAIK MP2 creates pool of
interpreters on server start and clone/create new ones only when there
is no available in pool.
Continuing to display my ignorance I’d think this means
that each apache child would then have a perl interpreter
and namespace for each RT instance. So if you have 10 RT
instances, one of which is really busy, you might spawn
20 apache children, each of which has 10 perl interpreters.
As opposed to fcgi, where you could have 20 fcgi processes
for the busy RT instance, and 1 each for the other 9
RT instances, therefore 29 fcgi/perl interpreters in memory,
as opposed to 200. Although a lot would be paged out.
bobg
–
Paulo Matos
|Sys & Net Admin | Centro de Informática |
|Faculdade de Ciências e Tecnologia | Tel: +351-21-2948596 |
|Universidade Nova de Lisboa | Fax: +351-21-2948548 |
|P-2829-516 Caparica | e-Mail: pjsm@fct.unl.pt |
… or fire up two separate instances of apache running with separate
config files on separate ports; this will then give you two separate
mod_perl instances. My colleague Russell worked this out.
Would this be possible to do (with mod_perl) per virtual host?
It is only possible with IP based virtual hosts. You can configure
different instances of apache to bind to different addresses. You
can also do this based on port numbers, but hide it by making the
main httpd proxy to the others. You might put RewriteRules or
ProxyPass directives inside named virtual host sections to
proxy to the httpd running on the correct port for each site if
you want it all to appear on port 80 at one IP address.
I’ve never played with mod_perl2. Yes, the docs seems to indicate
this would work. And it’s really works.
Bob, I think next paragraph is wrong, AFAIK MP2 creates pool of
interpreters on server start and clone/create new ones only when
thereis no available in pool.
Yeap a closer look into the docs shows that, you can even tune the
number of processes on the pool, with PerlInterpStart and PerlInterpMax
directives.
Anyone has played with this? I’m going to give it a shot.
I’ve never played with mod_perl2. Yes, the docs seems to indicate
this would work. And it’s really works.
Bob, I think next paragraph is wrong, AFAIK MP2 creates pool of
interpreters on server start and clone/create new ones only when
thereis no available in pool.
Yeap a closer look into the docs shows that, you can even tune the
number of processes on the pool, with PerlInterpStart and PerlInterpMax
directives.
Anyone has played with this? I’m going to give it a shot.
I saw reports that “PerlOptions +Parent” works for multiple RT
instances in one apache instance, but didn’t play much with that.
I’d think this means