Frog CMS - Funky Cache (beta testers wanted)

Funky Cache (beta testers wanted)

96 posts, 14 voices

Page: 1 2 3 4

Nov 21, 2008 13:18 tuupola 291 posts	First of all I must say I was surprised how easy it was to create plugins for Frog. Core team has done a good job with the API. That said, I wanted to make Frog frontend faster than it is now. I tried Gilles’ File Cache plugin and that was an improvement. However I wanted to use funky caching which is one of the fastest caching techniques. Now I have first public version of plugin available. Code is only two evenings old so it would be great if people could beta test. So if you have time check the installation instructions. If you interested in number check the speed comparison. Code itself is at GitHub. Thanks once more to core team for clean understandable API and Gilles’ for inspiration. UPDATE: It seems that GitHub tarball generation is flaky. Use this download link instead.

Nov 21, 2008 13:30 David 1493 posts	This is pretty nifty! I’ve grabbed it, installed, and had a little play. It looks very promising — especially with the “no-split” version of Frog on the horizon. Some issues for me: 1. I don’t use the “.html” suffix, and I didn’t make the alteration just to see what would happen. (The suffix breaks a sub-menu I use.) Without the suffix, the “Articles” page is broken; with the suffix, “Articles” works fine, but the menu is broken (I knew it would!). So it would be nice to have the suffix as optional! 2. It doesn’t seem to like Tagger. :/ When you click on a tag-link, I get a forwarding thing happening. I know this is “host” related, but I don’t suppose it should be happening at all. (The same thing happens when you try to remotely “hot-link” files from my site.) 3. The Contact form doesn’t seem to work? I’ll leave FunkyCache set up at TestFrog for now, with suffix, so the “CSS Play” page will not work. Later this evening, or tomorrow, I’ll turn it off though.

Nov 21, 2008 14:08 David 1493 posts	P.S. It doesn’t like the Pagination “helper” either — see the “paging” links at the bottom of the Article page. Hopefully these are all “quick fixes”! :)

Nov 21, 2008 14:13 tuupola 291 posts	1. I don’t use the “.html” suffix, and I didn’t make the alteration just to see what would happen. This will be configurable later. Also needs more mod_rewrite rules. I have only spent two after-work evenings with the plugin so extra features follow later. 2. It doesn’t seem to like Tagger. 3. The Contact form doesn’t seem to work? Thanks for heads up. Will do some testing with those. Also the Funky Cache does not take comment plugin into account at the moment.

Nov 21, 2008 14:21 mtylerb 316 posts	I think, for the .html problem, simply changing: `public function path() { if ('/' == $this->url) { $this->url = '/index.html'; } return $_SERVER['DOCUMENT_ROOT'] . $this->url; }` in FunkyCacheController.php to: `public function path() { if ('/' == $this->url) { $this->url = '/index'.URL_SUFFIX; } return $_SERVER['DOCUMENT_ROOT'] . $this->url; }` Should set it to be the same as set in config.php.

Nov 21, 2008 14:21 ricks 486 posts	This is very promising, Tuupola! But like David, I don’t use .html suffix so won’t be able to test…

Nov 21, 2008 19:45 tuupola 291 posts	Archive pages should now work properly with both .html suffix and no suffix. Download again. Both versions also need special .htaccess file. Example .htaccess files included in plugin folder.

Nov 21, 2008 20:14 mtylerb 316 posts	tuupola, is there any way of just making it use whatever is setup in the config.php? My site uses .xhtml and there’s going to be plenty of people who decide to change that to their own ideals. People could, for instance, use .php, .htm, .html, .xhtml, or, on one of my servers, .wish. Seeing as Apache can be set up to serve any extension as any other type of file, it’s plausible that someone might use .asp, .aspx, etc. The possibilities are endless.

Nov 22, 2008 04:38 David 1493 posts	Hmmm… Something weird is going/has gone on. My articles page has stopped working. Weird. I’ve removed all caching, and reverted to no URL_SUFFIX, but “Articles” still doesn’t want to cooperate! Oh well. Will try to sort it later!

Nov 22, 2008 06:32 David 1493 posts	OK. This is worth knowing about! I can only assume that funky_cache created an “articles” subdirectory in Frog’s root directory, and when I disabled caching, it was left behind. Of course, browsers now would look at the directory `erajad.byethost.10/articles`, rather than allowing Frog to produce its Articles page. Blowing away the directory fixed it, of course. It would be great to get these wrinkles worked out, because as tuupola’s tests demonstrate, the performance gains are substantial. Thanks for your work on this, tuupola!

Nov 23, 2008 06:33 tuupola 291 posts	tuupola, is there any way of just making it use whatever is setup in the config.php? My site uses .xhtml Will be later. I am now first making it work properly with my own setup. Configurable items will come later. and when I disabled caching, it was left behind. Of course, browsers now would look at the directory Ah yes. Clearing cache only removes static files, not leftover folders. Will fix.

Nov 23, 2008 14:42 tuupola 291 posts	I made the cache file suffix configurable. Download latest to test. Short explanation is needed: Funky Cache must have suffix set in settings. It can not be empty. This is the suffix used in static files written to disk. If you have URL suffix set in Frog configuration Funky Cache suffix must be the same. If you have empty URL suffix in Frog configuration Funky Cache suffix defaults to .html. You can change this to something else such as .xhtml. In all both cases (and depending on the suffix) mod_rewrite rules are different. Plugin will generate working .htaccess file for you. Click Your .htaccess file on sidebar and cut and paste it from there.

Nov 23, 2008 23:12 ricks 486 posts	Is it compatible with Frog 0.9.3?

Nov 24, 2008 01:33 tuupola 291 posts	Have not tried myself. You know, I installed Frog for the first time last wednesday :) So I haven’t tried any older versions yet.

Nov 24, 2008 16:10 David 1493 posts	@ricks – I can’t see why this wouldn’t work with 0.9.3 … there’s one way to find out! :)) @tuupola – what are the chances of funky_cache working without the URL-suffix kludge? I don’t mean just now … what you said above (“I am now first making it work properly with my own setup. Configurable items will come later.”) makes perfect sense! But on my tests so far, it would seem preferable for me to wait until there’s no URL suffix issue to contend with. I did test out the latest version. Again, it seemed to leave a fairly liberal sprinkling of directories behind it. Is there any way all the funky_cache pages could be consolidated into a single directory tree off the CMS root? Thanks again for your work on this. It has the potential to be a significant contribution!

Nov 24, 2008 16:24 Martijn (mvdkleijn) 651 posts	@David et all I got Russel’s caching code from him and it seems fairly easy to implement, though if we integrate that into the Frog Core, it might collide with other caching solutions/plugins. @tuupola Me being either too lazy or simply too busy to do so (you decide ;-)… could you give us/me a short description of how your plugin does its work? Technically I mean. That would give me an idea of potential pitfalls and would allow me to way it against the solutions by Russel and Gilles.

Nov 24, 2008 17:07 tuupola 291 posts	what are the chances of funky_cache working without the URL-suffix kludge? I don’t mean just now … what you said above (“I am now first making it work properly with my own setup. Configurable items will come later.”) makes perfect sense! But on my tests so far, it would seem preferable for me to wait until there’s no URL suffix issue to contend with. Funky caching writes a static file to disc. For this file to be served as text/html it (usually) needs to have suffix such as .html, .xhtml, .php etc. I haven’t seen any implementation of funky caching which would write the static files to disc without suffix. I also don’t see how this would be possible. For example articles page and articles folder would clash with each other if there is no suffix `articles articles/` When there is suffix there is no problem `articles.html articles/` With the current version you can configure what the suffix (see my previous post). it would seem preferable for me to wait until there’s no URL suffix issue to contend with. Is there some other issue than configurable file suffix? Is there any way all the funky_cache pages could be consolidated into a single directory tree off the CMS root? Yes, that can be configured. One warning though. Then user must make sure search engines wont accidentally index this folder. I am aware of the issue and removing empty directories is in my TODO list.

Nov 24, 2008 17:25 tuupola 291 posts	@mvdkleijn It implements technique called “funky caching”. I think it was first time used by the *.php.net sites. Lets assume we have page at URL: `http://www.example.com/about_us` First time this page is accessed request goes to Frog. Frog generates the page and send it back to the browser. At the same time cache plugin writes the same content to webserver document root as static file called: `about_us.html` Next time the address http://www.example.com/about_us is requested mod_rewrite rules check is static file about_us.html exists. If it does webserver sends the static file. Request never reaches Frog or database. `RewriteCond %{REQUEST_METHOD} ^GET$ RewriteCond %{REQUEST_FILENAME}.html -f RewriteRule ^([^.]+)$ $1.html [L,QSA]` There is nothing faster than serving static files. Then next time page is edited necessary static files are expired and generated again. Heart of the whole thing is correct mod_rewrite rules. They can be confusing to write. That is why plugin will generate them depending on Frog and plugin settings.

Nov 24, 2008 19:08 silentworks 109 posts	I like the idea of this plugin, but what if the information is dynamic. An instance would be that my homepage loads in a snippet that has a function to check a parent page and its children, now this is placed inside the layout that the homepage will use instead of the homepage. Each time i update the homepage it won’t have any effect on the layout so what happen if i should updated one of the parent page or children that the snippet collects, this won’t reflect on the homepage since the homepage is now static and i didn’t actually update it.

Nov 24, 2008 19:19 mtylerb 316 posts	He did say that any time you update a Page, all the old static pages are deleted, so that the pages are re-cached. I don’t know if the same goes for snippets and layouts, though.

Nov 24, 2008 23:38 ricks 486 posts	Then next time page is edited necessary static files are expired and generated again. Does this include new comments posted to the page?

Nov 25, 2008 04:32 Martijn (mvdkleijn) 651 posts	@tuupola Ok, technique understood. I’m not sure I like it though. (no offence intended) Granted, it should be very fast and efficient… but it has a number of drawbacks right of the bat: It could mess up your directory structure severely Mod_rewrite rules are complex, making potential security gaps available Mod_rewrite rules are complex, making it harder to debug potential (un)related problems For the plugin to generate mod_rewrite rules, it would require write access to the .htaccess file. That is a big potential security issue right there as far as I’m concerned. The php.net sites consist of largely static content, Frog sites will (generally) be much less static. What is the impact of this on SEO related things? but that’s just my gut instinct here.. I’m probably missing a couple of things. :-)

Nov 25, 2008 06:39 tuupola 291 posts	@easylancer I do not follow your explanation, but couple of points: Any caching system will have problem with stale cache if cache is not expired properly when content is updated. It does not matter if data storage is database, static file or voodoo. If page needs to be generated each time you should not use any caching for that page. You can disable cache for individual pages from the admin. @ricks Yes. Page is updated when new comment is posted. Next time it is requested page is served from cache. Comment paging currently most like does not work. I did not test too much yet. BTW. Comment plugin itself throws quite many PHP Notices. @mvdkleijn Yes. Funky caching is not for faint hearted. It is most likely too complex for designer type of guys (no offense designer guys :) However: It could mess up your directory structure severely It wont mess up directory structure if you know what you are doing. Blogging software I use (Mephisto) caches static files to document root and I have never had any problems. It is also possible to write the static files to their own folder for example DOCUMENT_ROOT/cache/. Then you do not any risk messing up something (and this actually is much cleaner way to do it). Mod_rewrite rules are complex, making potential security gaps available. bq. Mod_rewrite rules are complex, making it harder to debug potential (un)related problems As I said it is not for faint hearted :) For the plugin to generate mod_rewrite rules, it would require write access to the .htaccess file. That is a big potential security issue right there as far as I’m concerned. You misunderstood. It generates the mod_rewrite rules to you in admin interface so you can cut and paste them to your .htaccess file. The php.net sites consist of largely static content, Frog sites will (generally) be much less static. I do not follow. My blog is all dynamic. I still use funky caching. And if the site was static it would not need caching at all. What is the impact of this on SEO related things? None. Spiders (nor normal users) never know if the content was served from static file or PHP backend. Bottom line. If you are not confident with mod_rewrite and friends I would rather use Giles’ File cache plugin. It gives nice speed improvement and you only need to click a checkbox to enable it. However if you are after absolute performance (handling Digg effect and being slashdotted) I would give funky caching a try.

Nov 25, 2008 11:23 ricks 486 posts	Funky caching sounds great, but I was wondering what is the difference between this and File Cache Plugin, which describes itself thus: The FileCache plugin creates a cached version of the page in a file (on disk) and check at every request if a cached version of the requested page exists and is valid. If it is, the plugin will serve the cached version and stop the script execution. Thus, you improve performance and reduce database queries. It sounds like both do the same thing. How do you get such better performance from Funky Caching vs the File Cache plugin? It is also possible to write the static files to their own folder for example DOCUMENT_ROOT/cache/. Then you do not any risk messing up something (and this actually is much cleaner way to do it). If this is the better way to do it, can this be set to the default behavior? It generates the mod_rewrite rules to you in admin interface so you can cut and paste them to your .htaccess file. Does this mean you need a unique rewrite rule for every individual page? Thanks!

Nov 25, 2008 11:57 tuupola 291 posts	I was wondering what is the difference between this and File Cache Plugin. With File Cache plugin the request still goes to Frog. With my plugin the request never reaches Frog if page is cached. Rewrite rules check if cached file already exists. If it exists Apache serves the cached static file. Only if cache does not exist request is passed to Frog. If this (caching to DOCUMENT_ROOT/cache/) is the better way to do it, can this be set to the default behavior? I just committed update which does just that. You can configure folder where plugin writes the cached files. This defaults to folder named cache. Folder is relative to document root. Webserver must have write access to that folder. If you do not have Git I also updated installation tarball to version 0.3.0. Remember to cut and paste rewrite rules to your .htaccess file from admin interface after updating or changing cache settings. Does this mean you need a unique rewrite rule for every individual page? No. There is four different situations depending on Frog and plugin settings. Frog URL_SUFFIX = ‘’ and Funky Cache folder = ‘’; Frog URL_SUFFIX = ‘’ and Funky Cache folder = ‘some_folder’; Frog URL_SUFFIX = ‘.foo’ and Funky Cache folder = ‘’; Frog URL_SUFFIX = ‘.foo’ and Funky Cache folder = ‘some_folder’; Each of these case have slightly different mod_rewrite rule. These might be really confusing to write by yourself. That is why I wrote a generator which after changing setting you can just click Your .htaccess file in admin and cut and paste working rewrite rules from there.

Page: 1 2 3 4