• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.
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.


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.


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.


Note that this doesn't happen on all mod_perl platforms. The fork behaves just fine on some.


I take that back; looks like it is awful under even relatively light load.


What next release were you targeting?


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?


Sure. However the documentation is weak, IMHO.


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"


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".


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?


OK, in Patch04x01 and ready for release


Quietened down the error messages in the Fn testcase when native_search isn't installed.


Closed with release of 4.1.2


Topic attachments
I Attachment History Action Size Date Who Comment
Compressed Zip archivetgz natsea.tgz r1 manage 17.7 K 2007-01-26 - 14:19 UnknownUser Working files
Edit | Attach | Watch | Print version | History: r34 < r33 < r32 < r31 < r30 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r34 - 2007-03-04 - KennethLavrsen
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback