In the chain of processes that occur during data requests, Varnish is positioned directly upstream from the web server where the desired content is found. While page requests are still initially processed by the original server, it’s the Varnish proxy that saves the request and required content. Further requests of this kind are dealt with by loading the desired data directly from the Varnish Cache. This means that the software is able to cache all data located in the working memory and allows the operating system to determine what’s to be saved to the server’s hard drive. Doing this helps users avoid simultaneously saving data on both their hard drives and in the cache.
Varnish also functions as a load balancer . With the help of the Round Robin procedure, incoming client requests are evaluated as separate worker threads that are dealt with in sequential fashion by the Varnish Cache. A fixed limit determines how many simultaneously active threads are able to be processed. Once this threshold is reached, all other requests end up in a queue where they wait to be processed. Incoming connections are only blocked once the queue’s limit is reached.
Configuring Varnish reserve proxies is mostly controlled via the Varnish Configuration Language (VCL). This makes it possible for hooks (here: a technique which allows users to integrate foreign code into the application) to be written. Once this VCL script is loaded, it’s then translated into the programming language C and compiled into a program library; the VCL instructions are linked to the Varnish cache. If the applied CMS, e-commerce software, or web application supports the markup language ESI (Edge Side Includes), Varnish is also able to transmit entirely cached pages. The tagging language generates ESI tags in the HTML files, which are used for labeling dynamic content. During client requests, Varnish Cache is able to recognize these tags and reload their corresponding content.