[UPHPU] MySQL questions?
mac at macnewbold.com
Fri Apr 23 08:39:29 MDT 2004
Yesterday at 11:30pm, John said:
>For PHP cache'ing you could use Zend's (pay for) technology or you could
>use what I use, ionCube PHP Accelerator. And it's free and easy to setup.
> Much easier that Zends (at least a year ago's version). Basically it
>takes your PHP page and compiles the code (sort of) and keeps that binary
>version in /tmp, then when the next person comes along, it grabs the /tmp/
>binary one and doesn't have to recomple each time. It also keeps track if
>the file has a newer date stamp than the binary and thus recache'es it.
There are also free programs that do similar things, too. I think my work
used to use one called "apc". Here are some you might look at:
Alternative PHP Cache (apc)
Google also told me about a howto describing some things you can do to let
the results of your php pages be cached by a browser, using the
If-Modified-Since and Last-Modified HTTP headers:
PHP Cache Control
Here were some other things that looked interesting:
A few things to remember about caching is that its benefit is limited:
1) It won't decrease the size of your pages, so if the bottleneck was the
network, it won't speed things up for the client
2) If you don't have a sizeable cache hit rate (i.e. pages you can reuse
from the cache) then it won't do much good at all, and may even hurt
3) GET and POST input to your scripts can cause your page to change its
result, even if your script hasn't changed. Some PHP caching tools cache
the compilation of your php, rather than the result of its execution, and
still get a benefit here (although they still have to execute the php
every time). Others cache the result of execution, and can basically serve
up a static page every time, but the doc in the cache would have to have
the exact same GET and POST as the current request to be useful.
4) I don't know how all this interacts with SESSIONs, as they are another
form of input that change the results of your script. I didn't notice any
of the caching things mention it. Same caveats as #3.
5) Other input that isn't reflected in the script's modification time,
like anything you might look up in a database, filesystem, on the
web/network (via CURL), or anything else like that would also invalidate
your cached copy. Even something like the current date/time shown on a
page can invalidate your cached result of execution. See #3.
So the bottom line appears to be that first you need to look at the site
you're trying to speed up, and determine if server performance is the
problem. If not, caching probably isn't for you. Then, look at the way
your pages work, and see if caching the _result_ of the php execution
would work. If not, you'll have to cache the _compilation_ of the php
code, and you'll still have to execute the script every time. So the only
benefit you'll see is saving compilation time, which may or may not be a
significant part of your script's execution time.
Some other things that can increase speed for PHP sites:
1) Use mod_php instead of the standalone (aka CGI) PHP
2) Try using mod_gzip - most browsers support Content Encodings, and in
particular, will tell the server they can support gzip-encoded content.
mod_gzip lets apache gzip the result on the fly, if the browser supports
it, and decreases the size of the page that has to get transferred over
the network. It won't decrease the load on your server, but it often
provides the biggest bang for the buck for the speed percieved by visitors
to the site. (Google does it - try tcpdumping a request for google's
homepage - it comes back gzipped.)
If that answers most of the questions about php caching, I don't think
I'll cover it in the mysql meeting, even though someone requested it. I
don't know of any general form of mysql query result caching that is used
Mac Newbold MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com http://www.macnewbold.com/
More information about the UPHPU