[SM-USERS] Re: php accelerators

[Daniel W. <d...@ni...>]

Paul Lesneiwski wrote:

> All,
> 
>   After seeing Turck MMCache bite it hard on PHP 4.3.10 (segfaults if
> you use the cache; optimizer still works), I was pretty disappointed, as
> the other options aren't appealing (PHPA I found to be dreadfully slow,
> think $995/yr amounts to little less than extortion, etc).
> 
>   I saw a site that looked like it was trying to continue MMCache
> development ala integrating patches that were compiled to date (sorry,
> don't have the URI handy), but it was hard to figure out how to get that
> code and once I did, it STILL didn't work with PHP 4.3.10.
> 
>   I just came across what looks to be the most promising alternative so
> far: http://eaccelerator.net/HomeUk  This appears to be a MMCache
> extension under current development, except it gives me the impression
> that even that is tentative.
> 
>   Anyone have any input, experience, thoughts, etc?
> 
>  -paul

I'm just bringing this worthwhile thread back to life. PHP accelerators
are obvoiusly of hugh import to squirrelmail admins/users. I am
currently running PHPA and, whilst it does help, I'm not sure how it
will cope as I scale upwards.

Is MMCache still buggy with 4.3.10 (or .11)?

Whilst we are on about performance improvers, what other things should
we suggest people use to help squeeze performance? I for one am
currenlty using IMAPProxy which works a charm.

Here are my stats for imapproxy:

      Server Start Time:     Mon Apr  4 08:48:31 2005

 Last Counter Reset Time:     Mon Apr  4 08:48:31 2005



 CLIENT CONNECTIONS



    current:         0                 peak:        11



 ACTIVE SERVER CONNECTIONS



    current:         0                 peak:        10



 CACHED SERVER CONNECTIONS



    current:        18                 peak:       123



 CONNECTION TOTALS



    client connections accepted:                283875

    client logins:                              283259

    server connections created:                  33776

    server connection reuses:                   249483

    client login to server login ratio:       8.39 : 1

It really helps when moving from one email in a folder to the next.
Instant responses.

One downside to this is the fact that you have to change your
squrirelmail config file to point to the port that imapproxy listens on.
What would be nice would be if we could get squirrelmail to have a
fallback port of the default imap port. Then if imapproxy ever crashed
squirrelmail would continue using normal imap connections.
(new thread started for this topic actually!).

Best,
Daniel