dear community,

we are evaluating liferay portal server (tomcat6 bundle on jdk5) for the implementation of a rather big finance portal ;
until now we were very impressed by all the out of the box functionality liferay provides.
we have a decent machine running only the liferay portal server. delivery of simple pages sometimes needs more than 10 seconds (with only one user!)

the attached diagram shows (via the TamperData Extension) how firefox loads all the necessary resources for a simple portal page (a page with the invitation portlet, the forum portlet and the calendar portlet on it);

the delivery time of the html (469ms) is ok.
but it's when the browser loads all the js and css files that the user has to wait for about 5 seconds to see any page content, and another 2.5 seconds are necessary until all remaining resources are loaded.
this makes navigating through the portal a real pain.

there are about 80 resources, mostly static content and the browser issues a conditional get request for most of them, and has to wait for the response, the 304 tells the browser "resource has not changed, take it from the cache";
as all these resources are rather small, the savings are not that big, about 30% compared to a full reload of all the page resources (by typing ctrl-F5)

is there a concept on how to optimize the user expierience and to shorten these page load times?
would it help to use expiration headers, merge/compress javascript, let apache webserver deliver static content?

btw, i get similar results when looking at demo.liferay.net;

thx for any advice,

fusel!

Attachments:

Browser-Requests.png (204.0k)

Start by setting the following properties in portal-ext.properties:

#
# Set the following to true to check last modified date on server side CSS
# and JavaScript.
#
last.modified.check=false

#
# Set this property to true to load the theme's merged CSS files for faster
# loading for production. Set this property to false for easier debugging
# for development. You can also disable fast loading by setting the URL
# parameter "css_fast_load" to "0".
#
theme.css.fast.load=true

#
# Set this property to true to load the combined JavaScript files from the
# property "javascript.files" into one compacted file for faster loading for
# production. Set this property to false for easier debugging for
# development. You can also disable fast loading by setting the URL
# parameter "js_fast_load" to "0".
#
javascript.fast.load=true

GREAT! thank you very much for this quick response!

these settings reduced the delivery time for all the js/css/img stuff from 7.5 to 2.4 seconds.
i added the corresponding chart.

regards, fusel!

Attachments:

Browser-Requests-faster.png (45.9k)

Hello Fusel.

which tool are you using for those graphs?

The reason I'm asking is that I would like to do the same evaluation with a production portal I'm currently running.

Thanks!


Cheers

r

Fusel, we've just recently made a few corrections to the filter configurations that (since you're testing performance) I think might improve your results.

If you look at http://support.liferay.com/browse/LEP-4764 and specifically at

http://lportal.svn.sourceforge.net/viewvc/lportal/portal/trunk/portal-web/docroot/WEB-INF/web.xml/?rev=12857&view=diff&r1=12857&r2=12856&p1=/portal/trunk/portal-web/docroot/WEB-INF/web.xml&p2=/portal/trunk/portal-web/docroot/WEB-INF/web.xml

and

http://lportal.svn.sourceforge.net/viewvc/lportal/portal/trunk/portal-web/docroot/WEB-INF/web.xml/?rev=12903&view=diff&r1=12903&r2=12902&p1=/portal/trunk/portal-web/docroot/WEB-INF/web.xml&p2=/portal/trunk/portal-web/docroot/WEB-INF/web.xml

When you made your first post I was working on this, and thought... "Oh man I gotta' get this done!"

The basic change was to NOT filter on request dispatcher includes... this means that, all the way through the struts stack, every jsp include, all the way to each portlet... was calling every filter. Ouch!

While I've tested the fix's usage and have noticed quite some improvement, it would be nice to get a glimpse of any real improvements.

The changes above should backport easily to most recent versions of the portal.

hi renato,

i use this great firefox extension: Tamper Data] for the job.

regards, fusel!

thx ray for this hint!

for my current test case, these numbers did not change with the new web.xml - but thats clear, in my testcase its not the html being generated too slow, but the GET requests for the images.
i will test a more database/computing intensive testcase these days and will post the results then.

in my case its the answers (304) to the conditional GET requests of the browser that take such a long time. its strange to see that an empty 304-response takes four times longer (=my last measures) than delivering the generated html. so the browser has to wait more than 1.4 second before he can start to render the page.

could that be a bug in tomcat?
do others also expierience this behaviour?
is it common to let apache handle the static files (and the corresponding cache handling)?

thx & best regards, fusel!

Update:

i disabled showing images in my browser to get rid of the slow 304 responses;
but it didnt make page rendering faster; firefox is still fetching these other little pieces (see graph) one after the other.

i also have no idea why there are these long pauses, e.g. between the 2nd and the 3rd request.

regards, uwe!

Attachments:

without_images.png (38.1k)

calls to /language/... are actually ajax calls to localized strings from some js components in the UI. they should be cached by portal build number so as to reduce load.

As for the pause.. I'm not sure... perhaps we need to look at the outcome of css_cached to see what is so intense on the browser to block it so. And considering it's supposed to be cached? why is it resulting in a 200

everything_packed.js is definitely a fairly substantial amount of js to process... I can understand the pause there... even when it's cached the browser still needs to load it all into memory and process it.

hi ray,

thanks again for your helpful response;
i understand now, to further decrease page delivery time we can tune cache header settings and maybe reduce css complexity.

for the moment i have to defer investigation on this topic and move on to look if liferay's performance scales well for our needs.

i'd like to contribute my findings later on, maybe as a wiki page.

best regards, fusel!

I am using Firefox plugin Firebug with simillar functionality plus all the HTML CSS JS tools.
Firebug is really "musthave" tool for web developers.

Nice tool!!

I added these parameters but didn't notice any performance improvement.

I also tried :

# The layout cache filter will cache pages to speed up page rendering for
# guest users. See ehcache.xml to modify the cache expiration time to live.
com.liferay.portal.servlet.filters.layoutcache.LayoutCacheFilter=true

but also saw no performance improvement.

Any other performance suggestions?

Hi Everyone ,

i need to increase the performance of the page load i am using the page speed tool but the score that i get is low i had trying entry various entry in portal-ext file to increase the page speed on the production server .

my entry in portal-ext is as follows

theme.css.fast.load=false
theme.images.fast.load=true

javascript.fast.load=false
javascript.log.enabled=true

layout.template.cache.enabled=false
layout.show.portlet.access.denied=false

browser.launcher.url=

combo.check.timestamp=true

freemarker.engine.cache.storage=soft:1
freemarker.engine.modification.check.interval=2

openoffice.cache.enabled=false

velocity.engine.resource.manager.cache.enabled=false

com.liferay.portal.servlet.filters.cache.CacheFilter=false

com.liferay.portal.servlet.filters.themepreview.ThemePreviewFilter=true

layout.show.portlet.access.denied=false

com.liferay.portal.servlet.filters.header.HeaderFilter=true

session.enable.url.with.session.id=false
last.modified.check=false

if any body has any suggestion the pls help i am using liferay 6.0.5 .

Regards
Sandeep