[phpa] Re: files needed if using shm too?

Hi Nick,

thanks for your reply.

> Historical reasons. After the first two weeks of developing phpa I had a 
> cache that used files. Then I went from there to get the best performance. 
> The files don't need to be there, but there are some potential benefits 
> >from having them, and I've just never had time to take them out. Plus they 
> would form the basis of an encoder if there ever was one.

Ok, I got it. I was just wondering. :-)

> It's possible that something's either wrong with the tests/setup, the 
> scripts are too trivial, or simply execution far outweighs loading time. 
> There's certainly likely to be something wrong if APC gave you better 
> performance. You might get similar performance. You don't indicate what 
> tests you did, but for 'real world' cases, where there can be many includes 
> and perhaps large scripts involved for a single request, there almost 
> always seems to be at least 2 to 3 times acceleration. Smarty can be more 
> like 6 to 9 times. 

I don't say that I had better results with APC on the same machine.
I am switching to a newer machine with also completely new versions of the
software so the results are not really compareable.

Maybe a page which outputs 200K is a bit big ;-)

 
> It would be worth checking your apache errors log for any warnings, and 
> also enabling shm logging. If phpa was unable to initialise an shm cache 
> then it will still work with the file cache, but you'll just get less 
> acceleration.

The good news are ... there are no errors in the error-log and 
it uses the shm-cache (as to be seen in the phpaca).

> If you have very small files then acceleration won't be so noticable 
> either. I tried a hello world example on one of my machines, using ab, and 
> with concurrency 4. Without phpa I had 560#/sec. With I had 600#/sec, so 
> there's your 10% gain.  But running it on the index.html from the phpa site 
> I get 34.5#/sec without phpa, and 95#/sec with phpa, so there's a 2.75 
> times increase. 


Its running a customized Phorum-3.3.2 with some includes and so on ...
with the output of around 200 KB of the page its also not really small. ;-)
But I think the load on the database is simply negating the effect of phpa.

As far as I tested for now I get an increase of 30% with a concurrency of 10 
(which is maybe a bit too high).
I will run some more tests tomorrow and give you some feedback on it.

Just if you are interested, I am testing it on a AMD Athlon XP 1600+, 512 MB 
Ram,
with PHP4.1.1. This machine will handle around 200.000 (forum-)hits/day when it
takes over.


> A further factor is the size of the cache. The default is 8MB, but if your 
> scripts require more cache than that then you'll get performance hits. 
> Using the phpa_cache_admin tool, and especially with Hannes Edingers gui 
> front end, is a useful way to determine cache utilisation and to help 
> sizing the cache. Enabling shm_logging as mentioned before and checking for 
> indications of running out of shm space is also useful if memory gets tight.

I've set the size of the cache to 32 MB 'cause I needed around 26 MB with
APC and I can always decrease it later :-).

That brings me to a feature request. ;-)
Sorry if I compare it to some comparing project but APC has some nice things
like using more than one 32 MB-segment and allocating the shm-segments on the 
fly.
So there are only the number of shm-segments used which were really needed.
How about this in phpa?


Thomas
------------------------------------------------------------------------
  www.php-accelerator.co.uk           Home of the free PHP Accelerator

To post, send email to phpa@xxxxxxxxxxxxx
To unsubscribe, email phpa-request@xxxxxxxxxxxxx with subject unsubscribe

Other related posts: