Re: [Tikiwiki-devel] Status of the new dev/doc.tw.o hosting

[Alexander M. <ma...@am...>]

Hi Stephane,

have to answer to this one, because...

Am Thursday 04 December 2008 09:24:42 schrieb Stephane Casset:
> Le Wed, Dec 03, 2008 at 11:38:15PM +0100, Alexander Mette écrivait :
> > Hi everyone,
>
> Hi amette
[..]
> From my experience I found that lighttpd+php5 (fastcgi)+xcache works
> very well for tikiwiki. Apache tents to be to heavy for the load.
> At least if you want to stay with apache use PHP as a fast-cgi, the
> PHP-apache module sucks... and use an PHP opcode compiler (xcache is
> working pretty well here, I know there are others...)
... I just _love_ lighty!!! :D
And believe me, I would have gone for it instead of Apache, if it wouldn't 
have been for RewriteRules. And as we dogfood hosting here and we suggest 
Apache as our main webserver - I went for it in the beginning. Still building 
up the setup, so kept it easy for a start. But later on we can move to 
lighttpd. So, if you want to help with keeping the RewriteRules in the Tiki 
package up to date and test the stuff out - I'd be very happy! :)

> > Boths sites hold up rather well, but dev.tw.o could be killed in a matter
> > of seconds when running on a threaded Apache and putting load on the
> > site. This most probably is because of some PHP-extensions not being
> > thread-safe. Sadly I couldn't find any website that would have a list of
> > threadsafe vs non-threadsafe PHP-extensions - I would be very grateful
> > for such a thing. I read somwhere that the PCRE extension is not
> > thread-safe, but this sounded more like a rumour than a fact. I guess
> > that it is not possible to compile a completely thread-safe PHP and still
> > have TikiWiki running. Trackers use PCRE a lot as a simple grep told me -
> > so it might be that PCRE is one of the non-threadsafe culprits.
>
> To solve this use PHP in Fastcgi mode...
well see below ! ;p

> > I have one idea still to have the best of both worlds and get a bit more
> > performance out of the sites: using threaded Apache with PHP FastCGI.
> > This will take some reconfiguration and testing before going live. But I
> > think that it could pay off: having more Apaches listening for delivering
> > static content like .js, .css and images (did I always say to use CSS
> > instead of icons? ;) ) and still having a non-threaded PHP to run
> > TikiWiki itself. I didn't yet make any calculations on potential RAM
> > usage for such a scenario and the speed-increase should be rather
> > marginal, but it could be worth the effort for a high-traffic site.
> >
> > There are so many more parameters to this, as for example Apache
> > MaxClients, eAccelerator being used, MySQL-tuning and so on...
> > ... so if anyone is interested in more specific information, please let
> > me know. For a start I can tell you that the Apache-configurations are
> > pretty well balanced to stay in RAM and not start swapping. dev.tw.o does
> > it sometimes, doc.tw.o never did so far.
> > Also bomb me with suggestions for improvement - I can't (actually I
> > won't) promise to respond, but it might be that you find your suggestions
> > in the next "Status of dev/doc.tw.o hosting" mail.
>
> well see above ! ;p
>   lighttpd+PHP fast-cgi+xcache (php opcode compiler)
> Or
>   apache (threaded)+php fast-cgi+xcache (or other accelerator)
>
> The only pb with lighttpd is that it don't use .htaccess for access
> control...
I don't mind that - I was goind to move the .htaccess to the main 
Apache-config anyways to save on disk-reads and gain performance.

> I didn't test eAccelerator for a long time, same for mm-turck... :(
eAccelerator works very, very well - I'm running it currently on doc/dev and 
usually on my sites. I just recently discovered xCache and it is said to be 
faster, so I'm going to give it a try. Interestingly xCache is even marked 
stable in Gentoo, while eAccelerator isn't. But well, eAccelerator works 
really well for me. But xCache got one more huge plus on its side: it's from 
the guys who wrote lighty! ;)

greets
amette

>
> If you need help, let me know.
>
> A+



-- 
ma...@am...
http://amette.eu