Want to make Liferay even faster?
June 8, 2011 2 Comments
If your answer is yes then vote for issue LPS-14055. As you can see Asset Publisher makes many queries to underlying database. Those are very slow queries like count(*) (needed for pager element displayed below assets lists). If you are building big portal with many AP on every page (main article list, dynamic coin slider, recommended articles etc.) you will face lots of such queries. You can of course add additional servers to database layer but that is not a solution. Only thing that will help you is optimizing AP. First thing – in every query AP uses now() for checking expiration date. That lowers database abiliti to cache queries as with every second it gets new query. Second thing is cache – those queries are not made using hibernate. Third thing is speed – why ask database using very slow IN elements in queries if you can use JOINS. There is even better solution – use LUCENE for those slooooooow COUNT queries.
So if you want your Lfierays to become even faster vote for that particular issue now.
eo Networks about Liferay 
It seems it has been fixed by adding some indexes to DB… 😉
Indexes are just a minor help. With every query Asset Publisher uses NOW(). That means that query is changed every second and it can not be cached in database system. That is bad behavior especially that user can only set hour and minute in Expiration date. So there is no need to check that in interval as small as second.
Also construction of queries made by Asset Publisher is poor – to many IN elements and sub-queries. By design this is very slow.