Reasonable PHP execution time

[DrQuincy]

I've done quite a number of PW sites now but have only just started looking at performance. I do a lot of custom work using libraries and have been used to very low PHP execution times as a result. Generally under 50ms with OpCache enabled.

On my local MAMP server PW is taking generally over half a second to run. That's fine, it's an iMac and not really made as a web server. It speeds up considerably once I upload to my host where it runs on CentOS and Litespeed using PHP 7.4 with Opcache enabled.

I am testing the speed of a small brochureware site, currently only ~20 pages. I have a very simple MVP framework I have added so I can separate getting data from PW from the actual HTML templates. Each template has a presenter that loads data from Models (just classes that get the data from PW and format accordingly). From experience, this simple reflection should not slow PW down — and I don't think it does.

On my host server I have compared one a similar custom brochure site to this current PW one.

Custom site (no Opcache): ~0.03ms execution time
PW site (no Opcache): 0.35 to 0.5ms execution time
Custom (with Opcache): ~0.02ms execution time
PW (with Opcache): 0.18 to 0.35ms execution time

I have broadly split the timings via a few tests:

Just running the page — ~30-40ms
Starting MVP framework — ~10-20ms
Running global function — ~60-100ms  (getting global settings from template and a few other bits all just getting data from PW pages)
Loading rest of page — ~70-200ms (loads a page with a few fields, one is a repeater with 24 fields including a couple of nested repeaters and a page reference array)

So the PHP execution time ranges from 180ms to 350ms when using OpCache on the exact environment I will use for the live site. It is a shared server and times always vary but the company I use have very good hardware and are strict about not overselling their resources so as shared servers go, it's a good one.

Template cache seems to makes little-to-no difference.

I have a somewhat blinkered view here since I don't use off-the-shelf CMSs very often but is this pretty much the execution time you would expect for a small brochure site? I.e. it's just the overhead you have to accept when using something this powerful. This is not a criticism of PW, I am just wondering if this is the norm and that trying to make it any faster is going to be a waste of my time (assuming I do not have the budget to spend on better hardware, which I don't).

I do have one old WordPress site I look after and that seems to average 110ms execution time under the same environment — but I don't think it's a fair comparison since it's a five page site with no plugins installed. From other WP sites I have seen once you add plugins — which you need to do anything half-decent — then it really starts slowing down.

Would ProCache make a difference or is this more for high-traffic sites (this site would not be high traffic)? Is ProCache as low maintenance as OpCache or is it easy to end up with stale data in certain contexts?

Thanks. ?

 

[elabx]

5 hours ago, DrQuincy said:

Would ProCache make a difference or is this more for high-traffic sites (this site would not be high traffic)? Is ProCache as low maintenance as OpCache or is it easy to end up with stale data in certain contexts?

I think ProCache will always bring benefits as it basically turns the website into a static website, routing requests directly to html files. It will always have the bottleneck of the first request after the cache expire, so there's that (unless you do some work around it with cron for example). But as long as you configure your cache to expire correctly after page updates, there shouldn't be much trouble if your site is brochureware.

[teppo]

10 hours ago, DrQuincy said:

So the PHP execution time ranges from 180ms to 350ms when using OpCache on the exact environment I will use for the live site. [...]

I have a somewhat blinkered view here since I don't use off-the-shelf CMSs very often but is this pretty much the execution time you would expect for a small brochure site? [...]

I do have one old WordPress site I look after and that seems to average 110ms execution time under the same environment — but I don't think it's a fair comparison since it's a five page site with no plugins installed. From other WP sites I have seen once you add plugins — which you need to do anything half-decent — then it really starts slowing down.

Those numbers seem pretty normal. Just for comparison:

• The doc (HTML) part of a fairly complex site I recently finished takes ~600-900ms when I'm bypassing ProCache. This is from browser, though, so could be a bit different from what you're measuring (not sure how exactly you got these numbers). With ProCache I'm getting consistent < 100ms. ProCache serves content directly from disk (via Apache), bypassing PHP and database, so it's naturally quite a bit faster.
• Took a cursory glance at a couple of (also relatively complex) WordPress site that I know for a fact are well built and hosted on pretty powerful hardware, and load times for these were somewhere between ~1.5-3 seconds uncached, 200-400ms cached (static cache using nginx, I believe).

In my opinion 1-3 seconds would still be "pretty good" for just about any ProcessWire or WordPress site without proper caching. Anything below 4-5 seconds is in the "pretty normal" range, while 5-10 seconds is just plain wrong (but sadly not that rare). 5+ seconds is usually a sign of really bad hosting, or really bad implementation ?

Might be worth noting that, in my experience at least, PHP is rarely the real bottleneck: if the server returns the markup in a few hundred milliseconds but then there's blocking JavaScript, CSS, or perhaps a large image that takes hundreds of milliseconds to seconds at worst to finish loading and/or executing, it would be better to focus on that. Just saying; developers (including yours truly) have a tendency to focus way too much on shaving milliseconds off one end, even if at the other end it might be possible to shave off seconds ?

10 hours ago, DrQuincy said:

Template cache seems to makes little-to-no difference.

Template cache loads the page from the disk and doesn't execute any of your markup generating code, but it still has to go through ProcessWire, so there's definitely some overhead there compared to ProCache. How beneficial template cache is (in comparison to non-cached site) depends a lot on how complex the site is and how well it's already optimized.

10 hours ago, DrQuincy said:

Would ProCache make a difference or is this more for high-traffic sites (this site would not be high traffic)? Is ProCache as low maintenance as OpCache or is it easy to end up with stale data in certain contexts?

Kind of covered this already, but to reiterate: it would definitely make a difference.

ProCache is usually low maintenance, but this depends a bit on how your content is generated — such as whether it's all from stored with/in ProcessWire, or if you have parts that are loaded (especially with PHP) from other sources. Typically ProCache gets flushed based on predefined rules when pages are saved, so if your content isn't stored on pages, that could be a potential issue. In which case you may even need to programmatically flush it (via cron or some other method).

You can configure the preferred lifespan, so technically you can make ProCache stick to cached data almost indefinitely, and thus ProcessWire/ProCache will very rarely need to regenerate it. Though, again, in my opinion this is something that folks tend to pay too much attention to: if your typical page render (non-cached) takes 1-3 seconds at most and your cache hit ratio is 99+%, cache warming has so little actual effect that it's (in my opinion) mostly just wasted time and effort ?

[dragan]

@DrQuincy

Not much I can add here, other than maybe encouraging you to take a look at WireCache and MarkupCache, which is in core.

[DrQuincy]

Thanks for all the replies, this place is mega-helpful!

@teppo, that is a very detailed response and is much appreciated. Just to be clear, my numbers are from timing the execution of PHP — so from the start of the index.php right through to the end. I am not timing anything network-related. When you say “The doc (HTML) part of a fairly complex site I recently finished takes ~600-900ms” are you referring to the PHP execution time, as I am, or is this how long it takes for your browser to get the whole of the HTML document? Even so, if I add on some time for the request my simple brochureware site is still quick compared to your complex site so it tallies.

You've pretty much answered my question then that this is how it is out of the box. That's good to know.

Will ProCache automatically disable itself for POST requests (e.g. contact forms)? If you have a template that, for example, polls a third party service using cURL, do you simple just disable ProCache for that template in the admin? Is it possible to try ProCache first or do you need to buy it?

I will look at WireCache and MarkupCache, thanks @dragan.

[teppo]

1 hour ago, DrQuincy said:

When you say “The doc (HTML) part of a fairly complex site I recently finished takes ~600-900ms” are you referring to the PHP execution time, as I am, or is this how long it takes for your browser to get the whole of the HTML document?

This was from browser, so some network latency was included in that number. If I check the render time from the site, it's roughly the same, average being somewhere around 1s. I'm looking at the numbers provided by Tracy for a logged in user, so the higher time is explained by the stuff that doesn't apply to visitors (admin tools, Tracy itself, etc.)

Don't have a great testing setup for non-cached visitor execution time ?

1 hour ago, DrQuincy said:

Will ProCache automatically disable itself for POST requests (e.g. contact forms)? If you have a template that, for example, polls a third party service using cURL, do you simple just disable ProCache for that template in the admin? Is it possible to try ProCache first or do you need to buy it?

ProCache is always disabled on POST requests, GET variables and cookies that bypass cache are configurable.

I tend to rely on just the normal invalidation cycle — I have reasonably short cache time configured, so I don't have to clear the cache manually / programmatically very often. Depends on the use case, of course; for most regular websites it really doesn't matter if the data is 15..30 minutes old, even if it's of the "rapidly updating" sort. It's easy to flush the cache with PHP, though: see https://processwire.com/api/ref/pro-cache/ for more details.

As for the "try before you buy" part, I don't actually know if there's such an option. You could try contacting Ryan ?

[LostKobrakai]

15 minutes ago, teppo said:

As for the "try before you buy" part, I don't actually know if there's such an option. You could try contacting Ryan ?

Afaik there's no such option, but ryan does allow for refunds.

[DrQuincy]

Fantastic, thanks so much!

I've also never heard of the Tracy plugin before so will check that out too!

[DrQuincy]

A couple of further questions on the core's caching.

1. When you enable the cache on a template (from the Cache tab), what is this actually caching? Does this relate to the generated PHP files in the FileCompiler folder? what are the use cases for this?
2. Unlike the above method which invalidates the cache upon template saving out of the box (default option), if you use $cache->get() do you need to manually clear the cache using hooks if you want cache to be cleared upon page saving? I am assuming so and $cache is pretty much a wrapper for something like PHPFastCache.

I could not find anything in the core for MarkupCache in V3.

Thanks.

[szabesz]

23 hours ago, LostKobrakai said:

Afaik there's no such option, but ryan does allow for refunds.

Additionally, Ryan is usually very busy on weekdays so he might miss some messages sometimes. He usually addresses issues from Friday to Sunday, but this is a just a general guideline for you not a "rule" or something like that. For this reason, if you buy one of his modules, I recommend that you place the order before or on a Friday and make sure you will have enough time to test it so that you don't run out of the 7 day timeframe of the refund option in case you need it:

https://processwire.com/store/pro-cache/
see: Terms and Conditions: "...If you find ProCache does not meet your needs and that you won't be able to use it, let us know within 7 days of purchase and we will refund your money in full...."

[DrQuincy]

Thanks, that's useful to know.