Forums

Home » Liferay Portal » English » 2. Using Liferay » General

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Patrizio Munzi
Liferay 5.2.3 CE poor service performance
August 10, 2012 8:26 AM
Answer

Patrizio Munzi

Rank: New Member

Posts: 12

Join Date: November 3, 2011

Recent Posts

Hi All,
I'm trying to do some performance tests in liferay services.
What I do is to write a table entry on IGFolder table in each call to a servlet.
My servlet is as following:

 1
 2public class TestServlet extends HttpServlet{
 3
 4    private static Log                   _log          = LogFactoryUtil.getLog(TestServlet.class);
 5
 6    @Override
 7    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException {
 8       
 9        try {
10            String       groupId         = ParamUtil.getString(request, "groupId" ,"0");
11            String       name     = ParamUtil.getString(request, "name", "");
12            long _groupId = 0;
13            try {
14                _groupId = Long.parseLong(groupId);
15            } catch(Exception e) {
16                _log.error("KO - Wrong GroupId.");
17                response.setStatus(HttpServletResponse.SC_BAD_REQUEST);
18                return;
19            }
20            
21            ServiceContext serviceContext = getServiceContext(_groupId);
22            IGFolderLocalServiceUtil.addFolder(10237, 0, name, name, serviceContext);
23[...]


What I see is that in the following two different scenarios I get the same performances, then my system is not scaling.
Scenario 1:
100 councurrent threads
200 call per thread

Scenario 2:
1 thread
20000 call per thread

Both scenarios have a throughput of about 10 calls per seconds

Liferay and MySQL run on different machines.

I've made a lot of analysis but I cannot understand what's the problem.
I've changes also all tables engines to InnoDB
David H Nebinger
RE: Liferay 5.2.3 CE poor service performance
August 10, 2012 9:14 AM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 11464

Join Date: September 1, 2006

Recent Posts

The IGFolderLocalServiceUtil.addFolder() method is calling a method on a single shared bean. Regardless of how many threads you use to call addFolder(), there's still one bean doing the writing to the DB.

This is actually a good thing because it prevents deadlocks (two threads trying to update the same record at one time).
Patrizio Munzi
RE: Liferay 5.2.3 CE poor service performance
August 10, 2012 10:31 AM
Answer

Patrizio Munzi

Rank: New Member

Posts: 12

Join Date: November 3, 2011

Recent Posts

Thanks for you answer,
I made this test because I have some own tables which must be updated very frequently through a servlet.

I wonder if "all" the writing to the lportal DB built by the Service Builder make use of a single shared bean.

That wouldn't be nice from performance point of view.
I also saw an high iowait on the db server, around 35% whereas the cpu time is in the order of 2%
David H Nebinger
RE: Liferay 5.2.3 CE poor service performance
August 10, 2012 11:42 AM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 11464

Join Date: September 1, 2006

Recent Posts

Anything built w/ Service Builder (even custom entities) will have the same implementation - single writer.

Note that SB-generated code, being based on Hibernate, is not good for batch processing. It was never intended to support batch loading (neither is Hibernate).

If you are batch-loading data, you should find a different implementation.
Brian Kim
RE: Liferay 5.2.3 CE poor service performance
August 10, 2012 5:43 PM
Answer

Brian Kim

LIFERAY STAFF

Rank: Expert

Posts: 319

Join Date: August 16, 2004

Recent Posts

You really should consider moving to 6.1. There was a new permission algorithm (algorithm 6) introduced in 6.0 that you'll likely benefit from that will significantly improve the performance of your portal.

More details here:

http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Liferay+Portal+Permission+Algorithms
Hitoshi Ozawa
RE: Liferay 5.2.3 CE poor service performance
August 10, 2012 6:36 PM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7949

Join Date: March 23, 2010

Recent Posts

Brian's right. Complaining about performance/feature of old version is just nonsense. People don't complain about about MS Windows 3 anymore.

I don't think developers' are no longer working on Lfieray 5.2.3 anymore. If you can't solve the problem yourself, either upgrade to the new version, subscribe to Liferay.com support, or pay someone else to do it for you.
Patrizio Munzi
RE: Liferay 5.2.3 CE poor service performance
August 11, 2012 12:33 AM
Answer

Patrizio Munzi

Rank: New Member

Posts: 12

Join Date: November 3, 2011

Recent Posts

Migrating to LFR 6.1 could be an option but in this specific case only if it doesn't use a single writer for writing service entities anymore.

Brian Kim:
You really should consider moving to 6.1. There was a new permission algorithm (algorithm 6) introduced in 6.0 that you'll likely benefit from that will significantly improve the performance of your portal.

I use a simple servlet calling a method inside a service without considering permission or anything. Is the permission algorithm involved in the call anyway?

My next step will be making the same test, with the same servlet, on LFR6.1.

I'll b back shortly,
Thank you all
David H Nebinger
RE: Liferay 5.2.3 CE poor service performance
August 11, 2012 8:55 AM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 11464

Join Date: September 1, 2006

Recent Posts

Patrizio Munzi:
I use a simple servlet calling a method inside a service without considering permission or anything. Is the permission algorithm involved in the call anyway?


Every entity (for the most part) is permissioned.
Hitoshi Ozawa
RE: Liferay 5.2.3 CE poor service performance
August 11, 2012 5:35 PM
Answer

Hitoshi Ozawa

Rank: Liferay Legend

Posts: 7949

Join Date: March 23, 2010

Recent Posts

I've made a lot of analysis but I cannot understand what's the problem.


First, why are you writing servlets? Liferay is designed to execute portlets. If you want to run servlet, just use Tomcat.
Second, liferay is designed to use cache when services are build using service builder. Services generated this way do not write I/O directly to a database.
Third, how is your entity modeled? Liferay is designed for transactional high input transaction.

In all, I think it's more of a problem with you software and system/software architecture than with liferay. Recommend taking some basic courses offered by liferay.
Patrizio Munzi
RE: Liferay 5.2.3 CE poor service performance
August 12, 2012 11:56 PM
Answer

Patrizio Munzi

Rank: New Member

Posts: 12

Join Date: November 3, 2011

Recent Posts

Hitoshi Ozawa:
I've made a lot of analysis but I cannot understand what's the problem.


First, why are you writing servlets? Liferay is designed to execute portlets. If you want to run servlet, just use Tomcat.


1) I've written a servlet because at first I've noticed the problem in a serveResource method (called via AJAX) so I decided to take out the code e put in a servlet to simplify the complexity.
There's no difference calling a liferay service method from a serveResource method or from a servlet, further because the issue is in service writing shared bean.

Second, liferay is designed to use cache when services are build using service builder. Services generated this way do not write I/O directly to a database.


2) I've used the lifeary service builder to generate the service. So my service should already leverage LFR cache features. Can I do anything better??


Third, how is your entity modeled? Liferay is designed for transactional high input transaction.


3) I defined a dummy entity and a dummy service with only a table and only a method writing a line in this table. Is it possible to go simpler.
Moreover I also repeated the same test using a LFR built-in service (the addFolder example I talked about above) with the same results. I don't think the document library service is not well designed.


In all, I think it's more of a problem with you software and system/software architecture than with liferay. Recommend taking some basic courses offered by liferay.


4) I could take them but I don't think they will help me solve the writing shared bean service problem. Will they???

5) Hopefully today I'll make the same tests in LFR6.

Finally, dear Hitoshy, are you a Liferay Sales ? In all your replies you propose liferay training or consultancy or hupgrade....
AFAIK, this is a technical forum for open discussions and to share suggestions not a place to fire sentences.
If you have any suggestion to make the liferay writing shared bean faster I'm very keen to hear them

Thanks,
Pat
David H Nebinger
RE: Liferay 5.2.3 CE poor service performance
August 13, 2012 5:29 AM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 11464

Join Date: September 1, 2006

Recent Posts

Patrizio Munzi:
Finally, dear Hitoshy, are you a Liferay Sales ? In all your replies you propose liferay training or consultancy or hupgrade....


Neither Hitoshi or I are in sales, but we are extremely active in this tech forum.

Unfortunately many of the newbie questions that come in are from those who haven't read the doco, didn't take any classes, don't understand the portlet specs, etc. Even 20+ years after the internet went live (depending upon who you think invented the internet emoticon ), we still have to step forward at times and say RTFM...
Patrizio Munzi
RE: Liferay 5.2.3 CE poor service performance
August 13, 2012 8:50 AM
Answer

Patrizio Munzi

Rank: New Member

Posts: 12

Join Date: November 3, 2011

Recent Posts

David H Nebinger:

Unfortunately many of the newbie questions that come in are from those who haven't read the doco, didn't take any classes, don't understand the portlet specs, etc. Even 20+ years after the internet went live (depending upon who you think invented the internet emoticon ), we still have to step forward at times and say RTFM...


I understand.

BTW.
I've made the same tests with LFR 6 and performance are better, but not so much. Anyway it's something.

In your opinion is it possibile to use the permissions algorithm of LFR 6 in LFR 5??
I really don't have time to migrate to LFR6... :-)
David H Nebinger
RE: Liferay 5.2.3 CE poor service performance
August 13, 2012 9:23 AM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 11464

Join Date: September 1, 2006

Recent Posts

Patrizio Munzi:
In your opinion is it possibile to use the permissions algorithm of LFR 6 in LFR 5??


I don't know for certain, but I'd tend to believe it would be difficult. I think the permission algs are tied to database entities so you'd end up probably having to backport more than just the algorithm itself.
Brian Kim
RE: Liferay 5.2.3 CE poor service performance
August 13, 2012 10:48 AM
Answer

Brian Kim

LIFERAY STAFF

Rank: Expert

Posts: 319

Join Date: August 16, 2004

Recent Posts

There are definitely database changes that were required of Algorithm 6, so David is right in that you would have to spend a lot of time and energy to get it to work in an unsupported Liferay version. Not to mention, your objects themselves need to also have attributes to use Algorithm 6.
Patrizio Munzi
RE: Liferay 5.2.3 CE poor service performance
August 22, 2012 3:00 AM
Answer

Patrizio Munzi

Rank: New Member

Posts: 12

Join Date: November 3, 2011

Recent Posts

David H Nebinger:
Anything built w/ Service Builder (even custom entities) will have the same implementation - single writer.

Note that SB-generated code, being based on Hibernate, is not good for batch processing. It was never intended to support batch loading (neither is Hibernate).

If you are batch-loading data, you should find a different implementation.


I've done some more tests and what I see is that the performances problem doesn't look to refer to the permission algorithm but to the hibernate object saving algorithm.
Moreove even if I write on two different bean (I tried also two different bean of two different services) the performances are the same.
So looks like the writing serialization issue is on the low level I/F towards hibernate/DB not a service builder entities level.

Is this possible??

BTW: I'm not batch processing data, I'm trying to simulate many concurrent users.
David H Nebinger
RE: Liferay 5.2.3 CE poor service performance
August 22, 2012 5:29 AM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 11464

Join Date: September 1, 2006

Recent Posts

Patrizio Munzi:
I've done some more tests and what I see is that the performances problem doesn't look to refer to the permission algorithm but to the hibernate object saving algorithm. Moreove even if I write on two different bean (I tried also two different bean of two different services) the performances are the same.
So looks like the writing serialization issue is on the low level I/F towards hibernate/DB not a service builder entities level.

Is this possible?


Invocation of an SB method actually involves a lot more than just the Hibernate save...

You're crossing a class loader boundary (to get from the servlet's class loader into the class loader of the portlet providing the service), so there is some serialization/deserialization going on there.

Eventually it will go to hibernate for persisting.

Hibernate is not always the best tool for database writing (this stands out when you're trying to do batch loading). Hibernate shines when it comes to many concurrent readers, not so much on concurrent writers (similar sort of issue).

You're going to want to look at your hibernate config, ensure that you're using ehcache correctly for your retrieves. You're going to want to look at your transaction management, as most of the SB code will use a transaction per call.

And finally you want to consider the calls that your many concurrent users are making. Creating a new image gallery folder, for example, is one of the heavy methods to pick from. It's not just affecting the database but it's also doing stuff in the repository. And for simulating concurrent users, concurrent users would not all be creating new image gallery folders at the same time (and probably shouldn't have permissions to do so as this is really an administrative function).

If you want to test something, test something the concurrent users would do. For Liferay, for example, they would choose to simulate posting forum messages as this is what the bulk of their concurrent users actually do.
Patrizio Munzi
RE: Liferay 5.2.3 CE poor service performance
August 22, 2012 6:06 AM
Answer

Patrizio Munzi

Rank: New Member

Posts: 12

Join Date: November 3, 2011

Recent Posts

David H Nebinger:
Patrizio Munzi:
I've done some more tests and what I see is that the performances problem doesn't look to refer to the permission algorithm but to the hibernate object saving algorithm. Moreove even if I write on two different bean (I tried also two different bean of two different services) the performances are the same.
So looks like the writing serialization issue is on the low level I/F towards hibernate/DB not a service builder entities level.

Is this possible?


Invocation of an SB method actually involves a lot more than just the Hibernate save...

You're crossing a class loader boundary (to get from the servlet's class loader into the class loader of the portlet providing the service), so there is some serialization/deserialization going on there.

Eventually it will go to hibernate for persisting.

Hibernate is not always the best tool for database writing (this stands out when you're trying to do batch loading). Hibernate shines when it comes to many concurrent readers, not so much on concurrent writers (similar sort of issue).

You're going to want to look at your hibernate config, ensure that you're using ehcache correctly for your retrieves. You're going to want to look at your transaction management, as most of the SB code will use a transaction per call.

And finally you want to consider the calls that your many concurrent users are making. Creating a new image gallery folder, for example, is one of the heavy methods to pick from. It's not just affecting the database but it's also doing stuff in the repository. And for simulating concurrent users, concurrent users would not all be creating new image gallery folders at the same time (and probably shouldn't have permissions to do so as this is really an administrative function).

If you want to test something, test something the concurrent users would do. For Liferay, for example, they would choose to simulate posting forum messages as this is what the bulk of their concurrent users actually do.


1) I'm not using the image gallery folder test anymore and I've written a dummy service to get rid of all extra conplexity. At the moment my service only write a DB row per call. Isn't this like a user writing a msg in a message board? No extra processing!

2) I talked only about liferay hibernate save problem because I've run tests where I commented the line:
BatchSessionUtil.update(session, htUser, merge);
and performances boosted without saving my entries but keeping all the call stack till there.

3) I'm using standard liferay configuration, if you thing that tuning some parameters could help I'd be very keen to try. Any help on this??

Thanks