掲示板

Change Image gallery path and use of Varnish

11年前 に Pierre Le roux によって更新されました。

Change Image gallery path and use of Varnish

New Member 投稿: 9 参加年月日: 12/07/20 最新の投稿
Hello,

I would like to use Varnish in front of Liferay in order to cache image_gallery files and deserve quicker than with my Tomcat.

I have few questions about doing this :
- By default, image gallery uses src="/image/image_gallery/xxx", so it stays on the same server. Is there a way to change (without overriding Liferay JSP) image path ? Did anybody already try it ? Is there any drawbacks i have to consider ?

- Did anybody already try to use Varnish with Liferay ? Can i really expect performance increase ?

Thanks for your help.

Regards,

Pierre
thumbnail
11年前 に Juan Gonzalez P によって更新されました。

RE: Change Image gallery path and use of Varnish

Liferay Legend 投稿: 3089 参加年月日: 08/10/28 最新の投稿
I tried to use Varnish in Liferay 6.0.5 without much luck. Portal became much slower, but perhaps it was due to something misconfigured.

I don't think Varnish will increase performance a lot in Liferay, because Liferay has is own resource cache management (using HTTP headers) .
thumbnail
11年前 に Ákos Gábriel によって更新されました。

RE: Change Image gallery path and use of Varnish

Junior Member 投稿: 33 参加年月日: 09/10/05 最新の投稿
I have different experiences. In our case (rather complex page, complex business functionality behind every page creation) Varnish increased the performance of the page dramatically. From 70 req/min and 2-3 sec page download time it changed to 1100-1400 req/min and 10-20ms page download time. Page is loading instantly. Resources are loaded in the same tcp stream so rendering is instant as well.

Every measurement tool confirms that.

The problem you might have faced is that Liferay fills the response with cookies and by default Varnish doesn't cache these pages. In fact you would cache static resources only. With careful selection of pages this caching can be enabled and you'll benefit from the increased performance.

As soon as I have some time I plan to summarize the experience in a howto page soon.
11年前 に Pierre Le roux によって更新されました。

RE: Change Image gallery path and use of Varnish

New Member 投稿: 9 参加年月日: 12/07/20 最新の投稿
Hi

Thanks for all your answers. Akos, i'm looking forward for your results.

We are going to try with an NGINIX server. I don't know if Liferay can work with G-WAN. I just saw this benchmark
http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/

About CDN, i activated http.cdn.host configuration and i think we are going to be quicker on browser to complete pages

I think our configuration is going to be :
- Front-end with NGINIX for both portal url and CDN url
- Backend with Tomcat

At first use of a resource, NGINIX is going to call Tomcat and cache result.
On next uses, NGINIX will serve directly the resource.

When i have results, i post here.

A question for you :
when you use varnish, do you also use CDN configuration ? If yes, did you achieve to configure Liferay to serve media resources (image_gallery in 6.0.5 or media gallery in 6.1) with CDN url ?


When i'm looking to image gallery in Liferay 6.0.5, i found this in view_image.jsp

url='<%= (Validator.isNull(themeDisplay.getCDNHost()) ? themeDisplay.getPortalURL() : "") + themeDisplay.getPathImage() + "/image_gallery?uuid=" + image.getUuid() + "&groupId=" + image.getGroupId() + "&t=" + ImageServletTokenUtil.getToken(image.getLargeImageId()) %>'


As i declared a CDN, portalUrl is not included but i get "" instead of my CDN path.

In Liferay 6.1.0, all CDN references seem to have disapear in media gallery mecanism.

Can any anybody explain that ?
thumbnail
11年前 に Hitoshi Ozawa によって更新されました。

RE: Change Image gallery path and use of Varnish

Liferay Legend 投稿: 7942 参加年月日: 10/03/24 最新の投稿
What you outlined can be done with Apache httpd server too. With Apache, I just have to set not to transfer img request to liferay. Can do the same with css and javascript files too.

The downside is that when I do an update of liferay, I'll have to update transfer these files once again.