Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
Jason, you’re quite convincing :-)
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
The textdrive weblog is on a single proc (3something):
Requests per second: 327.68 1 (mean)
Not bad, not bad.
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
Sencer: Thanx for the update. And for the plugin.
Jason: Thanx for the stats. I think I will be putting this on other sites as well. Oh yeah…
Eric
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
Updated to version 0.8
- - don’t clean cache when merely viewing or previewing articles in article-event
- - add statistic in admin-side plugin over number and total size of the cache-files
- - sniff content and guess Content-Type on PHP4 (see Known Issues in first post)
- - finally, completely fix garbled feeds. (strncmp returns 0 for a match, go figure…)
The last should be the most important reason to update, because from time to time you might get a broken feed with the last version.
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
I’m upgraded!! Thanks Sencer.
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
Thanks for tweaking this, Sencer. For some reason I can’t tell if this is working on one of my textdrive accounts, any hints on testing to make sure it is active?
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
Soulship: You can examine your response headers to see if X-Cache: asy_jpcache v2 – file is returned. You may use an online tool such as this one.
VC3 :: weblog :: my wishlist
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
From the bottom of the help file
//Content-Sniffing to set correct Content-Type, because headers were not available
With version 0.8, I have a small problem with those headers.
I’m serving application/xhtml+xml for modern browsers via my plugin. This sets the headers (and gzip compressing) correctly.
Once asy_jpcache is activated, it overrides any header that the plugin sends, and serves everything as text/html (I haven’t checked the feeds yet).
- I’ve disabled gzip in jpcache-config.php, no problems with that.
- The mime type header proves harder to deal with. commenting out all those lines after the comment quoted above doesn’t help.
What actually happens is this: when the page is first requested, I get an error (and a blank page) – xml error in Firefox 1.0+, Safari returns this: ‘The error was: “bad server response
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
Hi phiw13,
I think I understand why the things are happening that are happening. I am just not sure wether there is a best way to handle them.
My proposal may seem a bit “intrusive”, but maybe someone else can come up with a better idea:
1) IMHO you should deactivate your plugin, and let jpcache handle the compression. Reason: For ob_gzhandler (or any gzip compression) to work, you have to send the correct header. If you turn off gzip in jpcache those headers are not being sent. And there is actually a “hack” in jpcache to uncompress compressed content before dealing with it, because the default textpattern gzips feeds, but not regular pages. Turning off gzip in asy_jpcache makes (IMHO) only sense, when you use mod_gzip/mod_deflate in Apache, or zlib.output_compression in php.ini.
2) Change the saved default header in file.php on line 104 (after the //Content-Sniffing…)
Find:
<notextile><pre>
else
$cachedata[“jpcachedata_type”] = ‘text/html; charset=utf-8’;
</pre></notextile>
change into:
<notextile><pre>
else
$cachedata[“jpcachedata_type”] = ‘application/xhtml+xml;charset=utf-8’;
</pre></notextile>
I think that should work. Reason: The first two “ifs” before that check for feeds, if they are not then this content-header gets saved and will later be served. If you comment those lines out, PHP will just send whatever default Content-Type is set in php.ini.
- The other solution would be to switch to a host that has PHP5, which I know is probably not an option in most cases. (If it is, Textdrive has PHP5;) )
Possible Problem: The header is saved in the cached file. If you only want to serve the xml-mimetype to those browsers that understand it, and text/html otherwise, you will also have to change the method “jpcache_restore” (in the same file.php) to not just read the type, but to check it against the Accept-Headers of the Browser.
If that all would solve the problem, I would adjust the code for the next release.
Questions: If an HTML Document starts with:
<notextile><pre>
<?xml version=“1.0” encoding=“utf-8” ?>
<!DOCTYPE
</pre></notextile>
will it always be sent as “application/xhtml+xml;charset=utf-8” (if we assume the browser understands it)? If a document should be served with that mimetype, does it always begin with that snippet?
edit: Nevermind my questions, I am looking at the code of your plugin right now. Thinking how best to take care of that…
Last edited by Sencer (2005-05-19 08:37:01)
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
> Sencer wrote:
- IMHO you should deactivate your plugin, and let jpcache handle the compression. Reason: For ob_gzhandler to work, you have to send the correct header. If you turn off gzip in jpcache those headers are not being sent. And there is actually a “hack” in jpcache to uncompress compressed content before dealing with it, because the default textpattern gzips feeds, but not regular pages. Turning off gzip in asy_jpcache makes (IMHO) only sense, when you use mod_gzip/mod_deflate in Apache, or zlib.output_compression in php.ini.
Turning off the ob_gzhandler in the plugin (and for my css files, which are served separately fom txp via a php file) wouldn’t be a problem at all. The ob_gzhandler is in the plugin, because my host doesn’t support mod/gzip yet.
When first tested, it was faster to disable that one line in your php files, ‘cuz I had them open in front of me :-)))). Call me lazy…
I was just a bit playing while dealing with some client issues which are pretty boring.
- Change the saved default header in file.php on line 104 (after the //Content-Sniffing…)
Find:
snipped
‘application/xhtml+xml;charset=utf-8’;
Here we’ll run into problems. Serving application/xhtml+xml to Gecko browers and to Opera 7.54+ is OK, Safari isn’t too happy, and then that browser ‘with dropping market share’ (aka IE) isn’t happy at all. Hence the content negotiation in the plugin.
Possible Problem: The header is saved in the cached file. If you only want to serve the xml-mimetype to those browsers that understand it, and text/html otherwise, you will also have to change the method “jpcache_restore” (in the same file.php) to not just read the type, but to check it against the Accept-Headers of the Browser.
If that all would solve the problem, I would adjust the code for the next release.
If that would be possible. I haven’t had a look at that part of the file yet.
The one thing that have to be kept in mind here, don’t force the TXP user to use application/xhtml+xml as it is tricky. You probably know that. The casual user doesn’t.
Questions: If an HTML Document starts with:
<notextile><pre>
<?xml version=“1.0” encoding=“utf-8” ?>
<!DOCTYPE
</pre></notextile>
will it always be sent as “application/xhtml+xml;charset=utf-8” (if we assume the browser understands it)? If a document should be served with that mimetype, does it always begin with that snippet?
Not necessarily, the xml declaration is optional anyway. I add it, in case a person want to save the page locally. The difference I use is in the DTD: xhtml1.1. or xhtml 1.0. But I know some TXP user who serves xhtml 1.0 anyway (UberNostrum), but a different mime-type.
As you see in the plugin code, the difference is all based on the accept-headers. It is all explained on this page, and a couple of forum threads around here.
edit: Nevermind my questions, I am looking at the code of your plugin right now. Thinking how best to take care of that…
Me too, although I won’t have time to really concentrate on this atm. And I’m looking forward to any idea that might come.
BTW, for a plain vanilla TXP site, your code does work very nicely. I’ve put it for a friend site, and he did notice a difference.
edit I disabled the ob_gzhandler in the plugin and the same in the php file that handles my stylesheets. Enabled asy_jpcache. This part works perfectly. On first load, I get the correct mime-type. A reload however, as expected, gives text/html.
Last edited by phiw13 (2005-05-19 09:18:33)
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
Thanks Etz, It’s running. I’ll have to save that link.
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
Ok, I have a question now.
I run AdSense on a couple of my sites. Do the ads get cached too? They are a javascript include.
Eric
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
For the moment application/xhtml+xml should not be used at all with this Plugin (version 0.8), even if you are on PHP5.
@edburdo: Javascript is executed client-side, therefore the result of that cannot be cached by PHP. You should be fine.
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
Ok, update to 0.9.5 (0.9 was not publicly released)
Download and read FAQ in the first post of this topic.
- - added option to enable txp’s logging (defaults to off)
- - clean cache on editing links
- - extended help section in admin-plugin
- - added statistics on read-write-ratio in admin-plugin (only if logging is enabled in jpcache and set to ‘all’ in Textpattern)
- - work-around for bug in some php-versions
- - added option to skip caching for feeds (defaults to off)
- - skip caching of feeds if the request can result in partial content (A-IM/feed, RFC3229)
- - skip caching when there is too little content (for example when doing redirects)
- - added some code & explanation to hack in application/xhtml+xml support
- - added Content-Length header
If you are upating:
Replace all files, clean the cache and re-upload the admin-plugin and re-examine the installation instructions! Here is the changed part:
Edit your index.php in the main directory and after
<notextile><pre>include ‘./textpattern/config.php’;</pre></notextile><br />
append the following line:<br />
<notextile><pre>include ‘./jpcache/jpcache.php’;</pre></notextile><br />
(Formerly it said to append the line at the top, now it is included after config.php)
Last edited by Sencer (2005-05-23 12:01:09)
Offline
Re: asy_jpcache 0.9.8 - Fast Full Page Caching
This is working great Sencer! Thanks for all the work on this. Could this work on the backend as well? /textpattern/index.php?
<span style=“font-size: 9px”>
Sorry if thats a dumb question. I don’t know the implications, of using it there. :)</span>
Offline