Re^2: mod_perl and module versions

There is a large possibility that a second application, based on the first one, will permanently be added to this server. This would be two apache servers running full time. If we need to have test versions of those running at the same time, all of a sudden we have four apache servers running at once. That is why I am concerned about the scalability of this.

As far as a third server, the reason I came to that conclusion was because of this same possibility. I see there is no necessity for that now, it just seemed more cleanly organized in my mind to have one server doing the port forwarding and the others handling requests associated with their particular application. Otherwise, you have one apache server both handling the port forwarding and doing the work for its application. Again, not bad, just a little more convoluted.

Comment on Re^2: mod_perl and module versions

Replies are listed 'Best First'.
Re^3: mod_perl and module versions by pileofrogs (Priest) on Feb 17, 2006 at 18:38 UTC
I'm having a hard time visualizing a situation where you need to be running all these different versions at the same time. It is some sort of test or demo rig where you want to compare many versions to each other? If I were doing something like that, I'd still just run a lot of apaches on different ports. I'd write a simple script that generated the config files, so adding new ones for new versions would be simple. That would solve the scalability problem. You could do something cute like encode the version number in the port number (e.g port 1001 eq version 1.001). The script that generates the apache configs could also make a few HTML files with links to all your apaches. If, on the other hand you're doing something production, I gotta wonder why you want all these different versions running...	[reply]
Re^3: mod_perl and module versions by thedoe (Monk) on Feb 17, 2006 at 21:44 UTC
This type of setup is from two production systems running on the same box. The second system was based off of the first, and so has many of the same module names. As we work towards a new release of each system, we must be able to demonstrate changes made without affecting the production system. Hence the need for the "test" versions. I wanted to avoid basing the number of apache servers running on the number of applications running, as each server is one more thing to keep an eye on.	[reply]