Configuração Varnish 4.1 para multi backends com Wordpress

bavaresco1
(usa CentOS)

Enviado em 29/06/2016 - 16:58h

Recentemente fiz a compra de um Cloud, mandei 3 sites para lá e os três estão rodando normalmente. Fiz a instalação do Varnish esta semana, está rodando na porta 80 de acordo com os tutoriais originais e já notei uma melhora no desempenho do servidor (melhorou bastante o Load). Obs: estou usando um servidor CentOS7 com PHP 5.5 e MySQL 5.5.

Tentei fazer esta configuração (https://gist.github.com/JREAM/e16d5402fa536b14b43c) porém não consegui compreender como funcionaria em multi dominios, se teria que setar dentro de cada backend no sub vcl_recv ou fora dele. Preciso fazer a configuração do varnish para funcionar em todos os três sites Wordpress. Segue dados do varnish:

Infos do Varnish:
- Versão do varnish: 4.1.2
- VCL 4.0

Infos do Servidor:
- 4GB de RAM
- 40GB SSD
- 2 Núcleos de 2Ghz
- 3TB de transf. mensal
- Apache + MySQL 5.5 + PHP 5.5 + WHM + cPanel

No momento tenho o seguinte arquivo default.vcl:

#

# This is an example VCL file for Varnish.

#

# It does not do anything by default, delegating control to the

# builtin VCL. The builtin VCL is called when there is no explicit

# return statement.

#

# See the VCL chapters in the Users Guide at https://www.varnish-cache.org/docs/

# and https://www.varnish-cache.org/trac/wiki/VCLExamples for more examples.



# Marker to tell the VCL compiler that this VCL has been adapted to the

# new 4.0 format.



vcl 4.0;



# Default backend definition. Set this to point to your content server.

# Estou usando o IP NAT e não o localhost, so para exemplificar



backend default {

    .host = "127.0.0.1";

    .port = "8080";

}



backend site1{

    .host = "127.0.0.1";

    .port = "8080";

}



backend site2{

    .host = "127.0.0.1";

    .port = "8080";

}



backend site3{

    .host = "127.0.0.1";

    .port = "8080";

}



sub vcl_recv {



    if (req.http.host == "www.site1.com.br" || req.http.host == "site1.com.br") {

        set req.backend_hint = site1;

    }



    if (req.http.host == "www.site2.net" || req.http.host == "site2.net") {

        set req.backend_hint = site2;

    }



    if (req.http.host == "www.site3.com.br" || req.http.host == "site3.com.br") {

        set req.backend_hint = site3;

    }

    

    else {

        set req.backend_hint = default;

    }

}



sub vcl_backend_response {

  # Called after the response headers has been successfully retrieved from the backend.



  # Pause ESI request and remove Surrogate-Control header

  if (beresp.http.Surrogate-Control ~ "ESI/1.0") {

    unset beresp.http.Surrogate-Control;

    set beresp.do_esi = true;

  }



  # Enable cache for all static files

  # The same argument as the static caches from above: monitor your cache size, if you get data nuked out of it, consider giving up the static file cache.

  # Before you blindly enable this, have a read here: https://ma.ttias.be/stop-caching-static-files/

  if (bereq.url ~ "^[^?]*\.(7z|avi|bmp|bz2|css|csv|doc|docx|eot|flac|flv|gif|gz|ico|jpeg|jpg|js|less|mka|mkv|mov|mp3|mp4|mpeg|mpg|odt|otf|ogg|ogm|opus|pdf|png|ppt|pptx|rar|rtf|svg|svgz|swf|tar|tbz|tgz|ttf|txt|txz|wav|webm|webp|woff|woff2|xls|xlsx|xml|xz|zip)(\?.*)?$") {

    unset beresp.http.set-cookie;

  }



  # Large static files are delivered directly to the end-user without

  # waiting for Varnish to fully read the file first.

  # Varnish 4 fully supports Streaming, so use streaming here to avoid locking.

  if (bereq.url ~ "^[^?]*\.(7z|avi|bz2|flac|flv|gz|mka|mkv|mov|mp3|mp4|mpeg|mpg|ogg|ogm|opus|rar|tar|tgz|tbz|txz|wav|webm|xz|zip)(\?.*)?$") {

    unset beresp.http.set-cookie;

    set beresp.do_stream = true;  # Check memory usage it'll grow in fetch_chunksize blocks (128k by default) if the backend doesn't send a Content-Length header, so only enable it for big objects

    set beresp.do_gzip   = false;   # Don't try to compress it for storage

  }



  # Sometimes, a 301 or 302 redirect formed via Apache's mod_rewrite can mess with the HTTP port that is being passed along.

  # This often happens with simple rewrite rules in a scenario where Varnish runs on :80 and Apache on :8080 on the same box.

  # A redirect can then often redirect the end-user to a URL on :8080, where it should be :80.

  # This may need finetuning on your setup.

  #

  # To prevent accidental replace, we only filter the 301/302 redirects for now.

  if (beresp.status == 301 || beresp.status == 302) {

    set beresp.http.Location = regsub(beresp.http.Location, ":[0-9]+", "");

  }



  # Set 2min cache if unset for static files

  if (beresp.ttl <= 0s || beresp.http.Set-Cookie || beresp.http.Vary == "*") {

    set beresp.ttl = 120s; # Important, you shouldn't rely on this, SET YOUR HEADERS in the backend

    set beresp.uncacheable = true;

    return (deliver);

  }



  # Don't cache 50x responses

  if (beresp.status == 500 || beresp.status == 502 || beresp.status == 503 || beresp.status == 504) {

    return (abandon);

  }



  # Allow stale content, in case the backend goes down.

  # make Varnish keep all objects for 6 hours beyond their TTL

  set beresp.grace = 6h;



  return (deliver);

}





sub vcl_deliver {

  # Called before a cached object is delivered to the client.



  if (obj.hits > 0) { # Add debug header to see if it's a HIT/MISS and the number of hits, disable when not needed

    set resp.http.X-Cache = "HIT";

  } else {

    set resp.http.X-Cache = "MISS";

  }



  # Please note that obj.hits behaviour changed in 4.0, now it counts per objecthead, not per object

  # and obj.hits may not be reset in some cases where bans are in use. See bug 1492 for details.

  # So take hits with a grain of salt

  set resp.http.X-Cache-Hits = obj.hits;



  # Remove some headers: PHP version

  unset resp.http.X-Powered-By;



  # Remove some headers: Apache version & OS

  unset resp.http.Server;

  unset resp.http.X-Drupal-Cache;

  unset resp.http.X-Varnish;

  unset resp.http.Via;

  unset resp.http.Link;

  unset resp.http.X-Generator;



  return (deliver);

}



sub vcl_purge {

  # Only handle actual PURGE HTTP methods, everything else is discarded

  if (req.method != "PURGE") {

    # restart request

    set req.http.X-Purge = "Yes";

    return(restart);

  }

}



sub vcl_synth {

  if (resp.status == 720) {

    # We use this special error status 720 to force redirects with 301 (permanent) redirects

    # To use this, call the following from anywhere in vcl_recv: return (synth(720, "http://host/new.html"));

    set resp.http.Location = resp.reason;

    set resp.status = 301;

    return (deliver);

  } elseif (resp.status == 721) {

    # And we use error status 721 to force redirects with a 302 (temporary) redirect

    # To use this, call the following from anywhere in vcl_recv: return (synth(720, "http://host/new.html"));

    set resp.http.Location = resp.reason;

    set resp.status = 302;

    return (deliver);

  }



  return (deliver);

}





sub vcl_fini {

  # Called when VCL is discarded only after all requests have exited the VCL.

  # Typically used to clean up VMODs.



  return (ok);

}

 

O código está bem estranho, pois a maioria as VCL's que vejo não são aplicadas a multi backends, apenas a um site dentro do servidor.

Caso alguém tenha uma sacada boa aí, ajudaria muito!

Valeu e boa tarde!!!