Bugzilla has supported mod_perl based invocation since version 2.23. The documentation [1] states: mod_perl is faster but takes more resources. You should probably only consider mod_perl if your Bugzilla is going to be heavily used. [1] https://bugzilla.readthedocs.org/en/latest/installing/apache.html checksetup.pl on the production bugzilla service shows: Checking for mod_perl (v1.999022) not found Checking for Apache-SizeLimit (v0.96) not found ... *********************************************************************** * MODULE NAME * ENABLES FEATURE(S) * *********************************************************************** * RadiusPerl * RADIUS Authentication * * mod_perl * mod_perl * * Apache-SizeLimit * mod_perl * *********************************************************************** So these packages probably need to be installed (possibly not Apache-SizeLimit, unless its compulsory)
I do not see any performance issues right now and doing a switch just for the sake of it is completely unnecessary. Is there any valid reason to switch to mod_perl?
The lack of performance issues (any measured degredation) is orthogonal and independent from potential performance improvements and the subsequent improvement in service quality/experience. It would certainly not be for the sake of it. I will note that Peter did mention something about issues with mod_perl in the (distant?) past, related to memory usage, but I do also note that mod_perl.pl comes with memory-limit-based process rotation (with a default of 45mb per proc) It's the recommended configuration for 'large' installations, and I think it's worth doing (of course, testing, evaluating, etc). It really ought to have been configured with mod_perl from the start, and our current configuration ought not be a barrier for improvement if its possible (and trivially so).
(In reply to Kubilay Kocak from comment #2) > The lack of performance issues (any measured degredation) is orthogonal and > independent from potential performance improvements and the subsequent > improvement in service quality/experience. It would certainly not be for the > sake of it. Improvements can be made, if impediments are currently known. Are there any impediments? > I will note that Peter did mention something about issues with mod_perl in > the (distant?) past, related to memory usage, but I do also note that > mod_perl.pl comes with memory-limit-based process rotation (with a default > of 45mb per proc) So we have no impediments, there might be improvements to issues that do not affect us (yet), but it also might happen that mod_perl brings in impediments. > It's the recommended configuration for 'large' installations, and I think > it's worth doing (of course, testing, evaluating, etc). It really ought to > have been configured with mod_perl from the start, and our current > configuration ought not be a barrier for improvement if its possible (and > trivially so). Looking at the mod_perl guide and the things to keep in mind at http://bugzilla.readthedocs.org/en/latest/installing/apache.html, we get an unknown set of improvements that do not solve any current issues, and also receive a set of important limitations. Given those circumstances, I do not see any benefit in switching to mod_perl right now.
Improvements don't require impediments :)
They should not bring in new ones, which outweigh the improvement itself, either ;-)
(In reply to Marcus von Appen from comment #5) Absolutely, without question. Net benefit.
+1 for keeping mod_cgi. Two years passed since opening this ticket and there was no major problem with using CGI AFAIK. Any unnecessary optimization is a risk and drain of limited resources, it would be better to spend them fixing bugs and adding new features. I vote for closing this bug and re-visiting it when we hit performance limit.
Closing as "Work as intended". mod_perl is not just a drop-in replacement, it comes with its own set of caveats and requires certain coding style. Stock Bugzilla supports mod_perl but I am not sure about our custom modules or third-party ones. And since there are no visible performance issues with the current setup I don't think it's worth spending resources on the migration.