2

We have a seasonal website which gets very popular around this time of year. This year we ported it from ExpressionEngine to Craft, for all the obvious reasons. We were very surprised to discover that the Craft version of the site is using considerably more resources than the old EE one. I'm looking for any advice on how to get this load down.

For info; both sites used the same dedicated Virtual Server, a quad core Xeon (minimum 800Mhz, burst to 2Ghz) with 8Gb RAM.

This weekend the Craft site was dealing with around 500 simultaneous visitors but pushing the CPU load to 7. By judicious use of the {% cache %} tags I dropped the queries per page from 200 to 20, and the load dropped to around 4-5.

Once the site is seeing 700 simultaneous visitors the CPU load is going into double digits and rapidly starts to spiral.

We had to switch out to a static scrape of the site. At the peak last year we were dealing with 1000 simultanious visitors and did not need to switch out to a static site.

I should point out that both sites are loading all their assets off Amazon S3, so none of those files are having an impact. This is purely about Craft being able to deal with the number of requests it's getting.

Why might Craft be performing so poorly in comparison, and how can I fix this?

  • 2
    If possible, I highly recommend switching to PHP 7. You will see enormous speed boosts, likely improving load time by 50% or more. – Lindsey D Nov 23 '15 at 19:33
  • 1
    Just curious, what type of caching methods were you using in EE? In my experience EE and Craft natively is fairly on par when it comes to performance. But using CE Cache heavily in EE can make significantly bigger improvements than the built in {% cache %} tag can (since it stores the cached data in the database). – André Elvan Nov 24 '15 at 22:20
6

This is a great resource on improving performance as it's a multi-pronged attack:

  1. Native craft caching {% cache %} which you mentioned you have done
  2. CDN and Browser caching
  3. Varnish and other tools, including plugins like Cache Warmer

I concentrated on cache as this is usually where the bottleneck seems to happen in Craft. Apologies if you've addressed all these already!

| improve this answer | |
  • Thanks :) I've managed to trim another two queries by using cache a bit ore broadly, so a typical page is down to 17. All the assets are already through a CDN. We may have to investigate stuff like Varnish, but it's concerning to us that Craft is performing considerably worse than ExpressionEngine for the same site design on the same server. – Matt Wilcox Nov 23 '15 at 10:33
3

Something about your math or the way you're measuring simultaneous users is way off.

I'm assuming they're not actually simultaneous requests since 8 gigs of ram with 450 users is only about 17 MB/user. That's about half of what Craft's system requirements are which doesn't add up. And that doesn't even factor in the rest of your stack (since I'm assuming your db and everything else is on the same box).

I think what you're seeing is Craft is using more ram than EE and Apache is swapping like hell, especially if you're using the prefork MPM with mod_php built-in. It sounds like you've maxed out Apache though hard to say. (If you haven't already turned off AllowOverride for .htaccess files that's a huge performance killer.)

One option is to move your db to another box or resize your VPS for more ram; you could also setup another box and load balance between the 2 instances but that's expensive.

I would highly recommend swapping out apache for nginx or throwing nginx in front of apache as a proxy. You mention a static scrape—this is exactly what nginx's fastcgi_cache does. In these cases, fastcgi_cache is a godsend. Even if you keep the cache low, like expiring every 5 min, you've just quintupled your capacity by hardly doing any extra work.

Instead of creating static pages manually, nginx is going to do that for you on the fly; watch your ttfb fall dramatically. It doesn't have to be all or nothing either, you might choose to cache the home page and a few other key pages but keep everything else dynamic.

Varnish is an option but it's tougher to setup IMO, it'll eat more ram, and it's another piece to worry about in the stack. If you're running your own VPS, keeping your stack as simple as possible is no-brainer. nginx is a webmaster's swiss army knife that does most things well.

| improve this answer | |
  • These are simultaneous users as reported by Google Analytics live reporting, so it will be under reporting - but not by much I expect. RAM is not a problem, there is a good amount of free RAM (almost couple of gig) as reported by top on the server terminal, and there's no waiting for disk access going on either. CPU load is the only issue I'm having. Sitting nginx infront is sensible, and would be nicer with decent cache invalidation, but doesn't explain the actual resource problem; Craft is chewing a lot of CPU. – Matt Wilcox Nov 30 '15 at 15:59
  • Yeh I think you meant "over reporting" since a user idling on a page is going to count (even when Apache is not fulfilling the request). I would check your logs and make sure Apache is only serving PHP requests as you mention. Craft hits the DB harder than other CMS, so some of that load could be MySQL too. Since you run a VPS, it'd be trivial to spin up a php fpm and nginx combination in another instance and test it. Your VPS could be seeing some contention under load as well, hard to say. Not a big fan of "burstable" providers, they tend to oversell. I like htop for reporting... – RitterKnight Nov 30 '15 at 16:35
2

Thanks all. In summary: Craft 1/2 (based on Yii 1) just isn't very efficient, and beyond using the {% cache %} tags there's very little to be done which can make Craft itself faster. Time to first byte is especially poor.

Getting current versions of Craft to handle high traffic sites essentially requires better horsepower or side-stepping the issue by using something like Varnish or nGinx in front of it.

Alternatively, using the not-yet final PHP7 may help, but as that's not final or in any OS repo I think that's outside the bounds of reasonable expectation for a lot of cases.

Craft 3 ought to solve a lot of this problem. But that's a way off it seems.

PS: as a rough guide...

Craft 2.4, under Apache 2, with MySQL 5.5, PHP 5.4, running on a 2Ghz quad core Xeon with 8Gb RAM will hit a CPU load of 4 (maximum sustainable) with traffic around the 450 simultaneous users level.

For those that would like an indicator.

| improve this answer | |
  • PHP 7 is due to be officially released "any day now". I'd recommend jumping on it as soon as humanly possible... I promise, it'll put a giant smile on your face. :) – Lindsey D Nov 24 '15 at 20:21
  • I hope you're using some kind of opcache with PHP 5.4? If not, even upgrading to 5.6 will make a big difference. – André Elvan Nov 24 '15 at 22:22
1

The bottleneck for Craft 2.4 is the TTFB: it uses an older Yii framework release which was pretty slow, compared to other frameworks. The Caching implemented in Craft is summier; it does not allow full-page-caching and relies on an external server-side solution (such as Varnish) to handle that.

In your case, there's probably no other solution then using a static HTML-cache, with i.e. Varnish.

| improve this answer | |
  • 2
    Worth noting that Craft 3 will address the TTFB issue (since it's built on the newer Yii 2). Doesn't really help now, unfortunately... the release of Craft 3 is probably close to a year away. – Lindsey D Nov 23 '15 at 19:37
1

As described in this thread, we found that our Craft site was gradually getting slower and slower over a period of several days, despite using the {% cache %} tag. When we cleared the template cache, the site would be fast again until the cache grew in size and got slow again.

It was our uninformed use of the {% cache %} tag that contributed to this.

It's important to firstly understand that using {% cache %} without any parameters generates a separate copy of the block for every single URL that uses it. If the page is requested with a different querystring, again the block is regenerated and a new copy is saved to the cache. This means you could potentially have many dozens, hundreds, or even thousands of copies of the same block in your cache.

Read my full answer at: Cache issues making site super slow in production but not in dev mode

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.