eZ Community » Forums » eZ Publish 5 Platform » Cached ESI can not be shared among...
expandshrink

Cached ESI can not be shared among pages (again)

Cached ESI can not be shared among pages (again)

Tuesday 09 December 2014 5:33:19 pm - 41 replies

I found that render_esi generates a very long subrequest with pathinfo information:

 GET /_fragment?_hash=...%3D&_path=pathinfo%2522%253Bs%253A62%253A%2522%252Fde%252FService-Support%252...

So it is not possible to have for e.g. one cached footer for all website pages because of this pathinfo in a call. Symfony http cache misses generates new footer cache for every page.

Is it a regression from https://jira.ez.no/browse/EZP-21695  or is it possible to get rid of pathinfo in a render_esi subrequest?

My installation is 5.3.3. 

Modified on Tuesday 09 December 2014 5:51:07 pm by Andrey Astakhov

Monday 22 December 2014 2:09:25 pm

I didn't check this lately but I am sure that this was not a problem on the 5.2 version.

It the additional parameter was introduced in the meanwhile, its a very bad feature happy.gif Emoticon and should be removed. maybe the best is to report to jira

Tuesday 23 December 2014 4:51:49 pm

Thank you for this information.

A bug is already reported in project.issues.ez.no. It appears only if Map\URI matcher is used in a siteaccesses configuration.

I hope it will be fixed soon, but there are also other issues that make using HTTP caching and ESI very difficult and unreliable. E.g the full fragment url for esi/hinclude requests is too long. If you have a plenty of siteaccesses (10-20), then final url will exceed max url length and hinclude will not be an option any more.

Modified on Tuesday 23 December 2014 4:52:35 pm by Andrey Astakhov

Wednesday 24 December 2014 9:35:28 am

Quote from Andrey Astakhov :

I hope it will be fixed soon, but there are also other issues that make using HTTP caching and ESI very difficult and unreliable. E.g the full fragment url for esi/hinclude requests is too long. If you have a plenty of siteaccesses (10-20), then final url will exceed max url length and hinclude will not be an option any more.

Yes, we noticed that too. so far we don't have such instance on ez5, but soon we might. 

Btw, we use ESI fragments were it makes, but not much hinclude. Only when you want to cache something on user browser (block with some user specific data) it makes sense.

What is your experience?

Wednesday 24 December 2014 10:25:59 am

Yes, it makes sense. Otherwise private esi cache blocks make a loading of a whole page too slow. On the other hand an ajax loader in a header might look unusal.

Another obvious example of using hinclude is a cache block with a data from an external resourse (e.g. ERP or CMS). 

Wednesday 24 December 2014 11:04:38 am

Quote from Andrey Astakhov :

Yes, it makes sense. Otherwise private esi cache blocks make a loading of a whole page too slow. 

Any data to show? How much slower?

Thursday 15 January 2015 9:26:08 am

I'd say significantly slower. Right now I'm trying to find bottlenecks in a project using blackfire.io. Let's see on numbers.

Time for complete page generation is 950 ms. On that page I have one call of render_esi with setPrivate in the controller and this block takes 630 ms. 

And it is always like that. Do you have another experience with esi?

Thursday 15 January 2015 10:40:04 am

Quote from Andrey Astakhov :

I'd say significantly slower. Right now I'm trying to find bottlenecks in a project using blackfire.io. Let's see on numbers.

Time for complete page generation is 950 ms. On that page I have one call of render_esi with setPrivate in the controller and this block takes 630 ms. 

And it is always like that. Do you have another experience with esi?

Not much, I had no time to make compare tests. That is why I am interested in this.

So 320ms is going on varnish page rendering?

How fast is the page when you use render instead of render_esi?

Thursday 15 January 2015 10:59:00 am

Very interesting this thing cause i'm exactly on it. 

Briefly, i have an inmimient ecommerce ez5 project where in the top of the page we have a shop basket summary that cannot be cached. This part is rendered using a subrequest.

Well, let's suppose i have ezpublish5 view cache activated, setting big ttl and that i use "render" for that part. 

Using blackfire.io to profile it says only 1MB is needed, only 17 class are added to composer... in briefly, very GOOD numbers. btw, siege shows it can support more than 200 reqs / sec in my dev machine. 

But, if i've just change that render to a render_esi and profile, memory usage rise to 28MB or something like that and classes added to auload renders to more than 600!

In that controller i set a sharedMaxAge of 0 in order to not cache anything. 

But well, i need to use render_esi there so every user can see its own data and not data from the others

If i find sometime i'll try to do some profiling to ez demo changing and tell you what i found. 

Thursday 15 January 2015 11:10:13 am

Quote from Carlos Revillo :

If i find sometime i'll try to do some profiling to ez demo changing and tell you what i found. 

Do you have siteaccess matching by uri on your project?

Thursday 15 January 2015 11:15:13 am

Quote from Carlos Revillo :

Very interesting this thing cause i'm exactly on it. 

Briefly, i have an inmimient ecommerce ez5 project where in the top of the page we have a shop basket summary that cannot be cached. This part is rendered using a subrequest.

Well, let's suppose i have ezpublish5 view cache activated, setting big ttl and that i use "render" for that part. 

Using blackfire.io to profile it says only 1MB is needed, only 17 class are added to composer... in briefly, very GOOD numbers. btw, siege shows it can support more than 200 reqs / sec in my dev machine. 

But, if i've just change that render to a render_esi and profile, memory usage rise to 28MB or something like that and classes added to auload renders to more than 600!

In that controller i set a sharedMaxAge of 0 in order to not cache anything. 

But well, i need to use render_esi there so every user can see its own data and not data from the others

If i find sometime i'll try to do some profiling to ez demo changing and tell you what i found. 

So you are testing this without varnish but with internal proxy?

Thursday 15 January 2015 11:22:19 am

Andrey: I've got two siteaccess, frontend and backend but both have his own subdomian

Ivo: Yes, with internal proxy. Why you ask this? happy.gif Emoticon If you have an idea let me know happy.gif Emoticon

Modified on Thursday 15 January 2015 11:22:45 am by Carlos Revillo

Thursday 15 January 2015 11:26:54 am

Quote from Carlos Revillo :

 

Ivo: Yes, with internal proxy. Why you ask this? happy.gif Emoticon If you have an idea let me know happy.gif Emoticon

Testing with internal proxy doesn't make sense beacue it loads the proxy etc, and it will not be used on live server anyway. Maybe on some very small projects.

I am interested on how much overhead is on Varnish when its using ESI blocks...

Thursday 15 January 2015 11:35:05 am

There we go. In this link you can see two profiles. first one is ezdemo as it cames. second one is just after changing render to render_esi in this line

I'll try to test with varnish... 

Modified on Thursday 15 January 2015 11:35:39 am by Carlos Revillo

Thursday 15 January 2015 2:38:31 pm

Hi guys

Sorry for not replying before (vacation happy.gif Emoticon).

See https://jira.ez.no/browse/EZP-23834 . I'm on it and a fix will be out soon blunk.gif Emoticon

Thursday 15 January 2015 2:41:21 pm

Quote from Andrey Astakhov :

I found that render_esi generates a very long subrequest with pathinfo information:

 GET /_fragment?_hash=...%3D&_path=pathinfo%2522%253Bs%253A62%253A%2522%252Fde%252FService-Support%252...

So it is not possible to have for e.g. one cached footer for all website pages because of this pathinfo in a call. Symfony http cache misses generates new footer cache for every page.

Is it a regression from https://jira.ez.no/browse/EZP-21695  or is it possible to get rid of pathinfo in a render_esi subrequest?

My installation is 5.3.3. 

Yes, it's valid issue but it doesn't seem to be a regression. As far as I can see it's been here from the beginning. The only way to get rid of the pathinfo is to avoid the matcher's injected request to be serialized with it, but URI matchers need it to generate links when you're inside an ESI. I'll open a pull-request soon.

Thursday 15 January 2015 2:51:08 pm

Quote from Jérôme Vieilledent :
Quote from Andrey Astakhov :

I found that render_esi generates a very long subrequest with pathinfo information:

 GET /_fragment?_hash=...%3D&_path=pathinfo%2522%253Bs%253A62%253A%2522%252Fde%252FService-Support%252...

So it is not possible to have for e.g. one cached footer for all website pages because of this pathinfo in a call. Symfony http cache misses generates new footer cache for every page.

Is it a regression from https://jira.ez.no/browse/EZP-21695  or is it possible to get rid of pathinfo in a render_esi subrequest?

My installation is 5.3.3. 

Yes, it's valid issue but it doesn't seem to be a regression. As far as I can see it's been here from the beginning. The only way to get rid of the pathinfo is to avoid the matcher's injected request to be serialized with it, but URI matchers need it to generate links when you're inside an ESI. I'll open a pull-request soon.

From my point of view, having 2 different outputs for the same page on 2 different sitaccess is ok. What is, of course, not ok having different outputs for 2 dfferent pages on the same siteaccess.

Right?

Thursday 15 January 2015 3:00:35 pm

Exactly Ivo. And this is what I'm currently working on blunk.gif Emoticon

Thursday 15 January 2015 3:28:23 pm

Pull-request ready !

https://github.com/ezsystems/ezpublish-kernel/pull/1140

Thursday 15 January 2015 3:44:13 pm

Quote from Jérôme Vieilledent :

Pull-request ready !

https://github.com/ezsystems/ezpublish-kernel/pull/1140

Thank you, Jérôme.

I'd mention another related problem. We have about 50 siteaccesses in our project. However it is not even a limit because of a number of countries and languages.

Information about all this siteaccesses is serializing into very long /_fragment?_hash= uri so it exeeds a uri length limit of a web server.

Hence it is not posssible to use hinclude instead of esi in this project. Is this problem solvable in general? 

Thursday 15 January 2015 4:20:56 pm

I guess you're referring to EZP-23168. If so, it's already fixed blunk.gif Emoticon

expandshrink

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

36 542 Users on board!

Forums menu

Proudly Developed with from