One of bottleneck in Liferay 6.1

A few days ago we’ve prepared a jmeter’s test. Our goal was to find a bottlenecks in the newest Liferay 6.1 portal. So we load about 7k AssetEntries (JournalArticles only) and drag and drop one Asset Publisher on the site. To my surprise – page loaded for about 30 seconds. In my mind was born a strange thought: is it possible have we done something wrong? Maybe our content’s importer is killing the portal. So it’s time to debug Liferay.

In AssetEntryServiceImpl we found interesting code:

protected Object[] filterQuery(AssetEntryQuery entryQuery)
throws PortalException, SystemException {
[...]
int end = entryQuery.getEnd();
int start = entryQuery.getStart();
entryQuery.setEnd(end + PropsValues.ASSET_FILTER_SEARCH_LIMIT);
entryQuery.setStart(0);
List entries = assetEntryLocalService.getEntries(entryQuery);
[...]
}

We want to pick 20 entries and Liferay get 20 + 5000 records from database. Twenty – because AssetPublisher has to display this records, plus 5000 – just in case. It gives 10040 records per request in every Asset Publisher. Furthermore – Liferay calls this method two times in every request. Firstly to get countEntries (pagination), secondly to get entities.
Later in this method Liferay checks permissions on every entity and picks only entities which have View permission. I understand this logic, but it’s very expensive.

Maybe Liferay developers should find more optimal way to get Asset Entries. I leave this question open.

Advertisement

12 Responses to One of bottleneck in Liferay 6.1

  1. Michael Han says:

    You’re probably on an older view of trunk. Latest view has this reduced via caching so that queries should be cut by 50%.

  2. Jorge Ferrer says:

    Hey Piotr,

    Thanks for noticing this. This is related to the difficulty to check permissions in a generic layer like what Asset Publisher provides.

    We are looking at several options to solve this. If you have ideas they will be welcome. BTW, have you created a ticket at issues.liferay.com?

    • hienamx says:

      Well Jorge,

      Such piece of code should not be releaset to a stable version of any product.
      If we assume that every page has at least 3 Asset Publishers (one without any filters and two with categoiries and tags set) which is very common situation it will leave my users with over 30 seconds page rendering time. Also I’ve notice that there are 30 000 queries being sent to database when rendering page with just one portlet (Asset Publisher) for logged user.

      Without proper patch for that Liferay is almost unusable because we can’t tell our customers to add another app/db server for every new page with asset publisher 😐

    • Piotr Filipowicz says:

      Jorge, I created a ticket at issues. Here is a link: http://issues.liferay.com/browse/LPS-22332

  3. Piotr Filipowicz says:

    Guys, On monday I’ll publish the results of my tests (number of queries to database, when I send one request).

  4. Pingback: Asset Publisher and queries count « eo Networks about Liferay

  5. Pingback: Asset Publisher and Lucene indexes « eo Networks about Liferay

  6. Pingback: RE: Liferay 6.1.0 beta3 Performance - Forums - Liferay.com

  7. mvmn says:

    This sucks, but you can avoid this by configuring AssetPublisher to not to check permissions. Which you should (or, well, have to) do to have ok performance.

  8. Hello there! I know this is kinda off topic however I’d figured I’d ask.
    Would you be interested in exchanging links or maybe guest writing a blog article or
    vice-versa? My website addresses a lot of the same subjects as yours and I believe we could greatly benefit from
    each other. If you are interested feel free to shoot me an e-mail.
    I look forward to hearing from you! Excellent blog by the way!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: