eZ Community » Forums » General » Varnish + ESI, looking for feedback
expandshrink

Varnish + ESI, looking for feedback

Varnish + ESI, looking for feedback

Saturday 02 January 2010 11:51:36 am - 12 replies

Hello all,

I wonder who implements Varnish + ESI support on real life websites and have a feedback about it, especially a focus on : integration versus maintenability, cost/time to integrate ESI.

I read this blog post : (in french) http://www.karlesnine.com/post/20...cu-%C3%A0-la-mort-de-Michael-Jackson. It's an interesting starting point between Squid ICP / Varnish ESI.

Thanks

Happy New Year

See you in Switzerland (I hope).

Pablo

Wednesday 06 January 2010 11:17:32 am

Version:1.0 StartHTML:0000000167 EndHTML:0000002398 StartFragment:0000000449 EndFragment:0000002382

Hello

 

Thank for the link to my blog.

 

About Squid vs Varnish I think is a wrong way to compare both like that because each of them is the solution for a issue .

 

Quickly this is my point of view.

 

If you need a strong reverse proxy architecture with a high capacity, for many différent web sites or service, provided by different technology or cms you dont have a choice: you must use ICP for reduce the number of request to you php servers.

 

If you need a strong reverse proxy architecture with a high capacity, for one web site provided by different technology or back office : you dont have a choice: you must use ESI for compose the page directly on the last stage; the revers proxy servers

 

If you need a strong reverse proxy architecture with a high capacity, for one web site provided with a very high audience: you dont have a choice: you must use ESI for build the site on the static stage: reverse proxy .

  • Varnish provide the ESI
  • Squid 2.7 provide the ICP
  • Squid 3 provide ICP and the ESI

You can imagine different solution:

  1. Use only one of them
  2. Use a stage of many squid, they exchanging their cache by ICP. front of of many single varnish server who compose the web page by ESI
  3. Use directly a stage of Squid 3.x servers

In my experience with eZ publish I was using a stage of many squid revers proxy v2.7 linked by ICP for the cache exchange. Behind them I had differentes php farm who provide different eZ publish web site.

My 2ct

Wednesday 06 January 2010 1:03:57 pm

And you have also Traffic Server. Formerly a commercial product (created by Inktomi, later acquired by Yahoo!)" the reverse proxy solution from Yahoo and now a open source project hosted by the Apache Fondation. Traffic Server supports ICP (Internet Cache Protocol) peering

My 0,5ct more

Wednesday 06 January 2010 2:11:54 pm

Thanks for your feedback, we're obviously in the one web site with high capacity context, so Varnish appears to be the solution, all the more with the eZSI extension. Any caveats about ESI and eZ ?

Merci pour tes retours

Pablo

Friday 08 January 2010 8:05:30 am

The reply has been removed because of violation of forum rules.

Tuesday 02 February 2016 12:33:19 pm

Quote from Pablo Pernot :

Thanks for your feedback, we're obviously in the one web site with high capacity context, so Varnish appears to be the solution, all the more with the eZSI extension. Any caveats about ESI and eZ ?

Merci pour tes retours

Pablo

Hi Pablo,

Did you get a perfect solution? How was the combination of ESI and EZ legacy?

Thanks,

Rana

Tuesday 02 February 2016 10:26:44 pm

We've had good success with ESI on eZ Publish legacy. We wrote a simple extension (https://github.com/mugoweb/mugo_esi) that provides a framework to do this with standard eZ Publish modules, which we felt was easier to use and as effective as ezsi.

Wednesday 03 February 2016 6:12:56 am

Quote from Peter Keung :

We've had good success with ESI on eZ Publish legacy. We wrote a simple extension (https://github.com/mugoweb/mugo_esi) that provides a framework to do this with standard eZ Publish modules, which we felt was easier to use and as effective as ezsi.

Hi Peter,

 

Thank you very much for your response. I'll definitely check it out. By the way, does this extension make ajax call to load the esi block or just communicate with gateway cache(i.e. varnish)?

 

Thanks again,

Rana

Wednesday 03 February 2016 8:04:22 am

Hi Peter,

 

As far as I understand, I don't need to run any cron, right?

 

Thanks,

Rana

Thursday 04 February 2016 2:18:13 am

Correct, no cron is needed. ESI blocks are expired according to the configured TTLs. Also, the extension makes Ajax calls only when you're not using Varnish (for testing purposes). Otherwise Varnish makes the call to the ESI block and assembles the page for the user.

Wednesday 04 May 2016 7:47:05 am

Hi Peter,

It worked as long as we route through /ezpublish_legacy. Now we've moved to hybrid stack. When varnish caching enabled, it doesn't work. It just shows esi tag in HTML code.

Did you experience this problem? Would you please put some light on it?

Thanks,

Wednesday 04 May 2016 4:50:28 pm

We haven't tested it in a hybrid solution, unfortunately. In your Twig templates you can of course use render_esi, which removes the need for the legacy ESI extension. But if you're still using legacy templates, I don't know why Varnish won't read the ESI tag. Did you change your Varnish config without the do_esi setting?

Monday 16 May 2016 10:56:54 am

Hi Peter,

 

Thank you for your response. 

We later implemented ESI (/_fragment) in SF2 way and call that function from legacy template using Netgen's https://github.com/netgen/ngsymfonytools.

 

Thanks,

Rashidul

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from