Download the PHP package trive/varnish without Composer
On this page you can find all versions of the php package trive/varnish. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download trive/varnish
More information about trive/varnish
Files in trive/varnish
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package varnish
Trive Varnish
Description
Magento 2 module which fixes issues with cache tags and 503 errors when using Varnish as caching application.
Installation
Install via composer:
Modify your VCL file with the following content:
Enable the module:
The issue
When using Varnish as caching application in Magento 2, each page is tagged by cache tags of the content displayed on it. These tags are then used for cache invalidation and purges, once content is updated.
For example, if you open a home page on default installation, it will be tagged with
store, cms_page and cms_page_1 cache tags.
Categories are tagged with cache tags of all products they have assigned. This means that, if you have a large catalog, with a single category containing about 2000 products, you're likely to have about 20kB worth of cache tags when first loading that category.
Cache tags are sent to Varnish as X-Magento-Tags header on initial, non-cached request to Varnish, so it can tag the URL with displayed content, and be able to clear all pages where a object appears, when requested.
Once X-Magento-Tags header gets longer than 8kB, default http_resp_hdr_len Varnish limit is hit and Varnish returns a 503 error to customers (backend fetch failed).
Even after implementing workaround from Magento Documentation, the issue is not solved, because another limit on Apache/nginx HTTP server might be hit, as they both have 8kB max header value by default.
Affected stores
Your store is affected if you are:
- using Magento 2 (any version)
- having a large number of products on store, with at least one anchor category containing at least 2000 products
- using Varnish as Magento 2 caching application, with default
http_resp_hdr_lenlimit
Your store might also be affected if you are:
- using Apache/nginx with default
LimitRequestFieldSize,large_client_header_buffers, or some other limit that might be hit by HTTP headers - using nginx/HAProxy with default header length or request size limits
- using Apache mod_proxy_fcgi
Our solution
This module addresses the above issue by separating X-Magento-Tags into 8kB header blocks.
Sending multiple X-Magento-Tags headers don't hit most of the limits, and doesn't triggers 503, nor FetchError http read error: overflow errors during Varnish backend fetch.
Note that default Magento 2 VCL file should be updated after implementing this module, to be able to collect multiple X-Magento-Tags headers into one, during Varnish procesing.
