7

I'm developing an EE site. I've used cache="yes" and refresh="60" parameters throughout. Locally, the site was running super quick (as expected).

However, when I pushed to the staging server, the 'wait' time on the site was painfully slow. Sometimes 5 seconds +. Tested via Pingdom

I contacted the host and their reply was this:

...it's an Expression Engine issue. It uses flock() which on our cloud platform is much slower than on local storage because we use network storage. By commenting out the flock statements it should speed up the site considerably.

Can anyone shed any light on this please? I've never come across it before.

What would my options be?

  • Move host?
  • Remove the cache tags?
  • Comment out the flock() statement? (somewhere in CI?)
  • CE Cache?
  • Something else...?

Thanks! : )

Improve this question
2
  • any chance you could share the name of the host? I'm just curious.
    – James Smith
    Nov 29, 2013 at 17:48
  • @JamesSmith Don't name the host, this isn't their fault. You'll see these issues with any "cloud" provider such as Amazon AWS. See my post below on how to properly solve this in a cloud environment. My method is scalable to millions of hits per second without having to touch EE at all or use any "cache" plugin.
    – Michael P
    Dec 2, 2013 at 4:57

3 Answers 3

Reset to default
2

CE Cache and ExpressionEngine's cache="yes" are not true caches. I hate that they advertise themselves as "caches" - they are not! They simply cache ExpressionEngine template parsing's output at a very high level, the entire PHP stack and ExpressionEngine core still needs to run. Not to mention database traffic, even for non-logged in members due to EE's horrible session management.

If you're suffering from slow IO performance due to high latency network storage. Absolutely no "cache" plugin or EE core modification is going to solve this.

If you want true caching, use nginx and fastcgi_cache which will give you true caching that will completely bypass PHP/EE stacks. It can very easily be set-up to achieve per-logged in member caches too.

We're doing this for many of our clients, with one in particular this method allows us to get hundreds of thousands of hits per second out of EE2.

Improve this answer
6
  • The other thing to note is. With nginx/fastcgi_cache, you can very easily and cheaply scale too into the ten's of thousands of hits per second range. With a $15/month VPS you'd get more performance out of this then a $1500/month dedicated server with a simple nginx/apache/php installation.
    – Michael P
    Dec 2, 2013 at 4:59
  • Man, this is really interesting. Do you mind if I contact about this? Or, maybe, to write more about the topic on someplace like coderwall?
    – Sobral
    Dec 3, 2013 at 0:08
  • 1
    @MichaelP You're mistaken. They certainly are cache technologies. They aren't proxies, which is what you are describing. Static caching with CE Cache does bypass EE once the content is cached. Fragment caching with the other drivers still allows the CMS to be run in order to have dynamic parts of the pages, but it can drastically speed up a site. I've seen webpages using fragment caching load in fractions of a second that generally take 15+ to load. One of the main problem with proxies is that cache breaking via the CP on content edits can be very difficult.
    – Aaron Waldon
    Dec 4, 2013 at 19:28
  • @AaronWaldon CE Cache (excluding static driver) caches the templating output. Read/write queries to the database still happen (due to EEs non-native sessions), the EE stack still uses 12-14 MB (+PHP+nginx) p/session, etc. I don't see that as a real "cache". Yes, it's partly caching something - but by definition it's not entirely correct to call it a cache, as it's really only caching a certain aspect of ExpressionEngine. For high volume sites, the read/write database calls for visitors/guests is a real dosey.
    – Michael P
    Dec 4, 2013 at 22:00
  • @AaronWaldon And while the Static Driver is better, yes, it's still invoking PHP which from memory still takes up 7-8MB/visitor (+nginx). We've built and host sites that serve hundreds of thousands of hits per second, CE Cache doesn't work in these type of environments (unless you throw massive resources at it). Fastcgi caching/proxying works with memory usage around 120-180KB/visitor. We've also got all the benefits of per-member caches (which your plugin can't do), and dynamic fragments via a lua script/custom plugin we've built which has nifty features.
    – Michael P
    Dec 4, 2013 at 22:01
0

Yes those are your options.

I personally suggest removing EE tags and using CE Cache. It's a great alternative which allows for multiple methods for caching:

file-based caching, database, APC, Redis, Memcache or Memcached) or full-page static caching

Improve this answer
2
  • This won't help. As I described below, CE Cache isn't a true cache. The entire EE/PHP software stack needs to run. Those laggy flock() statements over network storage still need to run. Use nginx/fastcgi_cache.
    – Michael P
    Dec 2, 2013 at 4:42
  • 2
    As described below, CE Cache does do true caching. The static driver also bypasses EE completely if the content is already cached. CE Cache is not a proxy like Varnish, but proxies are more involved to set up, and they can be difficult to integrate with the CMS to break the caches for specific pages when content is updated in the CMS. Proxies are very fast though and can be a good choice for sites, specifically for sites that have very static content. Running an optcode caching technology like APC (Alternative PHP Cache) is also recommended.
    – Aaron Waldon
    Dec 4, 2013 at 20:02
-1

You can use "Stash" to store (in the database) entire pages or parts of pages, with tags and conditionals rendered. I find that this speeds up pageload tremendously in some cases with some modules/fieldtypes.

another interesting one is "preparse" by solspace (which i haven't used yet). "Preparse allows you to parse EE template data when publishing/editing an entry..." and then stores it in a custom field.

Improve this answer
4
  • Again, this won't solve the issue and is a very bad suggestion. If the slowness is caused by EE's flock() calls over a high latency network storage sub-system then your options are to 1) by-pass the entire EE/PHP software stack by using proper caching, or 2) get a host that uses locally backed storage. With stash saving to the db, the entire PHP/EE2 (with all it's flock() calls) still need to execute. Not to mention that the DB will typically be even slower than storage, even network storage.
    – Michael P
    Dec 2, 2013 at 4:51
  • Michael i disagree. Typically (and hopefully) DB data is kept in large part in memory. The problem you mention is the file locks used by EE for caching templates and tags. My suggestion is to not use file based cache from EE itself.
    – GDmac
    Dec 2, 2013 at 10:46
  • He is file IO bound. While yes, a DB is faster then a read operation from disk that's not what your suggestion entails. Stash sits behind EE, the entire EE stack still needs to execute before it fetches the cached page from the database. The only thing Stash/CE Cache/etc are going to help with is when you are CPU bound.
    – Michael P
    Dec 2, 2013 at 11:24
  • The suggestion by your ISP is to not use flock(). While removing/commenting flock()is a bad idea, an alternative is to not use the parts of EE (caching) that rely on flock(), that is my suggestion. (This includes not saving templates as files in production)
    – GDmac
    Dec 2, 2013 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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