RE: [PHP] stripping white space?

Thanks, Bart. I am definitely interested in seeing your caching modules - it could be a useful resource for ours. Right now our caching module is only in the planning stage, but there are few scratches I wrote myself, and it seems to be very promising. Our project is a website that mainly contains articles. The database is fast but big, the pages can also get quite large, so as long as we get a good hard-drive we can work on that caching things. There's a directory called /cached which we will store the file with the exactly same file names (with mod_rewrite there's no need to use any ?var=val&etc=etc&, you just get it looking like a directory) so it is extremely easy to locate a file. ie: if you go to a file articles/2000/10/26/features/doom then apache looks first into cached/articles-2000-10-26-features-doom.txt and, if it finds it, sends it to your browser sweetly compressed. We were also thinking to use shtml or even php over again, but it kind of doesn't look to make much sense... When an article is updated PostgreSQL's (INSERT/UPDATE/DELETE) trigger shoots up a function that deletes a file relative to the database and looks for whatever related to it entry to delete other 'outdated' files as well. The file is gone, and the next visitor as soon as he accesses the page for the first time will drop a new file in cached folder again, without even understanding it. That's the idea. The difficulty here is one - create a bullet proof relation between database entries so only the right files get 100% removed to avoid situations like "I just updated that, where is it?...". Any comments, gurus? -maxim maletsky -----Original Message----- From: Bart Veldhuizen [mailto:bart@blender.nl] Sent: Tuesday, July 10, 2001 5:07 PM To: php-general@lists.php.net Subject: Re: [PHP] stripping white space? Hi Maxim, > 1. HTTP compression, which is not 100% compatible, but catches most > of the browsers anyway. Yes. The standard PHP implementation actually inspects the HTTP headers to determine if the browser supports gzip encoding. If not, it will send the files uncompressed. Looking at our website stats, 97%+ of the people use a version 4 browser so they're fine. > 2. Our own caching system: in two words: ob_*() to save the output > as a text file, mod_rewrite to check for file and throw the plain .txt files > if exist, PostgreSQL triggers to update (delete cached) .txt files. Hah! We think alike :) I implemented a similar system on our own website a few weeks ago. It does not cache complete pages (that's hardly possible due to the dynamic nature of our site), but instead caches HTML 'blocks'. (one page can consist of multiple blocks). Instead of serving those files directly from the filesystem I let PHP inspect them first: each file contains a timestamp that allows for expiry times. The results are wonderful: our website (http://www.blender.nl) has approximately 80.000 pageviews a day and the system load is almost never higher than 0.4. (Dual PIII/450/512MB/FreeBSD) If people are interested I'll publish the code for the caching module. > 3. Browser/Platform detection: there's no need to make > cross-platform heavy but compatible pages, just specific style sheets and > html tags for specific browser families. Clever! That's something I will put on my to-do list as well. > 4. clever HTML design, so there are less tags, tables etc, to have > files smaller. And *that* also includes less comments and double quotes on > integers. We do nothing with XML, so that is why I am so shocked why people > here discourage me that much. In my experience once you use HTTP compression, adding a few comments or whitelines do hardly add to the filesize anymore. I don't think it's worth the trouble to write super-compact HTML. I don't know a single thing about XML, so I'll skip that discussion :) Bart -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net For additional commands, e-mail: php-general-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net