The SitePoint PHP blog has posted the latest tutorial in their series creating a simple image gallery application with a focus on performance. In this latest article they cover the use of Varnish for output and page caching.

According to Pingdom.com, a company focused on web performance, in 2012 Varnish was already famous among the world’s top websites for its capacity to speed up web delivery.

[...] Although there are other solutions that also shine, Varnish is still a go-to solution that can dramatically improve website speed, reduce the strain on the web application server’s CPU, and even serve as a protection layer from DDoS attacks. KeyCDN recommends deploying it on the origin server stack.

Varnish can sit on a dedicated machine in case of more demanding websites, and make sure that the origin servers aren’t affected by the flood of requests.

The article starts by explaining a bit about how Varnish (and caching in general) works to help improve the performance for the end user. It also goes through some of the basics feature of Varnish including threaded executions, extensibility and its domain-specific language. The tutorial then walks you through the installation of Varnish on a linux-based machine and shares some example stats showing the difference between normal requests and when Varnish is enabled for the image gallery application.

If you've ever been interested in using Varnish as a caching layer for your application but weren't sure where to start, you're in luck. In a post to his site Thijs Feryn has announced the release of his book covering Varnish and helping you get started integrating it into your infrastructure.

I’m proud to announce that my Varnish book is out now. It’s called “Getting Started With Varnish Cache” and it’s available for download through Varnish Software. For the next 30 days, Varnish Software has the exclusive rights to distribute the book. After that, O’Reilly will also be distributing physical copies and the digital version of the book, while Varnish Software will continue to distribute the book on their website.

Varnish Software is currently offering the book for free (well, "free" after you give your personal info). Thijs gets into a bit of detail around the book, the process he followed creating it and what kinds of things Varnish can help with. He points out that it was "one hell of a ride" writing the book and getting it published but notes that it was a "fun experience" and probably won't be the last book he writes.

Freek Van der Herten has a post to his site showing you how to set up Varnish with a Laravel Forge server. Forge is a service that makes it simpler to set up and manage servers and the applications installed without having to mess with the details yourself.

For a project we’re working on at Spatie we’re expecting high traffic. That’s why we spent some time researching how to improve the request speed of a Laravel application and the amount of requests a single server can handle. There are many strategies and services you can use to speed up a site. In our specific project one of the things we settled on is Varnish. In this post I’d like to share how to set up Varnish on a Forge provisioned server.

He gives a high level overview of what Varnish is and what benefit it provides to your application (complete with illustrations) and includes a link to a presentation introducing Varnish to PHP developers. Then he moves on to installing Varnish on the server, updating the VCL configuration file and opening a port for you to use when connecting to the Varnish service. He shows the difference in the response headers when Varnish handles the response and the updates you'll need to make to get your Laravel application to play nicely with Varnish with this package.

He ends the post with examples of how to test the performance difference and some final steps to update the config and have it run on port 80 instead of the default 6081.

In a recent post to his site Jeff Geerling shows you how to disable the output buffering that PHP includes and create "streaming PHP" code similar to Drupal's recently introduced BigPipe handling.

For the past few days, I've been diving deep into testing Drupal 8's experimental new BigPipe feature, which allows Drupal page requests for authenticated users to be streamed and loaded in stages—cached elements (usually the majority of a page) are loaded almost immediately, meaning the end user can interact with the main elements on the page very quickly, then other uncacheable elements are loaded in as Drupal is able to render them.

[...] BigPipe takes advantage of streaming PHP responses (using flush() to flush the output buffer at various times during a page load), but to ensure the stream is delivered all the way from PHP through to the client, you need to make sure your entire webserver and proxying stack streams the request directly, with no buffering.

He decided to try out different configurations to see if he could reproduce the same thing outside of Drupal and - good news, everyone - he found a reliable way. He starts with a basic procedural script that emulates BigPipe and calls a flush inside a loop to push the latest output to the waiting client. While this cooperates on the command line the browser doesn't cooperate the same way. A small tweak helps it work, so he shows how to reproduce this reliably across the full stack - Nginx, Apache and Varnish.

He ends with a quick warning for those using VMWare/VirtualBox about some oddness he experienced in buffering the responses and includes a way to test if it's your script or the VM causing the trouble.

On the eZ blog there's a new post, the first part of a series, showing how to optimize the performance of your LAMP stack with the help of some tuning on the server and software levels.

Nowadays, a website is not only a simple HTML page. Your visitors expect dynamic, personalized information fast and you need a scalable way to deliver content as quickly as possible. This, of course, puts significant pressure on page loads and response time. In this series of posts, we’ll explore eZ’s system architecture and provide recommendations on how you can optimize caching and decrease response time with eZ software.

They then talk about the various pieces of software that make up a typical environment and some tips on optimizing them:

• Varnish
• Apache
• MySQL and MariaDB

Each includes the configuration changes and setup that's helped eZ get the most out of their stack and links to other tools to help you evaluate the performance differences.

The Symfony Finland blog site has worked up some benchmarks comparing the Symfony Proxy versus Varnish and shared the results in this new post. The Symfony Proxy is a tool built in to the framework to help with caching responses automatically. Varnish, however, is a separate tool optimized to handle the caching of the same content but outside of the application completely.

In the previous articles we have evaluated PHP performance on different runtimes (PHP 5.6, HHVM, PHP 7) as well as how it behaves when adding server resources (CPU & RAM) using eZ Platform - a CMS built on the Symfony Framework.

In production environments Symfony and eZ Platform are likely ran behind the Varnish Reverse Proxy, which we'll evaluate next by comparing it to the built in Symfony Proxy.

They once again use the eZ platform demo application as the software under test on an 8 Core machine. The results aren't overly surprising if you're familiar with Varnish at all. Software-based caching layers are helpful but when you are able to remove the processing overhead of it from an application, you're better off.

In the latest post to the Dutch Web Alliance blog Bas de Nooijer looks at a handy use of ESI in Varnish as a part of the output for a REST API. ESI (Edge Side Includes) let you handle the caching and reuse of fragments of the output from your application and define different caching rules/techniques for each.

For a project I’m currently working on we are implementing a REST API. Performance for this API is critical, so amongst some other solutions Varnish is used. This was done with minimal effort, as the API already had the correct caching headers. There was a noticeable improvement, however I had the feeling this could be improved much more. I realised I can basically compare our REST API to any website, it uses HTTP in the same way. The main diffence is the content being JSON instead of HTML. Just like most websites, our API composes content in many different ways, for instance ‘standalone’ resources, collections of resources or embedded resources. In a website this would be a clear use case for ESI, so why not use it in our API?

He starts off by asking the question "why use ESI in an API" and compares the ESI method to the more traditional caching rules and handling. He includes two diagrams showing the flow of each handling type along with a brief description of how it would extract and combine the data. With the background out of the way, he gets into the code. He shows how to enable JSON caching in Varnish and the JSON tag information you'll need to include to tell Varnish to do its job.

On PHPMaster.com today there's a new tutorial that can help you increase the performance of your application relatively painlessly with the help of the Varnish proxy tool. The article helps you get started.

Varnish is a reverse proxy server; it sits in front of your web server and serves content from your server and no one else’s. Reverse proxy servers are tightly coupled to the web server and can act on messages received from it. [...] Simply put, Varnish does one thing: serve web content super fast.

You'll need command line access to the machine (as well as permissions to install the software) but getting it installed is a simple "apt-get" away. There's a bit of configuration to set up to get it up and working, but it's only a few lines...and examples are included in the tutorial. They get into some of the more advanced configuration options too, like the time-to-live and changing the port it listens on. Varnish isn't just for PHP applications either - it can be used effectively for any kind of web application as it's just a proxy layer that sits on top and waits for requests.

Ole Markus has a new post to his blog looking at a technique for working with memcached and fetching data out of the store using a binary semaphore for better performance.

A typical document takes but a few hundred milliseconds to generate when a single request for the document enters the backend. The problem is that this is a highload website. In its current form, the backend serves hundreds of pages per second. This pretty much guarantees that the backend will concurrently receive cache miss on multiple languages and at the same time also receive cache miss on the pre-translated document.

Given that he wants the translated version to be the one that's always shared, a problem can come up when the cache request is "missed" and the document starts generating from multiple places. His fix for the situation is that only the first miss generates and all others see a lock on it and wait for it to be removed before successfully fetching the result. He provides code in a "LockedMemcached" class to help make it all more useful.

As is mentioned on the Zend Developer Zone, there's a new post from Bas de Nooijer about a cool feature of Varnish - Edge Side Includes - and how you can control them.

For me one of the best features of Varnish is ESI (Edge Side Includes). It allows you to combine elements with different lifetimes into a single page. This way you don’t need to regenerate a complete page as soon as a news listing somewhere on the page changes. And you can still cache pages while displaying user-specific information somewhere on the page. This lowers the load on your application even further and it can also help in simplifying your application, by focussing purely on the content of the page and loading all other elements via ESI.

He talks about the upsides and downsides to using the technique and what to avoid when implementing it in your Varnish config. One solution to the problem is sending an ESI "marker" to tell Varnish that a certain bit of content needs to be updated. He shows how to put it to use with a Zend Framework view helper that adds a special "esi" tag to the page when the content for a URL needs to be updated.