Hot answers tagged

49

TL; DR - On MageStack we use Varnish, Redis (cache), Redis (sessions) and Eaccelerator/Zend OPCache (depending on PHP version) You've already got most of it understood. The cache backend, session store, opcode cache, full page cached and reverse proxy cache are all completely different. You can use different technologies for all and you can use them ALL ...


28

There are two difficult things in computer science: Naming things Cache invalidation. Hole punching falls into category #2 :) General The best approach is to start at the lower points of the stack and optimize up to the frontend of Magento. Database and Filesystem Should always be the first areas to focus on. Because. I/O. MyTop is a handy Linux ...


19

Is Varnish right for you? Varnish isn't the be-all and end-all of Magento performance. Its great to offset load from bots & window-shoppers - but it shouldn't be your first port of call to actually making your store faster. In fact, implementing Varnish should be the last performance modification to your store. Only drop it in once you are seeing the ...


13

I had the same issue, I found a solution for this. I just removed the ttl attribute from /vendor/magento/module-theme/view/frontend/layout/default.xml and the menu bar appeared again.


12

You've been advised poorly. Remember that AWS doesn't do infinite scaling miracles, its just a virtual server provider AWS is nothing more than a set of virtual servers, running in a contended, shared environment. Coupled with the fact it runs older generation hardware, that has its resources crippled by the AWS hypervisor - its performance is less than ...


11

It depends on what your module is rendering. It boils down to do not render private, customer specific data server side. The exception being on completely un-cached pages (for example the customer account dashboad). In summary, I think it boils down to approaching module creation with a client-side first mindset. It is best to assume that GET and HEAD ...


10

The problem is related to an incompatibility between Magento 1.8 and Turpentine. The latest version of Turpentine requires that the varnish configuration be modified to include the following line under DAEMON_OPTS -p esi_syntax=0x2 Once this was applied, it was necessary to restart the varnish service, apply the Varnish Config (Under Cache Management in ...


10

Log in to the Magento Admin as an administrator. Click STORES > Configuration > ADVANCED > System > Full Page Cache From the Caching Application list, click Varnish Caching Enter a value in the TTL for public content field. Expand Varnish Configuration and enter the following information: Click Save Config. Click one of the export buttons to ...


8

I Would go for Redis + APC with Varnish on top. 'Why Redis' you ask? Read this excellent SO answer. Redis basically replaces Magento's standard file-based caching system. Since Redis is faster it'll give you some improvement on speed. Varnish actually doesn't have that much to do with the inner workings. It's put on top and caches static content so it ...


8

The answer I found is, Yes, a Varnish HIT should be recorded for cached pages in Magento 2 when Varnish is properly enabled. By properly, I mean: Varnish installed and running Magento 2 configured to use Varnish as FPC (Stores -> Configuration -> System -> "Full Page Cache" Download the vcl Magento gives you in the above admin area and load it into Varnish. ...


8

First, make sure you have caching enabled bin/magento cache:status Next, try to load some public page (for example the homepage) directly from apache or whichever server you're using, before varnish. In your case, it's on port 8080. Look for header Cache-Control. It must say smth like this for Varnish to work properly: Cache-Control: max-age=86400, public, ...


7

Not through Turpentine, but you can run this command (as root/sudo) to flush just the homepage (may need to adjust if Magento is not installed at the top level of your site): varnishadm ban.url '^/(?:index\.php/?)?$'


7

Yes, you can run multiple Magento 2 shops with single Varnish instance. For single Magento installation with multiple storefronts No changes needed at all For multiple Magento installations on the same server (unsupported) There is no easy solution that doesn't involve hacking Magento core code. You will at minimum have to amend changes from here. Then ...


7

Finally I fixed myself the issue. env.php 'http_cache_hosts' => array ( 0 => array ( 'host' => '127.0.0.1', 'port' => '80', ), ), default.vcl if (req.method == "PURGE") { if (client.ip !~ purge) { return (synth(405, "Method not allowed")); } if (!req.http.X-Magento-Tags-Pattern) { return (synth(400, "X-Magento-Tags-...


7

We user varnish and redis cache on our server and had this same error. This is the procedure we followed for a successful upgrade. composer require magento/product-community-edition 2.2.6 --no-update composer update rm -rf var/di/* var/generation/* var/cache/* var/log/* var/page_cache/* redis-cli flushdb curl -X 'PURGE' -H'X-Magento-Tags-Pattern: .*' ...


6

You can try using Nexcess_Turpentine, a free and community maintained Varnish and Magento module. From the module README.md Features Full Page Caching, with hole-punching via Varnish ESI and/or AJAX, even for logged in visitors Configurable via standard Magento methods (Admin system configuration and layout XML), no manual editing of Varnish config ...


5

I assume you're not referring to Magento 2. For Magento 1.x, you can use Turpentine to let Magento work with Varnish. Fair warning, this is by no means a "plug and play" process! Varnish does not terminate SSL connections, so you're correct that it won't work by itself for HTTPS. You can however use something like nginx or pound to handle the terminate part ...


5

Go to Admin panel -> Configuration -> Full Page Cache -> Varnish Configuration: Use following settings: Caching Application: Varnish Caching TTL for public content: 86400 Access list: localhost Backend host: IP of Varnish Server Backend port: Public Port of Varnish Server Hope this will help...


5

Yikes lots of questions here. BTW, feel free to open issues on our github as well to get help. I know lots of folks there use nginx, while I personally have little experience with it. Do I need to change .host IP to my site public IP and .port to 80 here? The backend should point to the IP and host where Magento is running with nginx. do I also ...


5

When you have Varnish cache enabled in Magento 2.x configuration, Page Cache is not active anymore, these are the only two options according to this line of code: https://github.com/magento/magento2/blob/6ea7d2d85cded3fa0fbcf4e7aa0dcd4edbf568a6/app/code/Magento/PageCache/Model/Controller/Result/BuiltinPlugin.php#L70


5

The information is incorrect. All the software you mentioned can co-exist just fine on the same server. However, note that you don't really need Memcached. If your intention to use it was for storing Magento PHP sessions - you can do the same just fine using Redis.


5

Especially for Varnish it makes sense to use and test ist during development as you can run into big problems laster. I just read Alan Kent's (Magento Chief Architect) Blogpost today where he explains the issue with Varnish: One particular note is inclusion of Varnish. A very common problem that has become apparent is developers are not testing ...


5

Yes, because search results change frequently and Magento doesn't know how to invalidate those results. And because the world isn't a perfect place to live :( Anyway, you can do just: # Bypass shopping cart, checkout if (req.url ~ "/checkout") { return (pass); } (note removed catalogsearch from condition) And do some "microcaching" of popular ...


5

Are you sure you have added the varnish cache to the Magento env.php config? You can do this by manually editing env.php or with this command php bin/magento setup:config:set --http-cache-hosts=hostname Until you do this Varnish will cache but clearing caches in Magento admin will not purge the Varnish cache.


5

There's a UI nuance that you need to be aware of. When first selecting Varnish as the caching mechanism, you need to Save the config before exporting the VCL. This action will pre-populate the fields with default values, and exporting the VCL from that point on will not result in an error. Specifically, the line in question will change: If config is not ...


5

Most common issue is a block included in all pages with cacheable = false. Maybe an extension with this declaration in default.xml. See vendor/magento/framework/View/Layout.php, function isCacheable. In particular: `$this->getXml()->xpath('//' . Element::TYPE_BLOCK . '[@cacheable="false"]')` To debug page load and save, see bellow. But before it, I ...


5

I ended up reaching the #varnish channel on IRC and ask for help in case a guru helps me out. So a guy called "guillaume" reached out and pointed out the error. If we inspect the panic.show log on line 8 of pastebin we can see the overflow keyword. ws = 0x7f285f09f0e0 { OVERFLOW The rest of the message refers to the backends response. So in the end what ...


5

After waiting on this question, I gathered some of the concept of warm and cold cache. By caching copies of image files, CSS, and HTML documents, the origin server does not have to generate these files each time a new visitor comes to the website. This both improves page load time and decreases stress on the origin server, meaning a website can serve more ...


5

Try this, Method 1: Add the below code to homepage cms under <referenceContainer name="content"> <block cacheable="false"/> </referenceContainer> content -> pages -> select homepage -> under design tab -> Layout update xml Method 2 : If you want it via xml in the sense add the below code into <?xml version="1.0"?> <page ...


Only top voted, non community-wiki answers of a minimum length are eligible