See
TWiki:Codev.StrangeGoingsOnWithSearch for a full analysis.
This effectively makes mod_perl unusable for any substantial TWiki application. I'm not sure if the same effect exists with speedy; I don't think it does, but I don't understand why.
CC
Speedy should show the effect to a lesser extent than mod_perl: With speedy, there are still separate processes for apache and speedy. So when speedy forks, it forks basically Perl plus a rather slim persistence wrapper, while when mod_perl forks, it forks Perl plus Apache.
The "age" of the Perl process is playing a role, too. The more different requests a single process has been serving, the more code gets compiled (we have lots of Plugins which are compiled on first invocation). And Perl
never ever returns memory to the operating system. So you could have a look at whether your processes simply grow to some maximum size, or continually leak memory (are getting fatter and fatter), or whether the situation improves if you have fewer MaxRequestsPerChild in your Apache config.
HJ
Don't think this is a release blocker. Setting priority to "Normal".
Damn right it's a release blocker, for anyone trying to use mod_perl. However I didn't intend to block 4.1 with it, but I most certainly want to block the next release. Resetting to Urgent.
CC
Note that this doesn't happen on all mod_perl platforms. The fork behaves just fine on some.
CC
I take that back; looks like it is awful under even relatively light load.
CC
What next release were you targeting?
Patch?
I am in urgentcy to get 4.1.1 out because there are many very basic feature related bugs that makes 4.1.0 a very bad experience compared to 4.0.5. This one has been there since Cairo so I'd rather make sure it is properly fixed and tested for quite a while and merge it in in a later patch release. Can we agree to this?
KJL
Sure. However the documentation is weak, IMHO.
CC
If the documentation is weak then why is it Waiting For Release?
I looked at the docs and indeed a lot more is needed here. I also looked at the actual changes. This is a massive change with c code that needs to be compiled.
I am very concerned about if normal non-geek users has any chance to install this.
This is a new feature - not just a bug fix. It should be following our release process.
I would like to see a Codev topic explaining
- What this new feature does
- How you install it
- How it works if you do not install it
- Who needs to install it. The text in the configure script leaves an installer more confused than enlightened.
- What more will happen?
- What is the benchmarks. There was an email with numbers from memory. I would like to see some more hard numbers.
What I lack of decisions from the community
- Should this be in the core or in a contrib?
- Is it the right solution to the problem?
This is for sure not patch release material. This is 4.2 or 5.0 material.
And for sure not waiting for release yet. I have put it in "Being Worked On"
KJL
Agreed. However it does patch the hole. Benchmarks:
A 686 desktop, RH enterprise, apache 2.2.3 All numbers in millseconds. Search over ~25K topics. "Forking" is the old code, "Native" is the native code module.
Without mod_perl |
Forking |
11455 |
Without mod_perl |
Native |
11908 |
With mod_perl |
Forking |
26672 |
With mod_perl |
Native |
11007 |
A dual-core x86 server, 2GB memory. Same S/W.
Without mod_perl |
Forking |
4908 |
Without mod_perl |
Native |
4299 |
With mod_perl |
Forking |
No figures, timed out |
With mod_perl |
Native |
3641 |
Numbers for pure perl not included, but it's faster than forking, but slower than native (unsurprisingly).
I am not doing any further work on it at this time, so switched back to "Confirmed".
CC
Oh, and sorry, this is
definitely patch material. It can be optionally applied, and is trivial to install. We'd be insane not to include it (especially after all the bloody work I put into it!). All it requires is to be user-friendly documented.
And could you use the target release field instead of modifying the summary please?
CC
OK, in Patch04x01 and ready for release
CC
Quietened down the error messages in the Fn testcase when native_search isn't installed.
CC
Closed with release of 4.1.2
KJL