[phpa] Re: Cached 'static' PHP vs HTML

I think we would all agree that pure static html generated as 
required/on-demand is the most cost effective way to scale any website. 
But there will be times when the content is so large and states changes 
so fast that it would be better to just use php to cache slow contents 
in a file and use php to time validate/expire the content versus a more 
complex validation/expiration system with a static site generated by php.

Most php sites use mod_gzip to decrease the transfer time/load from 
webserver to client to further increase throughput and save on bandwidth.

normal php way of caching/retrieving content to/from file:

(1) check to see if cache file exists, if not go to 2, else read/push 
cache file from hd to client
(2)  grab content from database
(3)  store output to cache file on hd and push output to client as well

CPU cycle is dirt cheap now-a-days when the site grows to a certain 
level, it's the database and more specifically the hard drive i/o that 
becomes the limiting factor to page/sec throughput. Here is how I use 
the extraneous cpu cycles to further accelerate PHP based caching:

We can go a step further by compressing both the database content and 
the cache with gzip.

faster php way of caching/retrieving  content to/from file:

(1) check to see if cache file exists, if not go to 2, else read/push 
cache file from hd
        (1)* the cache file on hd are compressed in gzip format so 
decompress and then push original cached content to client.
(2)  grab content from database
        (2)* content in database is pre-compressed with gzip at insert time)
(3)  store output to cache file on hd and push output to client as well
        (3)* the generated output is first compressed with gzip and stored 
to file.


On average, from my own experience, gzip compression on average reduces 
storage requirement by 50-75%. By using gzip compression provided by the 
zlib module we have effectively doubled the speed of database server for 
critical operations involving large content and at the same time 
effectively doubling the speed at which our custom php cache engine 
operates. Decompression time/cpu cycle is negligible. Hard drive 
read/write operations are the most expensive in any large scale 
environment and wide use of compression can significantly reduce the 
load on these mechanical slugs.

I have been using the above model for several months now on a very large 
production site with great result and because of the tremendous 
improvement versus the non-compressed way, I have pushed back previously 
planned server hardware upgrades indefinitely.

Of course, static html caching is still way better but depending how 
real-time you want your site to be and how large the site, the 
complexity might force some of us to stay with pure php based system in 
the mean-time. If that's the case with you, as it is the case with me, 
might as well use compression to give ourselves a close-to-free turbo 
boost.

Xing




On Thursday, April 18, 2002, at 07:05  AM, Manuel Lemos wrote:

>
> Hello,
>
> Nick Lindridge wrote:
>>
>>>
>>> Oh and there are webservers that focus on serving static contant like
>>> Tux and X15 for Linux that can push an amazing amount of data. They do
>>> a lot of funky stuff to get I/O time down to the absolute minimum.
>>
>> There's an interesting paper discussing the Flash server,
>> http://www.cs.princeton.edu/~vivek/flash99/
>> and that research did a number of obvious, but also some not so 
>> obvious,
>> techniques to maximise performance. Apache is really quite a slow web
>> server, but it's highly flexible, and of course that's nice. I'd 
>> probably
>> still use Apache for dynamic content, but use one of the much faster 
>> web
>> servers for static content if I had a really heavily loaded site.
>>
>> There are also techniques that can be explored such as putting the web
>> server into the kernel, and I believe some of the largest internet 
>> sites
>> exploit this.
>
> I have not reached any conclusions, but for static content there
> mod_mmap_static that pre-loads a specified list of files into shared
> memory and serve them from there so it prevents Apache from touching the
> disk.
>
> For HTML it is well worthy to use modules that compress and cache pages
> because the majority of the browsers supports compression and it usually
> reduces in 5 times the time it takes to deliver HTML pages to the
> browsers. This means that each Web server process will be tied with each
> client connection for much less time freeing the processes to serve
> other requests and preventing the need for the server to fork more
> processes during access surges.
>
> Regards,
> Manuel Lemos
>
>
> ------------------------------------------------------------------------
>   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
>
>

------------------------------------------------------------------------
  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: