Jump to content

ProcessWire Pro Cache - Now Available

ryan

By ryan,
in News & Announcements

 Share

Recommended Posts

jacmaes Sr. Member

jacmaes

Posted
Posted

For instance, if you are doing anything that checks $config->httpHost in your template file, you wouldn't want to cache that page with ProCache (or the built-in page cache, for that matter). This is an example of a template file you wouldn't want to cache: 

if($config->httpHost == 'de.domain.com') {
  $user->language = $languages->get('de'); 
} else {
  // www.domain.com
  // keep default language
}

However, I will be upgrading ProCache so that it saves the hostname with its cache files so that such a template file could still be cached. 

I'm guessing your observation applies also to similar setups to deliver mobile versions, e.g.

<?php  
if($config->httpHost == 'm.domain.com') 
include("./sidebar-mobile.php"); 
else include("./sidebar-desktop.php"); 
?>

Could ProCache be used in the future for this kind of setup?

Link to comment
Share on other sites
niutech Jr. Member

niutech

Posted
Posted

Couldn't the same level of caching as Pro Cache be accomplished by using plain old static HTML files?

Bootstrap file index.php would include a small PHP file, which would make a static HTML cache of entire output from ProcessWire. Whenever the cache exists, it would be used instead of firing PHP.

The included cache.php would look similar to this (based on cacheme.php):

    $cache_file = $_SERVER['DOCUMENT_ROOT'] . '/site/assets/cache' . $_SERVER['SCRIPT_NAME'] . '-static.html';

    ob_start();

    register_shutdown_function('cache_complete');

    function cache_complete() {
        global $cache_file;
        file_put_contents($cache_file, ob_get_contents());
    }

and the sample rules at the beginning of .htaccess:

#If these aren't POST requests...
RewriteCond %{REQUEST_METHOD} !POST
#...and admin panel pages...
RewriteCond %{REQUEST_URI} !/processwire/
#...and requests with ?param=value...
RewriteCond %{QUERY_STRING} ^$
#...and requests with cookie named nocache...
RewriteCond %{HTTP:Cookie} !^.*nocache.*$
#...and if the static cached file exists...
RewriteCond /site/assets/cache/$1-static.html -f
#...then load the cached HTML file instead of PHP
RewriteRule ^(.*) /site/assets/cache/$1-static.html [L]
#Otherwise load the PHP script
Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
  • Author
Posted

If that's all there was to it, I wouldn't have bothered spending weeks developing ProCache. Likewise, if all a CMS needed to do was save and display the contents of a textarea, then I wouldn't have bothered making ProcessWire. :)

While we use an entirely different method, capturing output from a PHP script and caching it is relatively painless. It's knowing when to save a cache and when to expire, how to maintain and freshen the cache, how to handle the security, URL segments, page numbers, configuration, etc., that's the hard part. There's a reason why this is a commercial module. 

  • Like 2
Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
  • Author
Posted

Sorry jacmaes, I didn't catch that earlier. But yes, ProCache will be able to cache m.domain.com and domain.com separately, so would work well in that type of setup. Support for that is not yet there, but likely will be over the next week. 

  • Like 2
Link to comment
Share on other sites
alan Hero Member

alan

Posted
Posted
No dis' to niutech. On the matter of commercial components Ryan raises;
 
There's a reason why this is a commercial module.
for me, coming from a CMS platform which was excellent in many ways but that had too little focus on the business of sustainability for the project, I welcome what Ryan et al do to develop commercial grade plugins.
 
What they do for the sustainability and health of the PW project is as important to me as the quality of PW.
 
And not unimportantly, from my albeit limited experience, the cost/benefit and quality of Ryan et al's commercial output has been exemplary and puts many commercial-only products I have used to shame.
  • Like 7
Link to comment
Share on other sites
alan Hero Member

alan

Posted
Posted

Welcome seddass! I bought it and even on a local env where delays are so short it's often hard to spot performance changes it clearly made a significant difference. And the implementation is excellent (it's own panel for control etc). PS: I doubt these are needed but Googling to teach myself what nginx was I found these two pages; just in case they're handy anytime. Enjoy the cache module! :)

Link to comment
Share on other sites
seddass Full Member

seddass

Posted
Posted

I bought it too and it seems that the control panel saves the rewrite rules in .htaccess file. It is not supported in nginx so I should to configure in nginx.conf each time I use the control panel but once configured.. it should work in nginx too. Hopefully even faster :)

Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
  • Author
Posted
Ryan, the tests results are fantastic. Does ProCache supports nginx? I guess that the rewrite rules can be modified accordingly. is there anything Apache specific? 

I'm not sure exactly what changes might be necessary to make it work with nginx, but I have no doubt that if you are able to get ProcessWire safely working under nginx, then ProCache should work fine too. However, you may want to remove write access to your .htaccess file so that ProCache can't write to it. That way you are implementing any updates manually (and adjusting them for nginx). I'm curious to know if the ProCache rules work under nginx as they are, or if you have to make any specific changes?

Link to comment
Share on other sites
seddass Full Member

seddass

Posted
Posted

nginx doesnt have support to .htaccess files and all of the rewrite rules are stored in (virtual) host config updated manually. The apache rewrite rules have different syntax so they should to be converted to nginx style. I will send my version of the nginx rewrite rules by email. I believe that it will be easy to implement that ProCache will suggest the necessary rewrite riles for nginx too. Just a suggestion. 

  • Like 1
Link to comment
Share on other sites
  • 2 weeks later...
OllieMackJames Sr. Member

OllieMackJames

Posted
Posted

Bought it as well and tested the speed of the delivery of pages through sitebeam.net and all pages now under 0.1 s which is a 10 in their book, so kudos to ryan!

Here's a quote from sitebeam.net about what they mean with response time:

====================quote====================================

The response time is usually a measure of the application powering the
website (e.g. a Content Management System or webserver) and the power of
any servers running that application.

Good application performance means webpages feel responsive to users,
and the server is more likely to handle higher volumes of traffic. Poor
performance will dissuade users and search engines from the site.

==========================end of quote sitebeam=================

And the highest score possible is 0.1 sec and that is what all my pages were doing.

  • Like 2
Link to comment
Share on other sites
  • 3 weeks later...
Alfred Jr. Member

Alfred

Posted
Posted

Hello Ryan,
 
In the introduction you write that there is an issue when using ProCache with the LanguageLocalizedURL module.
Is this still an issue and if so when do you expect it will be save to use?
 
Thanks
 
 
BTW, and thank you and all contributors for making ProcessWire for what it is (and will be in the future).
With Processwire I feel like starting to build what I want instead of first stripping what I don't want.
I've tried several CMSs and examined how far I could get (with my limited coding capabilities) to make exactly what I want. Processwire is the first that hasn't stopped me and doesn't force me to make all kinds compromises.

  • Like 5
Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
  • Author
Posted
Any news regarding Nginx support? I would love to help out if possible

Thanks u-nikos! I think that nginx support would just be a matter of finding the equivalent rewrite rules. These are a fairly small part of ProCache (only a few rules necessary). So one simple route would be to remove write access to your .htaccess file (so ProCache can't modify it) and then take the rules that it says you should paste, and translate those to the equivalent nginx rules, before pasting them in. 

In the introduction you write that there is an issue when using ProCache with the LanguageLocalizedURL module.

Is this still an issue and if so when do you expect it will be save to use?

I'm not exactly sure what the issue is, but Soma had mentioned that there was an issue. I don't know the inner-workings of the LanguageLocalizedURL module well enough to understand what the issue might be. I've got a few to-do items on my ProCache list before I can focus on the LanguageLocalizedURL issue. But if anyone has the time to experiment with the LanguageLocalizedURL module and ProCache sooner, to see what the issue is, I can attempt to make updates/tweaks per your feedback. Btw, ProCache should work with the new LanguageSupportPageNames module included with the core. I've not actually tested it yet, but don't see any reason why it wouldn't work. 

Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
  • Author
Posted
I'm willing to share my Nginx configuration directives for other people if that's okay with you Ryan?

Absolutely! That sounds great. Thanks for getting it working in nginx. 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...