Disclaimer: I never used Varnish. So please do not treat this as Varnish v/s Nginx post. It will be wrong on my part to compare Nginx to something that I have never used.

Since we published WordPress-Nginx tutorials, we have been asked many times that why we haven’t posted anything about Varnish!

Here is my attempt to answer…

Short Answer: Using Varnish + Nginx is not worth my effort!

Long Answer…

Time-saving:

I never used Varnish. So I will have to spend some time learning Varnish. Apart from this, Varnish will increase one more package on Nginx + PHP + MySQL + APC/Memcache stack we commonly use. That means if something goes wrong, we will need to debug Varnish also apart from other packages!

So not only in learning but I will have to spend time in maintenance on ongoing basis.

Static-content:

Nginx can handle static files itself pretty fast. On larges sites, people generally use CDN to host static files (images, videos, js, css, etc).

Varnish is surely useful when used with Apache. If Apache has mod_php enabled, Apache performance significantly drops for static-file requests.

Load-Balancer, Reverse-Proxy:

Again, Nginx does this for me! In a client-setup, we have a micro Amazon EC2 instance running nginx as load-balancer in front of range of PHP, mysql.

Beauty of Nginx is that it can directly talk to other Nginx and PHP directly. It can read from memcache directly! So it works really well for us in multi-machine environment.

In second part of our WordPress-Nginx Tutorial Series, I will write in depth about load-balancing, reverse-proxy etc. (You can subscribe here for updates.)

Benchmarks…

I am not fond of benchmarks. Still, if Varnish + Nginx gives 5-10% performance improvement but cost in days to learn and hours every month in ongoing maintenance, I will prefer to leave that 5-10% of performance gain.

That being said I find this Varnish/Nginx benchmark quite good!

Finally…

My point is… rather than learning multiple tools partially, I will dig deeper into Nginx. I will master it to the point that it can cater to all our needs! 🙂

That’s it from my side! You can prove me wrong using comment-form below! 😉


49 comments

  1. Beauty of Nginx is that it can directly talk to other Nginx and PHP
    directly. It can read from memcache directly! So it works really well
    for us in multi-machine environment.

    It sounds like you have done exactly what I am planning to do!
    I also think varnish is overkill and want to use nginx for everything. What plugins are you using? Seems to me that the nginx cache plugins and memcache plugin do not work together. The memcache plugin assumes that something else fills memcache right?
    I know nginx pretty well so if you can just sketch the solution here before you post the follow up article I would really appreciate it.

    1. We use APC Cache for database & object cache via W3 Total Cache plugin. For conditional purging of page-cache we are using Nginx Helper. Apart from that we use Nginx’s fastcgi-cache only to generate page-cache.

      For memcache, which I will recommend only in environment where a site is hosted across multiple machines, I think you can use Nginx’s built-in memcache module with a WordPress plugin which will “fill-up” cache. There are many WordPress plugins which can store cached pages in memcache but I haven’t tested them yet.

      Since I am tmpfs for fastcgi_cache storage location, it as fast as memory-based caching. (tmpfs is created in RAM)

  2. The irony of your post is that you likely spent more time writing it then it would take to get a basic Varnish setup and actually test it …

    1. @Joshua

      Its not one time cost. It may take like 30-mins to figure out how to get Varnish working! But what about ongoing debugging and maintenance?

      We have so many use-cases here for Nginx’s fastcgi_cache that Varnish docs will fail to cover.

      On a site with geo-targeting enabled, for every wordpress post/page, we store 8-different version of pages in fastcgi_cache and then serve correct version based on user-ip/preference so that backend PHP/mysql can rest in piece. Then see this use-case.

      We also use Nginx as a load-balancer. Nginx can talk to PHP on different machine itself when cache is missed! It simplifies deployment and ongoing management because we can move with one app i.e. Nginx alone.

      We have more than 100-sites/apps on Nginx (for us and our customers) and most of them have complex nginx config.

      Only feature, I like of Varnish is ESI – https://www.varnish-cache.org/trac/wiki/ESIfeatures but I am exploring few things in Nginx to take care of this. Also, once a page is completely cached, ESI won’t come into picture unless we need to regenerate page i.e. cache-flush. In that case also, parts like sidebar are present in RAM (in APC, via Object-Cache from W3 Total Cache plugin).

      Unless Varnish is 5-times faster (or can handle same traffic in 5 times less hardware), we are better with Nginx. In fact going by trend, one can move from Varnish to http://gwan.com/benchmark!

      The point is – either you can test every new thing every day or master something for a while and get the best out of it!

      1. Maybe I should rephrase then. I felt like this post should have been titled ‘The great things we like about Nginx’ rather than its current title. I came here from Google looking for interesting performance reasons against Varnish but found workflow reasons against it. As a tutorial, discouraging readers from trying new things because ‘they are hard and time consuming’ is a bit antithetical to learning.

        I completely support your decision to use Nginx in your workflow and not Varnish. It makes plenty of sense to choose a tool that works really really well.

        I personally have found Varnish to be a good tool to use in combination with Nginx. You have a point, it took some time to learn. But my site loads pretty fast and I’m really happy with it.

        Thanks for the reply. Also, G-WAN seems bogus: http://martijn.vanderlee.com/?p=396

        1. @Joshua

          This article was intended for my readers who were asking when I will cover Varnish in our WordPress-Nginx series – https://rtcamp.com/series/wordpress-nginx-tutorials/

          You can see my disclaimers and reason behind posting at the start.

          I am blogging from 2006 and I have maintained a line that I will never post negative reviews. If I cannot encourage somebody, I must not discourage them either.

          In fact, that is the reason why I added clear disclaimer in the beginning as I was bit uncomfortable while writing this but this made my life easier.

          When readers or clients ask for Varnish and when I say NO, link to this article save me form writing long answer to their next question – WHY?

          For records, I referenced benchmark here – http://todsul.com/nginx-varnish , which I found convincing as per my intuition.

          Based on my experience, benchmarks in general can be “tailored”. For example, most articles I see on Internet talk about performance of static-file handling between Nginx and Varnish.

          I am not sure about Varnish but in Nginx, if you run a benchmark again by turning off access_log for static files, you will get a decent speed-up. It could be around 2x. Because when access_log are on, for every FILE READ, Nginx is performing FILE WRITE by writing to access logs. Of-course DISK WRITES can be buffered (and buffering will again give us different results!)

          We deal with WordPress sites everyday where most plugins are developed by amateurs. When we run them on big sites MySQL slowlog is full of unoptimized queries. By optimising mysql queries, adding MySQL query-cache & object-cache, minifying/combining CSS/JS (almost every plugin adds 1 CSS and 1 JS file to output HTML), adding CDN we get the maximum performance benefit.

          My goal these days is to reduce cache-miss penalty. Serving static files or cached webpages isn’t much of a concern as I am not dealing with a site with million hits per day.

          Anyway, thanks for that link about G-WAN. I am not sure about truth behind G-WAN’s performance but you can see debate about “benchmarks” in comments there.

          Personally, I am driven by intuition and not by benchmarks. In fact, I haven’t done much benchmarking even though I spent considerable time in last 4-years on Nginx.

          To me I must be comfortable with technologies I use. Today, I am very much comfortable with Nginx.

          That being said, I won’t deny the fact that some day I may leave Nginx for something better in future. I just “feel” Varnish is not better “enough” for my work, atleast today.

      2. I have a troubleshoot.vcl which just points to the back end with no varnish config. Varnish becomes passthrough. At that stage you now just have a tool, varnishstat.

        When I’m trying to troubleshoot web server problems I simply mv default.vcl /home/root/backups/ and mv troubleshoot.vcl /etc/varnish/default.vcl and issue a service varnish restart.

        One thing about varnish is it uses nearnly 0 cpu and keeps those static files and images in RAM. I may be wrong, but I have not found a way to do that with NGINX. I have have a custom error message, so when my back end goes down for maintenance varnish will display a maintenance message and auto refresh every 3 seconds.

         // Display custom error with refresh if the backend is down 
        sub vcl_error { set obj.http.Content-Type = "text/html; charset=utf-8"; synthetic {"
            <?xml version="1.0" encoding="utf-8"?>
            <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
                "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
            <html>
                <head>
                    <title>We'll Be Right Back!</title>
                    <meta http-equiv="refresh" content="3">
                </head>
                <body bgcolor=#FFFFFF text=#222222>
                    <center>
                    <table border=0 cellpadding=3 cellspacing=3 width=790>
                    <tr><td>
                    <div style="font-size:150%; font-family:Arial;">
                    <h1>Hold On! We'll Be Right Back!</h1>
                    <p>We are taking care of some important back end maintenance right now. Check back in a minute. This page will auto refresh every 3 seconds.</p>
                    </div>
                    </td></tr>
                    </table>
                    </center>
        
                </body>
            </html>
        "};
        return(deliver);
        
        1. Nginx also keeps CPU load 0. Nginx can passthrough to backend. Nginx can also previously cached copy of page if backend is not reachable (“stale” version).

          Nginx can also show a page like above! 3-second refresh is done using HTML in above case!

          So again I did not get any reason to invest time in learning Varnish.

  3. I have actually installed Vanish in front of Nginx in a production site running Drupal with “boost” module.

    After some time of using it, I realized it added no benefit. I made some tests about it, you can read them here:

    http://www.garron.me/en/go2linux/nginx-varnish-vs-nginx-alone-compared.html

    and here: http://www.garron.me/en/linux/apache-vs-nginx-php-fpm-varnish-apc-wordpress-performance.html

    But another thing I have learned is that you can configure Apache with fastcgi, and it will work almost as good as Nginx. More here:

    http://www.garron.me/en/blog/wordpress-apache-ubuntu-mpm-worker-php-fpm.html

    Sorry for so many links, I am not trying to spam here, I really think they are relevant to the topic of this posts.

    1. I am not sure how you ran benchmarks or how your application is configured.

      Nginx is always better than Apache. Also, PHP5-FPM is better than fastcgi.

      Are you using Drupal or WordPress? If you are not getting better performance with Nginx + PHP5-FPM, as compared to Apache + fastcgi, then that simply means there is some misconfiguration.

      1. Nginx is always faster than Apache.

        But if you really need Apache, or really want Apache (.htacces for example). And I know you can replace .htacces with Nginx rules, but htacces is so convenient sometimes.

        Well in that case, using Apache + PHP-FPM instead of Apache+mod_PHP is almost as good as Nginx. Specially for the non PHP content.

        For the PHP content, you can improve with cache techniques.

        Nginx micro-cache as reverse proxy
        Varnish
        WP-Super cache for WP
        Boost for Drupal

        But once again Nginx is always faster than Apache.

        1. Why are you using the Boost module if you’re using Varnish? There’s really no appreciable benefit from Boost in such an environment, especially since it’s adding an unnecessary layer of work, both for the server(s) and for maintenance.

          1. I am not. What you see above is a list of the caching options I may use. Not all together.

  4. In my limited experience with Nginx, I fail to understand what extra benefits you get from putting Varnish in front of it, except for additional obfuscation — on a set of cloud instances, you could, for instance, run several Nginxes on separate instances in a cloud-based, private network, and just have Varnish being publicly accessible. So hackers would only be able to attack Varnish — which is not a webserver and, as such, cannot be easily tricked to run commands… — but not go beyond that. So even a misconfigured Nginx would not present such a big security risk.

    Other than that, it would like expecting having a benefit of having Squid in front of Varnish, or Varnish in front of Squid — both do the same (but Squid is bloated and tough to configure). There would be no benefit in that. Running Nginx in front of Apache is another story, since Nginx could, in that case, do everything that Apache is not good at: delivering static files superquickly, handle a distributed cache, and so forth — while leaving Apache to handle PHP, which it does marginally better than PHP-FPM (on servers with plenty of memory!). That would make sense.

    But putting a fast static serving application in front of another fast static server application…? I also fail to understand the benefit in terms of raw performance. Both would be doing basically the same thing. Except for security concerns, I don’t understand the point of using Varnish with Nginx.

    Nothing against Varnish, btw! It’s the salvation for current Apache/IIS users who have no option but to stick with Apache/IIS. At least they can benefit from Varnish’s superfast distributed caching mechanism…

    1. @Gwyneth

      Agree with all points except:

      leaving Apache to handle PHP, which it does marginally better than PHP-FPM (on servers with plenty of memory!)

      I guess you are comparing mod_php (Apache specific) with PHP-FPM. For a PHP request, I am not sure weather “Apache + mod_php” will be faster than “Apache + PHP-FPM” but for non-PHP requests “Apache + mod_php” will be very slow as compared to using Apache with fastcgi or PHP-FPM.

      PHP-FPM offeres too many advantages to ignore, and since it can be used directly with Nginx, I do not see any reason to bring Apache into picture.

      Please correct me if I missed a use-case (except some legacy codes which makes use of Apache’s feature heavily and cannot leave without Apache!)

      1. You’re right, I was a bit unclear on that. However, according to the benchmarks I’ve seen, Apache + mod_php performs far better than Apache with PHP-FPM. Personally, I’ve not tested that configuration — just with Apache + PHP Fast CGI, which is slightly different (and has less performance than PHP-FPM), and I cannot confirm your claims — there is a significant loss of performance, on a server with little memory, when pushing PHP out of Apache into something external.

        However, on a server with plenty of memory, the reverse might happen. I haven’t tested that, and as far as I remember, I have not seen a benchmark for that case.

        But I still claim that this “better performance” is possibly just on pure PHP applications. As soon as a “real mix” is used (e.g. a website with non-PHP components — images, JS, CSS, possibly pure HTML), Nginx will easily beat Apache, even if Apache by itself is just dealing with static content and not funneling it through anything that deals with PHP — because, well, Nginx is truly very optimised for serving static content, to a level that goes far beyond Apache’s capabilities.

        Again, the only use-case for keeping Apache around are pure PHP-only applications, of which there are a few.

        1. You are right Nginx is performs better than Apache when mixing PHP and static.

          But I don’t agree that Apache is only good when you have pure PHP app.

          You can easily support more than a million hits per day with Apache, may be less than nginx, but 99 percent of sites will be great with Apache if well configured. So to me is a matter of taste.

  5. I am not a very technical person and I have been learning to configure a VPS server for some of my websites. It is true that varnish has a bit more learning curve than nginx and most probably I should give up trying varnish cache on my websites as I tried a few times and my test sites were started giving me error 503.

    Right now, I am pretty happy with nginx.

  6. Personnally i think you are missing a huge benefit of using varnish at the front. If yiur nginx or database servers go down, varnish will keep serving cached pages. You can then work on the backends to get them up and running again.

    I have not spent time tweaking nginx because once the pages are cached by varnish, your varnish server will quickly serve pages that arecached. (although I have not tested using nginx only as a cache server and I probaby have not tweaked nginx to perfection). But Varnish is so easy to master and setup, so i chose it as the front end. I didn’t have to master nginx settings, because once varnish is up and running, everything is cached. I have seen the performacnce gains using varnish at the front and niginx in the back. Also I have experienced varnish still serving pages when i had issues with the backend. You are right though, it would be nice to only deal with one product. maybe I should investigate how hard it is to use nginx as a cache server instead of varnish and see if there is a difference in performance.

    1. You have underestimated Nginx big time!

      I can work on backends – PHP/MySQL while Nginx keep serving cached pages very easily.

      In fact our checklist for perfect Nginx setup has a step where we forcibly shutdown PHP/MySQL backend and test if Nginx can serve cached content correctly – https://rtcamp.com/wordpress-nginx/tutorials/checklist/

      If you have seen any performance gain putting Varnish in front of Nginx, that most likely means you haven't used Nginx caching.

      Benefit of mastering Nginx is – in one go you will learn about caching, load-balancing, CDN and many more things. Nginx does a lot many things compared to Varnish and its list of modules is growing rapidly.

      1. The link you provided shows WordPress cache, not Nginx Cache.

        Test if WP Super Cache or W3 Total Cache is working:
        Is a test of Wodpress Cache, sure Nginx can cache and it is very efficient on that, but your link just does not show that.

        1. @Guillermo

          Thanks for pointing out. That checklist was written before I posted Nginx’s fastcgi cache config.

          Same checklist will work with Nginx’s fastcgi cache as well as future caching solutions I will be covering soon.

          Goal is to check if Nginx can serve a cached page itself if backend interrupts.

          Anyway, updated that checklist article. 🙂

  7. I think some of the commenters here missed the point of the post.

    This post is not about why you should not use Varnish, or varnish vs nginx. Both Varnish and Nginx have their place. Let me show you some examples.

    You are configuring a server to host hundreds of WordPress sites. Then you better go with Nginx, you can tweak it to server the most efficient way WordPress sites. If you do a good job configuring the server, you do not even need WP Supercache and the like. Let WordPress be dynamic as it was created. And let Nginx do the caching.
    You have to configure a server to serve a lot of different platforms, WordPress, Joomla, Selfoss, Piwik, DokuWiki and some more. In this case where all these software have been made to work with Apache out of the box, you may be better installing them on an Apache server. You can then install Varnish in front of them (Better in another VPS) to give those sites better performance.
    You do not want to go through all the hassle of tweaking Apache or Nginx on your own, but you still want to have some services running on the internet, WordPress, Selfoss, Owncloud and some more. You can get a cheap shared host account, use CPanel to install of those tools. Get a cheap VPS (Digital Ocean comes to mind) setup Varnish there (just varnish) and Forward your WordPress traffic through it. You will have great performance, but it is on someone else the hassle to keep your site up.

    Finally. The author here is just showing why he does not use Varnish, well he is in case 1, he simply do not need it. Nginx do all he needs, not need to deal with Apache or Varnish. He just have to learn one thing, and he only works with WordPress. Once he masters how to tweak Nginx for WordPress that is all he needs.

    My two cents 🙂

    1. You’re quite right on that point. In fact, a company I occasionally work for is selling precisely what you’re suggesting as a business product (sorry, they started doing it a few months ago, or I’d force them to give credit to your idea), namely, for “lazy” or “security-unconscious” admins, they just set up Varnish as a cache/reverse proxy server, redirect all site’s traffic through it, and contact the poorly-administered server from the customer behind it. The solution works wonderfully well and is giving some of the worst websites ever a huge boost in PageRank, Yahoo, and so forth.

      So, yes, that idea is sound. Varnish does wonders for performance (and security!), if you’re too lazy to do it on your own server, and/or you have no patience/no money to move out of a shared service.

      Personally, I prefer to rely on CloudFlare for that, but sometimes one needs to have full control over one’s servers.

      1. Hm. Do you have any idea if Zend Opcache is supported at all by the W3 Total Cache plugin for WordPress? I’m using PHP 5.5 on one of the servers, and W3TC can only find APC installed but not Zend Opcache…

        1. Zend Opcache is not supposed to be supported by W3 Total Cache. Opcache is different that data-cache or user-cache.

          APC is both opcache as well as user-cache. Thus W3 Total Cache has option to use APC (data-cache part).

          Opcache works at PHP interpreter level. It doesn’t have get/set style API for general purpose key/value pair caching.

          We are using Memcache with W3TC – https://rtcamp.com/tutorials/php/memcache/

  8. Informative really, Thanks
    I have a question, if you have an Apache server that services PHP and a lot of images, what is the best to use for caching and boost performance, Nginx or Varnish? The server has also Plesk.

    1. In your case, it won’t make much difference. Both nginx/varnish can act as cache in-front of Apache backend.

      As far as I know, plesk can work with Nginx. So try replacing Apache with Nginx if possible.

      If you use plesk to manage php/wordpress sites only and comfortable with command-line, try https://rtcamp.com/easyengine

      You can get best by removing Apache, Plesk and using nginx directly with PHP.

      1. Thanks Rahul,
        As I know, if we need caching only we should use Varnish rather than Nginx as it’s designed from its start to be a caching proxy.
        And yes Plesk now supports Nginx besides Apache.
        So I think to use Nginx besides Apache on this server to serve static contents like images and so on, this will boost performance and save hardware resources.
        What cache size do you recommend for better performance when we have enough RAMs?
        Regards

        1. As I know, if we need caching only we should use Varnish rather than Nginx as it’s designed from its start to be a caching proxy.

          IMHO, it doesn’t work that way. Apache was designed to be web-server but its no better than many web-servers created later on. Anyway, as it looks like nginx and varnish are both new for you, go with whatever seems easy to use. I believe difference between varnish and nginx will be negligible in your case as compared to replacing apache with nginx altogether.

          About cache-size, not sure about varnish but nginx doesn’t provide a separate cache for static file content. Nginx provides open_file_cache – https://rtcamp.com/tutorials/nginx/open-file-cache/ for which you won’t need much RAM.

          Your OS should do caching static content as long as there is some free RAM.

          If you have a lot of static contents. like posts with plenty of images, better go with CDN – https://rtcamp.com/tutorials/cdn/

    1. Its more about “Why I never used Varnish”.

      Its better to write a post for once and all, rather than replying to individual emails in details. Now if anybody ask us if we can configure Varnish for them, we just send them link to this post!

  9. I returned to leave a comment. Three days of torture from varnish and in the end I gave up. Varnish eating resources. WP super cache is a more elegant solution for small sites.

    1. It’s hard to imagine Varnish eating resources. Though I never used it, it seems light-weight also.

      Anyway, if WP-Super-Cache is working fine for you, enjoy that. My whole point is to use things which works for you rather than giving too much thoughts to “trends”!

  10. he link you provided shows WordPress cache, not Nginx Cache.

    Test if WP Super Cache or W3 Total Cache is working:
    Is a test of Wodpress Cache, sure Nginx can cache and it is very efficient on that, but your link just does not show that.

    1. I am not sure which link your which link you are talking about but I covered test cases here – https://rtcamp.com/wordpress-nginx/tutorials/checklist/

      There you can test WP Super Cache, W3 Total Cache, Nginx Fastcgi Cache or any page-cache with timestamps in HTML.

      I also have another technique to test Nginx Fastcgi Cache (only) https://rtcamp.com/tutorials/nginx/upstream-cache-status-in-response-header/ . We use Nginx fastcgi cache everywhere so this is my favorite.

  11. Howdy,

    (Disclaimer: I work for LiteSpeed Technologies…)

    Have you ever thought of LiteSpeed Web Server? I know you don’t want to learn new tools, but that’s the point of LiteSpeed — it runs directly off Apache configs. You don’t need to spend time learning new tools. (I totally get that the time required to learn a new tool is an important consideration.)

    Couldn’t access the benchmarks you said were good, but we just put out some new benchmarks ourselves: http://blog.litespeedtech.com/2013/11/12/new-benchmarks-litespeed-vs-apache-vs-nginx-for-static-content/

    In our test, both Enterprise LiteSpeed and our open source OpenLiteSpeed beat nginx (and Apache, of course) in static file service. Would love to know what you think, though.

    1. Thanks for taking time to drop by here Michael.

      Though I am unlikely to use or recommend LiteSpeed in near future, I appreciate its development as light weight alternative for webmasters who want to stick with Apache knowledge.

      In my case, it might sound offbeat but I never learned Apache server deeply.

      Back in 2009, when I started exploring web servers, I remember meeting LiteSpeed, Nginx and few other alternatives then.

      I choose Nginx because of its event-driven architecture and I am happy with my choice.

      About benchmarks, for any famous pair “A” and “B”, you will find atleast one article proving “A” is winner and one saying “B” is winner.

      Nginx worked for me when Apache failed. I will look for alternatives only when Nginx disappoints me!

      1. Well, that is a little offbeat, but I certainly can’t argue that you should learn something new.

        We’ve based the company and technology off giving people better performance without having to learn nginx. If you know nginx and not Apache, there’s no reason I can see that you should have to learn Apache (unless there’s something you need to do that nginx doesn’t handle yet).

        Cheers,

        Michael

        1. Agree. 🙂

          Most of the times, there are more than one way to solve a problem at hand.

          I believe, once you solve a problem in any one way, you no need to learn other ways to solve same problem unless you are expecting miraculously different results/improvements.

          It’s better to invest that time and energy solving different problems.

          Nginx is already working as a nice reverse-proxy, load-balancer and web-server for php-apps for us.

          Rather than exploring another reverse-proxy or load-balancer, I will spend my next free time slot on learning Lua (reason/motivation)

          I never ask people to stop using whatever is already “working” for them.

  12. Great points about Nginx and it’s incredible performance. I’m all for Nginx! But has anyone had any experience with running Nginx + FastCGI cache + GlusterFS stack? I haven’t seen any posts on this type of setup which might benefit from a little Varnish. I’m currently configuring a couple of Amazon EC2s with an autoscaling policy in place that upscales to 6 servers as needed. All store their cache pages in a shared GlusterFS mount to allow for consistent purging of the cache, but have ended up with many PHP connection timeouts and 502s under high load probably due to the shared mount point capping out. I’m now looking into running Varnish on a dedicated server as a possible solution to this problem and will post my results.

    1. We ran some tests with GlusterFS in LAN and it worked nicely.

      Next, we want to test GlusterFS in WAN, using 1 VPS in New York and 1 VPS in Amsterdam. We are using DigitalOcean for all our initial testing.

      I am concerned about latency in WAN.

      If GlusterFS works well, we plan to keep entire webroot and mysql data on GlusterFS. Goal is to use low-level sync so that we can skip dealing with mysql-replication and static file-sync. We are also exploring DRBD (http://www.drbd.org/)

      In your case, why don’t you try Nginx with Memcache. You may try – http://wordpress.org/plugins/wp-ffpc/

      I think Amazon AWS also offers memcache as a service under http://aws.amazon.com/elasticache/

  13. Your basic point is that nginx on its own gives you good enough performance, that’s fine, but this point…
    “I will master it to the point that it can cater to all our needs!”

    To me, it makes sense to use tools that are best suited to the task at hand. You might not have a use for Varnish right now, but to deny that there might be times where it’ll suit you better than nginx seems a little silly. In my opinion. The same goes for all technology decisions.

    1. I think I should have been more clear. I said that in context of varnish features like load-balacing and caching.

      I want to spend more time in fulfilling my requirements with nginx first. Of course, the day I find nginx is not working nicely for something, I will look for alternatives.

      Fortunately, I am yet to come across a use-case where I needed varnish. May be its side-effect of dealing with wordpress-sites only but I am loving nginx as load-balancer now. I am enjoying it’s proxy-cache feature. I am experimenting with nginx+memcache as for many client sites, we are dealing with multiple servers now.

      IMHO running behind trend is silly! It’s better to make optimum use of tools at hand, before looking for alternatives.

      1. It’s better to make optimum use of tools at hand, before looking for alternatives.

        But where is the line drawn to keep from over-optimizing one tool while neglecting the application of another tool?

        1. How to draw such lines? In my case, the day I will feel that after spending days on a particular tool to solve a problem, I am not reaching desired solution, I will start looking for alternatives.

          But I will definitely give tools at hand a try before trying new tools!

Comments are closed.