Markup cache and PW performance

[muzzer]

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.

 

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 

[teppo]

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?

[cstevensjr]

http://www.webperformancetoday.com/2012/04/02/latency-101-what-is-latency-and-why-is-it-such-a-big-deal/

http://www.webperformancetoday.com/2012/04/02/mobile-versus-desktop-latency/

http://www.webperformancetoday.com/2010/07/09/waterfalls-101/

[muzzer]

@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.

[Jonathan Dart]

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.

[muzzer]

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

[Soma]

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

[teppo]

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

[WillyC]

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 ?

[muzzer]

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

[ryan]

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. 

[kongondo]

Nice addition Ryan, thanks! (Timers)...

[muzzer]

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.

[teppo]

@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.

[matjazp]

Is ProCache supported on IIS?

[SiNNuT]

.........

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!

[matjazp]

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

[WillyC]

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 ?

[adrianmak]

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. 

Screen shot 2014-06-17 at 2.59.23 PM.png

how to show these timing information ?

[LostKobrakai]

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

[mr-fan]

first:

https://processwire.com/talk/topic/1126-how-to-debug-use-the-error-log/

second:

https://processwire.com/talk/topic/4810-debug-mode-on-front-end/

Edit: LostKobrakai was faster...

Edited January 14, 2015 by mr-fan