Answers.Body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Craft 3 ought to solve a lot of this problem. But that's a way off it seems.</p>
  
  <p>PS: as a rough guide...</p>
  
  <p>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.</p>
  
  <p>For those that would like an indicator.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-24T20:21:00.007Z
Answers.Text: 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. :)
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-24T22:22:12.697Z
Answers.Text: 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.
Answers.UserDisplayName: André Elvan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-24T11:10:14.463Z
Answers.LastActivityDate: 2015-11-24T11:55:32.403Z
Answers.LastEditDate: 2015-11-24T11:55:32.403Z
Answers.UserDisplayName: Matt Wilcox
Answers.Body: <p><a href="https://supercool.github.io/2015/06/08/making-craft-sing-with-varnish-and-nginx.html" rel="noreferrer">This is a great resource</a> on improving performance as it's a multi-pronged attack:</p>
  
  <ol>
  <li>Native craft caching <code>{% cache %}</code> which you mentioned you have done</li>
  <li>CDN and Browser caching</li>
  <li>Varnish and other tools, including plugins like <a href="https://github.com/sjelfull/Craft-CacheWarmer" rel="noreferrer">Cache Warmer</a></li>
  </ol>
  
  <p>I concentrated on cache as this is usually where the bottleneck seems to happen in Craft. Apologies if you've addressed all these already!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-23T10:33:56.517Z
Answers.Text: 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.
Answers.UserDisplayName: Matt Wilcox
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-23T09:59:54.743Z
Answers.LastActivityDate: 2015-11-23T09:59:54.743Z
Answers.UserDisplayName: Merlin
Answers.Body: <p>Something about your math or the way you're measuring <em>simultaneous</em> users is way off. </p>
  
  <p>I'm assuming they're not actually simultaneous <em>requests</em> since 8 gigs of ram with 450 users is only about 17 MB/user. That's about <a href="https://buildwithcraft.com/docs/requirements" rel="nofollow">half</a> 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).</p>
  
  <p>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 <code>AllowOverride</code> for <code>.htaccess</code> files that's a huge <a href="http://www.eschrade.com/page/why-is-fastcgi-w-nginx-so-much-faster-than-apache-w-mod_php/" rel="nofollow">performance killer</a>.) </p>
  
  <p>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.</p>
  
  <p>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 <a href="https://www.digitalocean.com/community/tutorials/how-to-setup-fastcgi-caching-with-nginx-on-your-vps" rel="nofollow">fastcgi_cache</a> does. In these cases, <code>fastcgi_cache</code> 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. </p>
  
  <p>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. </p>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-30T15:59:17.187Z
Answers.Text: 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.
Answers.UserDisplayName: Matt Wilcox
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-30T16:35:22.063Z
Answers.Text: 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...
Answers.UserDisplayName: RitterKnight
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-25T16:36:02.350Z
Answers.LastActivityDate: 2015-11-25T17:03:55.030Z
Answers.LastEditDate: 2015-11-25T17:03:55.030Z
Answers.UserDisplayName: RitterKnight
Answers.Body: <p>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. </p>
  
  <p>In your case, there's probably no other solution then using a static HTML-cache, with i.e. Varnish.  </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-23T19:37:21.643Z
Answers.Text: 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.
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-23T10:50:01.963Z
Answers.LastActivityDate: 2015-11-23T10:50:01.963Z
Answers.UserDisplayName: Chris
Answers.Body: <p>As described in <a href="https://craftcms.stackexchange.com/a/22642/5437">this thread</a>, we found that our Craft site was gradually getting slower and slower over a period of several days, despite using the <code>{% cache %}</code> tag. When we cleared the template cache, the site would be fast again until the cache grew in size and got slow again.</p>
  
  <p>It was our uninformed use of the <code>{% cache %}</code> tag that contributed to this.</p>
  
  <p>It's important to firstly understand that <strong>using <code>{% cache %}</code> without any parameters generates a separate copy of the block for every single URL that uses it</strong>. 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.</p>
  
  <p>Read my full answer at: <em><a href="https://craftcms.stackexchange.com/a/22642/5437">Cache issues making site super slow in production but not in dev mode</a></em></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-30T23:30:46.927Z
Answers.LastActivityDate: 2017-10-30T23:30:46.927Z
Answers.UserDisplayName: Simon East
Body: <p>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.</p>
  
  <p>For info; both sites used the same dedicated Virtual Server, a quad core Xeon (minimum 800Mhz, burst to 2Ghz) with 8Gb RAM.</p>
  
  <p>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.</p>
  
  <p>Once the site is seeing 700 simultaneous visitors the CPU load is going into double digits and rapidly starts to spiral.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Why might Craft be performing so poorly in comparison, and how can I fix this?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-11-23T19:33:08.640Z
Comments.Text: If possible, I **highly** recommend switching to PHP 7. You will see _enormous_ speed boosts, likely improving load time by 50% or more.
Comments.UserDisplayName: Lindsey D
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-11-24T22:20:41.983Z
Comments.Text: 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).
Comments.UserDisplayName: André Elvan
Tags: <performance>
Title: How to improve unexpectedly poor Craft performance?
ThreadText: # How to improve unexpectedly poor Craft performance?
  
  (Asked by: username_0 on 2015-11-23)
  
  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?
  
  **Tags:** performance
  
  > **Comments:**
  > **username_1**: If possible, I **highly** recommend switching to PHP 7. You will see _enormous_ speed boosts, likely improving load time by 50% or more.  
  > **username_2**: 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).  
  
  ---
  
  ## 5 answers
  
  ### Answer by username_0 on 2015-11-24. Score: 2 | Accepted answer
  
  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.
  
  > **Comments:**
  > **username_1**: 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. :)  
  > **username_2**: 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.  
  
  ---
  
  ### Answer by username_3 on 2015-11-23. Score: 6
  
  [This is a great resource](https://supercool.github.io/2015/06/08/making-craft-sing-with-varnish-and-nginx.html) 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](https://github.com/sjelfull/Craft-CacheWarmer)
  
  I concentrated on cache as this is usually where the bottleneck seems to happen in Craft. Apologies if you've addressed all these already!
  
  > **Comments:**
  > **username_0**: 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.  
  
  ---
  
  ### Answer by username_4 on 2015-11-25. Score: 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](https://buildwithcraft.com/docs/requirements) 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](http://www.eschrade.com/page/why-is-fastcgi-w-nginx-so-much-faster-than-apache-w-mod_php/).)
  
  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](https://www.digitalocean.com/community/tutorials/how-to-setup-fastcgi-caching-with-nginx-on-your-vps) 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.
  
  > **Comments:**
  > **username_0**: 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.  
  > **username_4**: 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...  
  
  ---
  
  ### Answer by username_5 on 2015-11-23. Score: 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.
  
  > **Comments:**
  > **username_1**: 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.  
  
  ---
  
  ### Answer by username_6 on 2017-10-30. Score: 1
  
  As described in [this thread](https://craftcms.stackexchange.com/a/22642/5437), 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](https://craftcms.stackexchange.com/a/22642/5437)*
  
  
  ---
  
  