<p>I don't have specific answers to your questions, but that's mainly because I feel there are some clarifications and observations that I think might be more helpful.</p>

<p>The thread you linked to is referring to template caching using the Craft <code>{% cache %}</code> tag in a template.  All of its cached data is stored in the database in the <code>craft_templatecache*</code> tables, not on the file system.  See <a href="https://craftcms.stackexchange.com/a/13383/57">here</a> for an explanation of the different caching methods Craft uses.</p>

<p>The compiled files in <code>craft/storage/runtime/compiled_templates</code> are what happens when Twig needs to render a template in the <code>craft/templates</code> folder. The first time a template is requested, Twig will take that uncompiled template and compile it down to PHP and save it in the <code>compiled_templates</code> folder.  If another request comes in for that same template, it will check the  file's last modified date and if it hasn't changed, it will execute the compiled template directly.</p>

<p>Given that an actual 404 request wouldn't create new files in the <code>compiled_templates</code> folder (other than the 404 template that it might need to render), I'd guess that the assumption that the 404 requests caused the <code>compiled_templates</code> folder to fill up enough to run out of disk space is incorrect.  It could be that enough log files or some other by-product of the testing caused more disk space to be used, but it's hard to tell without looking at the server.</p>

<p>You also mentioned that the database went down.  Given that the <code>{% cache %}</code> tag stores its data in the database, my first hunch would be to look at the strategy for using the template cache tag on your templates.  Here is a good article that weighs the in-and-outs of using it: <a href="https://nystudio107.com/blog/the-craft-cache-tag-in-depth" rel="nofollow noreferrer">https://nystudio107.com/blog/the-craft-cache-tag-in-depth</a></p>

<p>Two other things worth thinking about. A responsible security pen-tester is going to know better than to test on a live site by hammering it to the ground. But it's possible that maybe they were being responsible and the server is under-powered to handle any spike in load.</p>

CC BY-SA 3.0
2017-06-28T00:13:07.730Z
2017-06-28T10:59:37.633Z
2017-06-28T10:59:37.633Z
Brad Bell
<p>We just moved an installation of one of our sites to a new server. Previously, it was on a machine where the versions of Ubuntu / PHP prevented us from upgrading the Craft core version from 2.3.x to 2.6.x.</p>

<p>A few days ago, our client ran one of their security penetration tests that result in a large number of 404 HTTP requests against our site. This test generated enough unique cached templates in <code>/craft/storage/runtime/compiled_templates</code> to fill up the remaining disk space on the server - which appeared to take MySQL service down and serve 500 template errors afterwards.</p>

<p>Since bringing the site back up, we've been trying to identify and resolve the root issue behind the template caching that took the site offline. We've read <a href="https://craftcms.stackexchange.com/a/15925/6917">this thread</a> and are trying to formulate the right questions to prevent this from happening to this site the next time the client runs their tests.</p>

<ol>
<li>Were there any significant changes in how Craft was handling template caching between versions 2.3 and 2.6 that would've allowed the old site to handle a spike in traffic without this issue?</li>
<li>Is there a configuration setting we missed to either avoid caching 404 pages, or reference the same cached template for all 404 requests?</li>
<li>Are there any special directory or file permission considerations to take into account that would prevent Craft from periodically clearing disk space here? Are there any automated cleanup tasks that should have run before the directory filled up?</li>
<li>Are there any OS, PHP or Apache settings that we should compare between the old server and new server that would help clarify the issue?</li>
</ol>

<cache><php><error><404><apache>
Security test generated large compiled_templates directory, site outage
# Security test generated large compiled_templates directory, site outage

(Asked by: username_0 on 2017-06-27)

We just moved an installation of one of our sites to a new server. Previously, it was on a machine where the versions of Ubuntu / PHP prevented us from upgrading the Craft core version from 2.3.x to 2.6.x.

A few days ago, our client ran one of their security penetration tests that result in a large number of 404 HTTP requests against our site. This test generated enough unique cached templates in `/craft/storage/runtime/compiled_templates` to fill up the remaining disk space on the server - which appeared to take MySQL service down and serve 500 template errors afterwards.

Since bringing the site back up, we've been trying to identify and resolve the root issue behind the template caching that took the site offline. We've read [this thread](https://craftcms.stackexchange.com/a/15925/6917) and are trying to formulate the right questions to prevent this from happening to this site the next time the client runs their tests.

1. Were there any significant changes in how Craft was handling template caching between versions 2.3 and 2.6 that would've allowed the old site to handle a spike in traffic without this issue?
2. Is there a configuration setting we missed to either avoid caching 404 pages, or reference the same cached template for all 404 requests?
3. Are there any special directory or file permission considerations to take into account that would prevent Craft from periodically clearing disk space here? Are there any automated cleanup tasks that should have run before the directory filled up?
4. Are there any OS, PHP or Apache settings that we should compare between the old server and new server that would help clarify the issue?

**Tags:** cache, php, error, 404, apache

---

## 1 answers

### Answer by username_1 on 2017-06-28. Score: 3

I don't have specific answers to your questions, but that's mainly because I feel there are some clarifications and observations that I think might be more helpful.

The thread you linked to is referring to template caching using the Craft `{% cache %}` tag in a template. All of its cached data is stored in the database in the `craft_templatecache*` tables, not on the file system. See [here](https://craftcms.stackexchange.com/a/13383/57) for an explanation of the different caching methods Craft uses.

The compiled files in `craft/storage/runtime/compiled_templates` are what happens when Twig needs to render a template in the `craft/templates` folder. The first time a template is requested, Twig will take that uncompiled template and compile it down to PHP and save it in the `compiled_templates` folder. If another request comes in for that same template, it will check the file's last modified date and if it hasn't changed, it will execute the compiled template directly.

Given that an actual 404 request wouldn't create new files in the `compiled_templates` folder (other than the 404 template that it might need to render), I'd guess that the assumption that the 404 requests caused the `compiled_templates` folder to fill up enough to run out of disk space is incorrect. It could be that enough log files or some other by-product of the testing caused more disk space to be used, but it's hard to tell without looking at the server.

You also mentioned that the database went down. Given that the `{% cache %}` tag stores its data in the database, my first hunch would be to look at the strategy for using the template cache tag on your templates. Here is a good article that weighs the in-and-outs of using it: <https://nystudio107.com/blog/the-craft-cache-tag-in-depth>

Two other things worth thinking about. A responsible security pen-tester is going to know better than to test on a live site by hammering it to the ground. But it's possible that maybe they were being responsible and the server is under-powered to handle any spike in load.


---

