Richard Heyes wrote: > Jochem Maas wrote: > >> but ... I need more speed ... > > Don't we all? Try these: > > 1. stat() is slow, try not to use it ack. > 2. Don't pass images through PHP if at all possible for dynamically, resampled images: I only do this on the initial request - php generates the image .... after that apache+mod_rewrite spit them out. > 3. Get Fiddler (www.fiddlertool.com) - It will let you see the HTTP > response headers. It will show what's actually being requested from > you server. Typically, images are cached by the user agent , whereas > PHP files are not. I've happily used 'tail -f access.log' and the webdeveloper toolbar and firebug upto now. but I'll look into Fiddler. > 4. Don't use mod_rewrite if at all possible I need mod_rewrite. > 5. Recompile Apache with just the modules you need this is a tough one - I don't know most of the apache modules, find out which ones I'm actually using is a time consuming task. > 6. Recompile PHP with just the stuff you need > NB: You can always recompile later if your needs change > 7. Don't use off the shelf components when you don't need to. PEAR::DB > is one example - I was using this but then mimicked the API saving > 50k of code. Quite significant if you're not using an accelerator. pretty much everything I run is handmade. the page scripts on the server/sites in question are outputting at 50-250ms - so that pretty good - it's the tons of images and other stuff (e.g. google maps api js) that's killing the page load time. I use the latest version of APC (thanks to Greg Beaver for the help on setting up a 'custom' PEAR install) with 'stat check' turned off. still leaves me with the Etag weirdness. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
