Bug 204212
| Summary: | Evaluate/Test switching from mod_cgi to mod_perl | ||
|---|---|---|---|
| Product: | Services | Reporter: | Kubilay Kocak <koobs> |
| Component: | Bug Tracker | Assignee: | Bugmeister <bugmeister> |
| Status: | Closed Works As Intended | ||
| Severity: | Affects Only Me | CC: | gonzo |
| Priority: | --- | Keywords: | dogfood, feature, performance |
| Version: | unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Kubilay Kocak
2015-11-02 07:54:57 UTC
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. |