Jump to content
muzzer

Markup cache and PW performance

Recommended Posts

Playing around with the markup cache on a website which is listing accommodation/activities. The page in question displays a number of listings (info about accommodation operator) and then a google map with markers for all the listings.

I've cached (using markup cache) each listing, and also the google map markers, and the performance boost from this is pretty damn good, I'm stoked with the result. In the process I've got a bit obsessed with page-load speed and done some benchmarks. the following image is a sample page-load.

The troubling aspect is time PW takes to get up and running.

 post-608-0-28763600-1402621845_thumb.png

As you can see from the benchmarking info the vast majority of page-load time is PW startup - that is everything prior to the page template - ie, the time is measured from the start of index.php to the start the the page template file.

  • Is this normal? This is on a live server (shared host) and the value varies from 400-600ms.
  • Do installed modules have any impact on this?
  • Is there any way to speed this up? It's reasonably snappy but if this can be improved then I'm all for it 
  • Like 1

Share this post


Link to post
Share on other sites

Umm.. probably a stupid question, but in your picture ProcessWire startup time looks more like 0.6ms than 600ms. Which doesn't seem that bad. Am I reading this wrong? :)

  • Like 1

Share this post


Link to post
Share on other sites

@teppo, Oops, thats a formatting error, those figures are seconds, so .602ms should read .602s, or just over half a second, as should all the other timings. This is a top end figure, more often than not it's around 300ms.

@cstevensjr, thanks for the links, good read. The timings however are not latency, rather php processing times. Sorry, should have made that clear.

Share this post


Link to post
Share on other sites

I was surprised to see that 600ms figure so I tested out some pw sites I've worked on. My PW 2.4 sites seem quite a bit slower than the sites using 2.3. I'm using a pretty beefy server and the 2.3 sites have processing times below 300ms where as the 2.4 sites are 600ms+. For the most part that is acceptable but it would be nice if it was faster. Some options to speed up pw:

  • Open an issue on github, make ryan aware of the performance issue
  • Find the bottlenecks in the code yourself, fix them and create a pull request
  • Use ProCache
  • Put Varnish in front of your web server 
  • Put Cloudflare in front of your web server

Edit: I was a bit hasty, an empty pw 2.4 project executes in around 200ms, those other 400ms+ are my doing.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks for the suggestions Jonathan.

I'm not concerned so much with bottlenecks in my code as I know I can optimise these in due course. Although if the page is taking 700ms to load and 600ms of that is PW startup there would not appear to be a lot of room to optimise my code!

I am more concerned about the PW setup time (600ms)  which I don't think I can get around without more severe caching or cloudflare etc. And I'm not wanting to go down that track as pages are constantly changing (600+ users with ability to update site data makes page caching difficult) and I have quite a bit of page data tracking which I would lose (to my knowledge) if utilising cloudflare (unless I handled this with javascript which I'm not keen on).

What I was hoping for was an idea from other v2.4 users if the 400ms-600ms benchmark shown above for pre-template parsing was normal, if removing modules would improve this at all, and any other way I might improve this.

Cloudflare may end up being an option I need to look at more closely.

Thx for all input/suggestions thus far guys :-)

Share this post


Link to post
Share on other sites

In my test PW needs 0.001s to load config and 0.1s to the point right before rendering a page.

  • Like 2

Share this post


Link to post
Share on other sites

While testing I had mostly similar results to those of Soma for the basic site profile out-of-the-box (on localhost), but some actual production sites took a bit longer to load -- around 200-300ms. If we really wanted some comparable results, we'd need all the details of aforementioned tests (including a test site to run those tests on on) just to rule out different measuring methods and side-effects of installed modules :)

  • Like 2

Share this post


Link to post
Share on other sites

whattool u.use 2 bench marks    ?

whatt. autoload modulos u have ?

turning on debugger mode.on in config.php

admin>debug>hooks tell u some

multi languoge ?

  • Like 1

Share this post


Link to post
Share on other sites

Thanks for this guys.

Soma, your results are more like what I would expect. Some older (but comparable) modx sites I'm running on the same server are loading in under 100ms.

WillyC, benchmarks are very simple, using php microtime to measure the various segments from the beginning of the index.php file through to the end of rendering the page footer.

No multi language

Have just uninstalled a handful of unused modules (editors, module manager etc,all backend/admin modules) so only have a barebones install. Startup is now between 200-300ms so seems to be an improvement (and entirely acceptable to me). I have not developed modules so don't know how they work but assume any admin modules should only load on backend pages?

I'll need to go back over this and see if it is indeed modules that are the problem but I would not have thought so.

Still, I wonder why my modx sites are so blazingly fast compared to PW sites, even static (no api calls) pages. I know PW is more advanced and offers much more than modx so some expected overhead there, but it does seem a little out of proportion. Don't get me wrong, I'm not complaining, lovin' PW :-)

Share this post


Link to post
Share on other sites
Still, I wonder why my modx sites are so blazingly fast compared to PW sites, even static (no api calls) pages.

I'm not sure you can directly compare modx and ProcessWire on load times unless you have them both in original state without any modules installed, except those required by the core. Even then, they may not be directly comparable unless they are accomplishing the same thing and providing the same level of tools at bootstrap. ProcessWire's boot time will be very much affected by how many "autoload" modules and running and how much activity they perform during their initialization process. It will also be affected by your overall quantity of modules, fields and templates. I would assume modx to be the same in that regard (assuming they have some equivalent of autoload modules, fields, templates, etc.). So whichever one is faster may have as much to do with how much stuff you are asking it to load as part of the bootstrap process. 

We do have a rather extensive API that most systems don't, so we do hand over a lot of ready-to-use tools to your template file and part of our bootstrap, and very likely most systems you'd compare PW to don't have near the scope of tools that we do. But we always want PW to have the best performance possible. In PW a "no api calls" page is not going to make any difference in the time of the bootstrap process, because execution of your code (in your template file) occurs after the bootstrap process. Again, I'd assume modx to be somewhat similar in this regard too. 

I did measure the time it takes for our bootstrap is a fairly blank state (with regard to modules) and found I was getting about 0.2s (200ms) bootstrap times. Admittedly, this is on a slow computer more than half a decade old, but did have APC enabled (APC is an opcode cache). Then I disabled APC and found they were at least 100ms higher. This is the time it takes ProcessWire to boot and give control to your code. As far as how long it takes after that depends entirely on you and what you are doing with the API. I would guess that in Soma's case, he's got a faster computer than me and perhaps with an opcode cache too. 

Even though my computer is old and doesn't have much in the way of horsepower, I thought there was some potential to speed up the bootstrap process (there is always room for optimization), so I've gone ahead and applied some optimizations to the dev branch, now available in PW 2.4.5. On the same computer as before, I've got the bootstrap down to 0.08s (80ms) with APC enabled, or 0.15 (150ms) with APC disabled (no opcode cache). This is with a logged-in user, so it's a pretty good performance boost. Is it possible to tell the difference in speed in person? No–we're talking about amounts of times that are beyond our perception (beyond my perception at least). But performance is always a priority in our core. And regardless of whether another platform might boot faster than ours or not, I think most would agree that ProcessWire's performance is always better in the areas where it really counts. 

In PW 2.4.5 (dev) if you want to measure boot-up times, there is now a "Timers" section in the debug info at the bottom, but debug mode must be enabled to see it. Keep in mind that debug mode takes up quite a bit of resources in its own right, so actual times would likely be less with debug mode off. 

post-2-0-15684100-1403031706_thumb.png

  • Like 13

Share this post


Link to post
Share on other sites

Hey Ryan,

Thanks for the extensive response. I'll download and try the dev branch and see how that goes, looks like some great improvements.

Regarding boot times for processwire; I appreciate that PW is doing a lot of work initially to provide the great API, and I put a lot of the processing time down to this, it's well worthwhile to get the API PW provides.

With regards to Modx (Evo) I think modx is definitely more 'basic' than PW but I have to say it also seems blazingly fast. I always wondered if this was simply down to the database style - having all page fields in one page record rather than pulling 30 different field values from 30 different tables when selecting page data. I don't know enough about how you do the database magic in PW to know if this is a point of difference, and my knowledge of SQL is good only to a certain level - modx style.

I appreciate we are only talking about milliseconds here, and even 100ms is almost impossible to notice. But from an SEO/pagespeed point of view it is important. I guess the reason I've got a bit pedantic about this is I've converted a modx site to PW and seen it slow down which is not the result I was after! The slowdown was quite extensive until I started using Markup Cache which is so simple to use and so effective. Now with caching the site is loading probably 200ms slower than essentially the same site on Modx, which I'm happy with.

Markup Cache: This seems to be a little known and underrated tool. There is not a lot in the documentation or forums about this module. When I get a moment I'll write up a page about markup cache as it seems to me it is not used by many PW users but I've personally found it to be incredibly useful. It's taken some of my heavier pages from sluggish to quick while allowing me to keep dynamic pages dynamic "in part" rather than serving a completely static page using other caching methods. This allows me to collect stats, log views of certains part of a page etc.

Keep up the good work bro, you are an inspiration.

  • Like 1

Share this post


Link to post
Share on other sites

@muzzer: markup cache is definitely a great tool if you've got otherwise highly dynamic pages that can't be cached as a whole. If, on the other hand, the page stays pretty much same on each page load, I'd suggest looking more into template level caching -- that way you'll have entire page cached instead of caching separate regions and then combining those on the fly.

If you're really interested in speeding up your sites, ProCache is the ultimate solution. For the most part it'll be serving static pages without involving PHP or MySQL at all, which will always beat the speed of any page built on the fly (regardless of what CMS is used).

Just saying.

  • Like 1

Share this post


Link to post
Share on other sites
.........

Still, I wonder why my modx sites are so blazingly fast compared to PW sites, even static (no api calls) pages. I know PW is more advanced and offers much more than modx so some expected overhead there, but it does seem a little out of proportion. Don't get me wrong, I'm not complaining, lovin' PW :-)

Having run a couple of MODX Evolution sites in the past i can confirm that this system was/is pretty snappy on both the manager part and frontend rendering. I'm guessing that this is in part because of the relatively simple nature of the beast. Remember MODX Revolution? With it came more power but also backend performance and frontend rendering times took a dive.

There is maybe another thing to consider, which you are probably aware of but maybe not. In Evolution, documents (think PW pages) are set to 'cacheable' by default. This means that all page output is cached. What was nice about the system was that, if needed, you could still call uncached snippets and such from within an otherwise cached document. But most of the times you would call snippets cached, i.e. without the exclamation mark. So in reality, in Evolution, most documents tend to be cached, either wholly or at least in part.

So if you compare Evolution <--> PW with regards to total rendertime on the frontend (which is the only thing Google and end-users really care about) you should take caching into consideration for a fair comparison. Use template caching where possible and if not Markup Cache, at least for PHP/API/DB stuff.

I see that with some use of Markup Cache you were already able to get within 200 ms of the comparable Evolution site. Maybe with Ryan's optimizations to the bootstrap this will only go down. That's pretty good if you ask me. Another thing to consider is that suboptimal use of the PW API in temlate files or other places and loaded modules can affect performance negatively. So be sure to scrutinize your PW projects for this stuff.

In the end i think the power to performance ratio that PW delivers is pretty awesome!

  • Like 7

Share this post


Link to post
Share on other sites

Looking at the timers:

boot 0.2320 - includes all boot timers boot.load 0.1985 - includes all boot.load timers boot.load.fieldgroups 0.0508

Is there room for further optimisation? What is taking so long between boot.load.fieldgroups and boot.load? There are 48 queries, 25 modules loaded (I installed PageListPin, ProcessPageDelete, ProcessPagePublish, SessionLdapAuth), no caching, 2.5.4 dev

Share this post


Link to post
Share on other sites
What is taking so long between boot.load.fieldgroups and boot.load? 

,,so long,, u funny

u.answer live in rest of boot.load.* 

boot.load.modules 0.0313
boot.load.fields 0.0156
boot.load.pages 0.0143
boot.load.fieldgroups 0.0079
boot.load.templates 0.0044
boot.load.fieldtypes 0.0006
boot.load.users 0.0003
boot.load.roles 0.0002
boot.load.permissions 0.0002
----------------------------------
boot.load all 0.0918 

boot.modules.autoload.ready 0.0093
boot.modules.autoload.init 0.0264
==================================
boot all 0.1373
Is there room for further optimisation? 

mabe u install APC ?

  • Like 1

Share this post


Link to post
Share on other sites

I'm not sure you can directly compare modx and ProcessWire on load times unless you have them both in original state without any modules installed, except those required by the core. Even then, they may not be directly comparable unless they are accomplishing the same thing and providing the same level of tools at bootstrap. ProcessWire's boot time will be very much affected by how many "autoload" modules and running and how much activity they perform during their initialization process. It will also be affected by your overall quantity of modules, fields and templates. I would assume modx to be the same in that regard (assuming they have some equivalent of autoload modules, fields, templates, etc.). So whichever one is faster may have as much to do with how much stuff you are asking it to load as part of the bootstrap process. 

We do have a rather extensive API that most systems don't, so we do hand over a lot of ready-to-use tools to your template file and part of our bootstrap, and very likely most systems you'd compare PW to don't have near the scope of tools that we do. But we always want PW to have the best performance possible. In PW a "no api calls" page is not going to make any difference in the time of the bootstrap process, because execution of your code (in your template file) occurs after the bootstrap process. Again, I'd assume modx to be somewhat similar in this regard too. 

I did measure the time it takes for our bootstrap is a fairly blank state (with regard to modules) and found I was getting about 0.2s (200ms) bootstrap times. Admittedly, this is on a slow computer more than half a decade old, but did have APC enabled (APC is an opcode cache). Then I disabled APC and found they were at least 100ms higher. This is the time it takes ProcessWire to boot and give control to your code. As far as how long it takes after that depends entirely on you and what you are doing with the API. I would guess that in Soma's case, he's got a faster computer than me and perhaps with an opcode cache too. 

Even though my computer is old and doesn't have much in the way of horsepower, I thought there was some potential to speed up the bootstrap process (there is always room for optimization), so I've gone ahead and applied some optimizations to the dev branch, now available in PW 2.4.5. On the same computer as before, I've got the bootstrap down to 0.08s (80ms) with APC enabled, or 0.15 (150ms) with APC disabled (no opcode cache). This is with a logged-in user, so it's a pretty good performance boost. Is it possible to tell the difference in speed in person? No–we're talking about amounts of times that are beyond our perception (beyond my perception at least). But performance is always a priority in our core. And regardless of whether another platform might boot faster than ours or not, I think most would agree that ProcessWire's performance is always better in the areas where it really counts. 

In PW 2.4.5 (dev) if you want to measure boot-up times, there is now a "Timers" section in the debug info at the bottom, but debug mode must be enabled to see it. Keep in mind that debug mode takes up quite a bit of resources in its own right, so actual times would likely be less with debug mode off. 

attachicon.gifScreen shot 2014-06-17 at 2.59.23 PM.png

how to show these timing information ?

Share this post


Link to post
Share on other sites

Enable $config->debug in you're site/config.php, then they're appended to every site in the admin backend.

Share this post


Link to post
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

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By MoritzLost
      Process Cache Control
      This module provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions.
      The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu:
      Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Clear the ProCache page render cache (if your site is using ProCache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides:
      An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README.
      Plans for improvements
      If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind:
      Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions!
      Links
      https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory CHANGELOG in the repository Screenshots


    • By verdeandrea
      Hello,
      I am using ProCache v3.1.8 on ProcessWire 3.0.96.
      Everything worked fine in the past, but today I noticed that the css file serverd by procache gives a 410 error. 
      The file is there, I checked.
      I deleted the cached files, I deleted the css file, I looked into the .htaccess file looking for some clues about this problem but nothing worked.
      The only way i can see my website correctly again is disabling ProCache. 
      Has anyone any clue on what could be the cause of the problem or on what should I do to fix it?
      Thanks!
    • By abdulqayyum
      Hy Processwire community,
      There are some problem in fileCompiler cache.
      when i change under the directory \site\templates\ it must change under the directory /site/assets/cache/FileCompiler/site/templates/
      but it does not update and functionality working with /site/assets/cache/FileCompiler/site/templates/ directory.
       
      In this case please suggest me how i clear fileCompiler cache?
      what i have to clear it manually?
      Thanks AbdulQayyum.
    • By modifiedcontent
      I had upgraded my Apache configuration to include PHP7.2 and PHP7.3 for a Laravel-based script on the same server. Somehow it/I messed up a previously fine Processwire site, in a very confusing way.
      The site still looks fine, but editing template files has no effect whatsoever. It is stuck on some kind of cached version. I have already disabled PHP7's OPcache, cleared browser caches, etc, with no effect.
      The pages now apparently come from PW's assets/cache/FileCompiler folder, even though I never enabled template caching for this site.
      I have tried adding "namespace ProcessWire;" to the top of the homepage template file, but then I get this fatal error:
      My functions.php file pulls data in from another Processwire installation on the same VPS with the following line:
      $othersitedata = new ProcessWire('/home/myaccount/public_html/myothersite/site/', 'https://myothersite.com/'); That apparently still works fine; the site still displays data from the other installation, but via the "cached" template that I am now unable to change.
       
      I don't know where to start with this mess. Does any of this sound familiar to anyone? Any pointers in the right direction would be much appreciated. 
       
      Edit:
      Adding "$config->templateCompile = false;" to config.php results in the same fatal error as above. 
    • By Peter Knight
      Is there a way to make JPGs progressive by default via the API?
      I've added the following to my site/config.php file but user-uploaded images are often displayed as non progressive.
      $config->imageSizerOptions = array( 'upscaling' => true, // upscale if necessary to reach target size? 'cropping' => true, // crop if necessary to reach target size? 'autoRotation' => true, // automatically correct orientation? 'interlace' => true, // use interlaced JPEGs by default? (recommended) 'sharpening' => 'soft', // sharpening: none | soft | medium | strong 'quality' => 95, // quality: 1-100 where higher is better but bigger 'hidpiQuality' => 60, // Same as above quality setting, but specific to hidpi images 'defaultGamma' => 0.5, // defaultGamma: 0.5 to 4.0 or -1 to disable gamma correction (default=2.0) ); Thanks
×
×
  • Create New...