|Too low performance of legacy WAR-application [message #1005929]
||Tue, 29 January 2013 05:38
| Anton Lem
Registered: January 2013
Good day, everybody!|
To test a possibility to use Virgo in my development of a mass network enterprise system in couple with Liferay portal I've firstly deployed Liferay portal like one all-included WAR-file to Virgo (like the first step of the migration process, described in the documentation). Everything is working properly and developers have done a really great work. But performance of this solution has turned out more than 4 times slower than the original installation of Liferay to Tomcat.
I clearly understand, that OSGi and Blueprint apply an additional workload on the system resources and the WAR-deployment works in some kind of emulation-mode, not native working mode of Virgo. But I am not ready for that scale of overloads. I guess, if you describe the war-deployment as the first level of the migration process of a real existing application, then most of real robust legacy applications have to work properly in the war-mode and with an acceptable performance. In my case this is very far from reality, I can't physically use Virgo in a production system.
To repeat my experiment you should:
1) Increase -Xmx option in the virgo/bin/dmk script no less than 1024m.
2) Download ROOT.war [sourceforge.net/projects/liferayforvirgo/files/Liferay-6.1.1/WAR/ROOT.war/download] (187Mb), drop it into the pickup directory and start(it will take about 8-10min). Please be noted, that a Virgo installation by default contains in the pickup directory the splash screen web-bundle "org.eclipse.virgo.apps.splash_3.6.0.RELEASE.jar" which is installed into the root context "/" and has to be deleted to avoid a conflict with Liferay.
3) Open in your browser vigro-host/:virgo-port (it will probably take several minutes)
4) Don't change anything and click "Finish configuration". In the Virgo parent directory will be created 3 directory: data, logs and deploy,- and "portal-setup-wizard.properties" file. You may delete them after the test
5) Read "Your configuration was saved successfully." and click "Go To My Portal"
7) Set any new password, but won't forget it.
8) Type any answer for the reminder query (no matter what, for example random chars), then click "Save"
9) Download and install iMacros (if already have not) [www.iopus.com/imacros/firefox/] for Firefox or [www.iopus.com/download/imacros-ie/] for IE
10) Download [sourceforge.net/projects/liferayforvirgo/files/Liferay-6.1.1/misc/check-LR.iim/download] a simple macros for testing and drop it into the "My Documents\iMacros\Macros" directory (for Linux look at options of iMacros, where it places its scripts)
11) Start the script and measure CPU time of the java process by some Advanced Task Manager or same system utility (I used DameWare NT Utilities, just because it already installed)
This script simply sequentially clicks all control panel menu items of Liferay. During this Liferay lazy initializes almost every its libraries, frameworks and subsystems and caches many answers and results. That is why the first pass we must omit and measure since the second pass of test (simply restart test)
In my system Windows XP x32 AMD Phenom X3 2,91GHz, RAM 3,5Gb the original installation of Liferay for Tomcat completes this test using near 44s of CPU time. Liferay single WAR for Virgo takes about 187s and uses twice more memory. (about 968Mb instead of 420Mb of the original installation). I was ready for additional workload of resources for OSGi and Blueprint, but that kind of values is not acceptable at all. There is not enough powerful CPU on market to process my application with acceptable performance on Virgo platform. On the other hand, Liferay successfully is being launched on other application servers (JBoss, Glassfish, Geronimo and etc). That is why I guess this is a Virgo performance problem.
I understand what this is more comfortable for developers to test some trivial application provided with source code, but... I am sure there is already written hundreds of thousands lines of synthetic tests and trivial debug applications to test Virgo. But all this "comfortable" tests can't replace testing and profiling of Virgo with real existing application, even if it has to be tested in uncomfortable "black box" mode. Liferay, as I guess, is a perfect candidate for Virgo testing as it is: robust, famous, wide-spread, mature, very complex, massive but fast enough. Moreover Liferay is open source and you can in the most cases take a source and modify it for debug purposes as you wish.
Finally, drawing conclusions from the aforesaid:
1) Developers could profile my test application, trying to separate a concrete source of the performance problem. It might be an easy-to-fix incompatibility problem of one of Liferay components with the Virgo platform. I guess, it will be very useful for a further Virgo development and popularization to port such a serious product like Liferay to Virgo
2) It will be very nice to do something with Virgo performance. As I found out this is a global Virgo problem, not only for WAR-deployment
3) In any case it is very necessary to modify the product documentation to notify developers about a possible performance trap to avoid some kind of useless spending (time, money, nerves and etc.)
Thanks a lot guys!
You are doing a great job!
Powered by FUDForum
. Page generated in 0.02000 seconds