7 Comments

  1. Luigi
    June 12, 2017 @ 9:06 pm

    Thank you very much for this guide. What i wish to see if possible is another layer of how to control and maintain this installation in order to avoid having a broken website/server.
    That would be really fabulous if you could explain.

    Thanks,
    Luigi

    Reply

  2. andrew
    June 13, 2017 @ 12:02 pm

    What is better for a large woocommerce affiliate store – MariaDB or PerconaDB?

    Reply

    • Dave Hilditch
      June 13, 2017 @ 12:08 pm

      Both are far better than plain MySQL, but PerconaDB is better because it comes with better performance analysis tools.

      Reply

  3. Danny
    July 13, 2017 @ 10:22 pm

    Hi Dave,
    Very interesting article, but there’s little info about the setup. For the average webmaster it will be hard to control and debug… and the paid services are out of reach for many. I’m curious why you use Varnish when in the serverpilot guide you use cloudflare to replace it . I’m setting up a daily deals site, and some posts need to be changed or deleted every day, so I’m curious how long pages are pages cached, or how to configure it. Or maybe I can decide not to use it and just skip the varnish setup? And what about redis? Perhaps the serverpilot setup is more suitable for those less familiar with configuring a server?

    Reply

    • Dave Hilditch
      July 14, 2017 @ 2:33 pm

      Varnish only caches pages for a VERY short amount of time – circa 5 minutes typically. It’s used to handle RUSH traffic.

      For page-caching, using something like W3 Total Cache you can control how long the page cache exists, and you can also provide an XML sitemap to prime the cache.

      For sure, the Server Pilot set up is probably simpler – especially because Varnish cache can be technical to configure if there are any plugins that need configured that aren’t included in my scripts.

      Redis is awesome for object caching – even with page caching in W3 Total Cache I will typically use disk-based caching because this allows W3 Total Cache to pump these pages out without loading all of WordPress core (if you use Redis for page caching, it has to load all of WordPress core).

      Reply

      • Danny
        July 17, 2017 @ 2:40 pm

        The drawback of serverpilot is that when you install other applications on the server then serverpilot could screw them up. So I will probably go far this rocketstack. My only concern is the caching, having read about Simple Ajax Chat in the cache busting list: what happens if a logged in admin views a front-end page. Will the admin bar at the top, any admin edit buttons on the page, etc. get cached, so the next visitor will see that, or how does that work? As that’s no admin url, there’s no url parameters, and it doesn’t look like the extra content is added via js. Is it possible to just disable / override varnish for the time being? And how does one test plugins and themes for cache busting behavior?

        Reply

        • Dave Hilditch
          July 18, 2017 @ 9:45 am

          Yes – you can just skip installing varnish. Or follow the full guide and just switch varnish off. It’s clever enough that if Varnish isn’t working, is broken, or is off, then nginx just passes the web requests directly to PHP/WordPress.

          re: Simple Ajax Chat – I highly recommend you use a different plugin.

          re: Admin bar – these don’t get cached because there are varnish rules to avoid caching for logged in users.

          re: testing for cache busting behaviour – typically most plugins don’t even qualify for needing testing – i.e. most plugins apply content to your pages that applies to all users. Plugins that require testing are the ones that create different content per user – e.g. shopping baskets, user wishlists, users recently viewed products, or plugins that do messaging between users (or between users and admin). To test, view a page (logged out) with user-specific content in browser 1 (e.g. add something to your wishlist, or send a message with simple ajax chat or similar), then immediately view the same page in browser 2 (also logged out). If browser 2 sees browser 1’s user-specific content then they have not implemented their code in a page-caching compatible way.

          Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

  • Hullo and welcome! Chat directly to the site owners below.
Latest Message: