Liferay Portal Performance

Benchmark Study of Liferay Portal Enterprise Edition

Table of Contents
Executive Summary ................................................................................. 3 Test Scenarios ......................................................................................... 4 Benchmark Configuration and Methodology ................................................ 5 Environment Configuration .................................................................. 5 Methodology ...................................................................................... 6 Benchmark Results .................................................................................. 8 Transaction Centric Scenarios ............................................................. 8 Content Centric Scenarios ................................................................. 11 Collaboration Scenarios .................................................................... 14 Summary .............................................................................................. 20 Appendix A ............................................................................................ 21 Detailed Test Scenario Descriptions ......................................................... 21 Transaction Centric Scenarios ........................................................... 21 Informational/Content Centric Scenarios ............................................ 23 Collaboration Centric Scenarios ......................................................... 25

000 blog entries and 1.300 concurrent users on a single server with mean login times under half a second and maximum throughput of 79+ logins per second.000. The Liferay engineering team performed an intensive round of tuning and testing to demonstrate the scalability of Liferay Portal Enterprise Edition in a collection of use cases including infrastructure portal. Given sufficient database resources and efficient load balancing.000 concurrent users on a single Liferay Portal server with average transaction times under 50ms and 35% CPU utilization. and Liferay Service Partners in capacity planning.000 users in the database • 3. collaboration. To truly achieve “enterprise scale. 4. The portal solution has been named by Gartner as a leader in feature completeness and ROI among the vendors represented in the Gartner Magic Quadrant. 3.Liferay Por tal Pe r fo rm a n c e Executive Summary Liferay Portal is the leading open source enterprise portal solution.300 concurrent users at average transaction times of under 800ms. In collaboration and social networking scenarios. Liferay Portal can scale linearly as one adds additional servers to a cluster.000 comments The key findings of the study are: 1. Liferay Portal can support over 3.000 message forum threads and posts • 10.000.” this study was commissioned with: • 1. Liferay clients. As an infrastructure portal. Liferay Portal’s WCM scales to beyond 150.e. The goals of this study were to: • Determine the maximum number of concurrent users supportable by a single physical server across defined test cases • Determine if Liferay Portal provides linear scalability (i. and content management.000 communities and organizations • 100. 2. Liferay Portal Enterprise Edition is the commercial and long term supported edition of the Liferay Portal solution. we should double the number of concurrent users) • Provide statistics to help Liferay Global Services. 3 .000. each physical server supports over 1. if we double the number of portal application servers.

• Informational or content centric scenarios » Applies to publications (e. pay bills. » Mostly authenticated access. developer communities. Session times will vary in duration. and ecommerce deployments where a large number of users will login and perform transaction like online banking (bill payments.Liferay Por tal Pe r fo rm a n c e Test Scenarios The document utilizes the following conventions when discussing test cases and results: • Concurrent Users — Simultaneous transactions and operations like login.g. etc). newspapers and magazines). roughly 5:1 ratio between read and write transactions. • Total Users — Total number of users in the portal database that could be used as part of a test. • Collaboration centric scenarios » Applies to Facebook-like social networks. and post messages to forums. Based on this feedback. » Both anonymous and authenticated access to services provided by Liferay WCM. and e-government cases. browse content. airline and hotel booking. Each portal deployment is unique in its requirements and performance characteristics. online insurance applications. product marketing. Liferay collaborated with clients across a broad spectrum of industries to determine the scenarios that best modeled use cases for the product. insurance. » Frequent authenticated access with long user session times. and intranet environments. Liferay decided to classify the test cases into three categories: • Transaction centric scenarios » Applies to financial. A more detailed listing of the test cases can be found in Appendix A. 4 . » Relies upon collaboration tools like blogs and message boards. and etc.

Liferay opted to not inser t a firewall or a hardware load balancer into the benchmark environment. etc. Oracle. Oracle Identity. Application Tier — hosts Liferay supported application servers like Tomcat. IBM DB2. Postgres (please see LPEE support matrix for additional platforms) For simplicit y. Application Tier Web Tier Database Tier Application Server Apache Web Server Database Server Application Server Figure 1 . and IBM Websphere (please see LPEE support matrix for additional platforms) 3.Liferay Por tal Pe r fo rm a n c e Benchmark Configuration and Methodology Environment Configuration The benchmark environment conforms to deployment architecture best practices. rich-media.Benchmark conFiguration 5 . Sun Identity. Glassfish. 2. Oracle/BEA Weblogic. It consists of the following tiers: 1. Oracle AS. MS SQL. Also provides integration modules to single sign-on solutions like CA Netegrity. Web Server Tier — deliver static content elements like images. and other static files like style sheets. Database Tier — Database Tier – hosts Liferay supported database servers like MySQL. JBoss.

2. the injectors ramped up users at a rate of one user every 100 milliseconds until the maximum concurrent user load has been achieved.1. 12MB L2 cache (8 cores total) » 16GB memory » 4 x 146GB 15k RPM SCSI Network: » Gigabit network between all servers and test clients Software: » » » » » » Liferay Portal Enterprise Edition 5. Database Tier » 1 x Intel Core 2 Quad E5430 2.31 Community Server Apache HTTPD Server 2.13GHz CPU.0_12-b04) CentOS 5.18-92.66GHz CPU.22.el5 #1 SMP) MySQL 5.6. In all test scenarios. the following statistics were gathered: 6 . The benchmark data was gathered after an initial ramp up time of five minutes to initialize all application elements and warm up all injectors. As part of data gathering. Application Server » 2 x Intel Core 2 Quad E5430 2. Web Server » 1 x Intel Core 2 Duo E6405 2.2k RPM IDE 2.6.1.5 Sun Java 6 (1.3 The Grinder 3 load test client Methodology Liferay utilized The Grinder load testing tool and its distributed load injectors.Liferay Por tal Pe r fo rm a n c e Hardware platforms: 1.1. 12MB L2 cache (8 cores total) » 8GB memory » 2 x 146GB 10k RPM SCSI 3. 2MB L2 cache (2 cores total) » 4GB memory » 1 x 146GB 7.2 64-bit Linux (kernel 2.66GHz CPU.

a single application server was used to perform most tests. standard deviations. • JVM garbage collection information via Visual VM and garbage collector logs. Although the benchmark environment consisted of two application servers. and throughput from The Grinder console.Liferay Por tal Pe r fo rm a n c e • CPU statistics on web. and database servers. 7 . Once the tests determine the max performance of a single server. Liferay utilized the second application server to prove the linear scalability hypothesis. In theory. application. • Average transaction times. doubling the available hardware will double the maximum concurrent supportable user load.

we have a mean time (µ) of 162ms and 95% of the logins (2σ) below 600ms. we see CPU utilization at roughly 71% on the application server.400 2.000 to 3.800 2.2 76 79. we see 2σ increasing to over 1s.300 30 30 30 30 30 30 30 30 97.000 concurrent users. We first examine Liferay’s performance with simple content portlets on the page. At this inflection point.3 517 515 537 495 574 1044 1334 51 52. moving above the acceptable threshold. These portlets are extremely fast.200 concurrent users. The login and permission retrieval process is one of the most resource intensive processes within the portal.Liferay Por tal Pe r fo rm a n c e Benchmark Results Transaction Centric Scenarios Isolated Login The first of two transaction centric scenario focuses on the login process of Liferay Portal. Although the portal itself is at peak performance.500 users. The optimal performance point for this test scenario occurs somewhere between 3. the portal must retrieve user and security information from the database and calculate authorizations.800 3. At 3.1 36 44 50 58 63 71 78 81 taBle 1 – isolated login Figure 2 graphically illustrates the test scenario as we approach the optimum performance point. lending average rendering times of less than 10ms. Unfortunately. we could allocate a second JVM instance and delay the inflection point to roughly 3. Thus. This indicates we have excess capacity on the CPU.100 2. ConCurrent users Duration (min) μ(ms) σ(ms) 2σ (ms) throughput (tps) Cpu utilization (%) 1.2 199 197 199 177 206 367 452 186. overall CPU utilization remains at 78%.6 67. The mean time for login remains less than 200ms as we approach the performance inflection point. Liferay did not have sufficient time to test this hypothesis.9 119 121 139 141 162 310 430 44.200 3.6 59. At 3.200 users.000 3. 8 .700 2.4 70 74. Table 1 illustrates the performance observed during this test. At login.

000 users on a single application server.000 concurrent users) is roughly 74 logins per second. At 6.isolated login throughput Upon determining the maximum throughput. the portal appears to have a maximum throughput of roughly 80 transactions per second. The benchmark results showed that Liferay Portal was able to breach 6. Login Throughput 80 70 60 Trnasactions/sec 50 40 30 20 10 0 1800 2100 2400 2700 2800 3000 Concurrent Users Figure 3 .100 users. a second portal application server was deployed.Liferay Por tal Pe r fo rm a n c e Login Time 180 160 140 120 Time (ms) 100 80 60 40 20 0 1800 2100 2400 2700 2800 3000 Concurrent Users Figure 2 .mean login time In terms of throughput. the optimal throughput (at 3.100 concurrent users using two application servers. 9 . the transaction times remained similar to the times gathered at 3.

196 2. 600 users less than the previous login scenario.500 2.600 30 30 30 30 30 30 133 141 156 173 367 533 170 155 165 131 496 568 2. The hypothesis is that individual portlet performance will have impacts on the overall performance of the portal solution.5 196 239 2.1 65.159 2. The two seconds simulate the impact of integration with systems like Salesforce.165 2.3 55.6 49.400 concurrent users.120 2. we see that 95% (2σ) of the combined login and home page transactions consume 2.5 692 807 2.569 2.Liferay Por tal Pe r fo rm a n c e Login with Legacy Simulator This test scenario helps demonstrate the impact of adding a portlet that will sleep for two seconds.616.871 4.800 2. The statistics indicate a decrease in the maximum number of concurrent users prior to reaching the optimum performance point.com or interacting with a company’s enterprise service bus.4 51.3 186.login with simulator 10 .577 2. Login Time 3000 2500 2000 Time (ms) 1500 1000 500 0 1800 2000 2200 2400 2500 2600 Concurrent Users Figure 4 .180 39 47 45.606 3.3 66.400 concurrent users in this scenario.6 42 55 62 73 77 83 taBle 2 – login with simulator Figure 4 illustrates Liferay Portal approaching its optimal performance just above 2.2s.400 2.040 2.000 2.6 2.200 2.024 2. the portal reaches optimal throughput and performance at roughly 2. ConCurrent users login Duration time (min) μ(ms) login time σ(ms) Delay page μ(ms) Delay page σσ(ms) total μ(ms) total σ(ms) total 2σσ (ms) throughput (tps) Cpu (%) 1.060 2. At the inflection point.2 64.713 209 202 210. In this scenario.026 2.233 2.6s with a mean time of 2.487 2.327 45.

Total throughput appears to remain constant at roughly 3.000 users.000 user mark. This test confirms that individual portlets will have an impact on the performance of the overall portal solution. The tests show the WCM handling the load with ease. Content Centric Scenarios Anonymous Content During tests. At the 150. to achieve higher throughput. a second portal application server was deployed upon determining the inflection point. the benchmark environment’s network becomes a bottleneck as the gigabit network strains to keep up with the volume of requests.900 transactions per second. At 4.000 users browsing for content anonymously. login with simulator As with the first scenario.Liferay Por tal Pe r fo rm a n c e As expected with a longer delay on login.800 concurrent users using two application servers. Based on this statistic.400 users on a single application server. the transaction times remained similar to the times gathered at 2. As shown in Table 2. Since we have sufficient CPU resources. the 95% of the transactions (2σ) remains comfortably below 50ms while the system only consumes 34% of total processing power. 11 . using only 35% of a single server’s resources. Login Throughput 70 60 50 40 30 20 10 0 Transactions/sec 1800 2000 2200 2400 2500 2600 Concurrent Users Figure 5 . it appears we have reached the maximum throughput of a single JVM hosting Liferay Portal. Slower portlet transactions will decrease the maximum concurrent user load each physical server may support. at 150.throughput. the overall throughput of the system is lower.800 users. roughly about 65 transactions per second. Liferay Portal WCM was able to service over 150. we should instantiate a second JVM on the same physical server. The benchmark results showed that Liferay Portal was able to breach 4.

87 27.4 96.95 2.2 246 286.880 3. Thus.300 users.000 3.4 675.6 55. At 2.97 8.98 2.5 512 604 834 83.6 636.8s at 3.47 3. In this scenario.878 taBle 4 – known user Browsing For content 1 To simplify presentation of the performance statistics.38 3.936 2.9 119 121 139 141 389 450 655 44.970 22 25 28 32 taBle 3 – Browsing For content anonymously Due to the test reaching maximum network bandwidth.000 100.300 30 30 30 30 30 30 30 30 97. Although the Portal does have resources to push to 3. ConCurrent users Duration (min) login time μ(ms) login time σ(ms) Content page1 μ(ms) Content page σ(ms) total μ(ms) total σ(ms) total 2σ(ms) throughput (tps) Cpu (%) 1.2 199 197 199 177 391 433 734 22.96 122.800 2.4 31 35 43 55 73 81 86 91 260. As we can see from the data. 95% of the transaction times are under 850ms.200 2.2 6.5 88. we aggregated the time for accessing 20 different content pages and report the aggregate as a single Content page access time.96 12.3 25.6 131 194 233 288 120.3 220.960 3.4 295.2 133.800 concurrent users. the WCM will leverage the Portal’s authentication and authorization system to ensure users have the appropriate permissions prior to viewing content.4 107.600 2. the performance inflection point for this scenario appears to be around 2.65 131. In Table 4.000 50.4 76.27 42.2 144.6 194.5 1. Authenticated Content The authenticated content scenario shows different performance characteristics than the anonymous content scenario.Liferay Por tal Pe r fo rm a n c e ConCurrent users Duration (min) μ(ms) σ(ms) 2σ(ms) throughput (tps) Cpu (%) 25.800 3.4 19.3 79.76 19. 12 .82 1. driving the 95% transaction time to over 2. the performance characteristics become unstable.200 3.300 concurrent resources.2 95.800 users.6 785.000 150. we find the statistics from this test.5 308 585 666 1022 836.5 123 154 179 39 47 63. Liferay deemed it unnecessary to proceed with allocating a second physical server to test linear scalability.682 1.000 30 30 30 30 0.42 129. the performance characteristics of this scenario are very similar to that of the login test scenarios.400 2.4 33.4 154.930 3.

Authenticated Content Access 250 200 Time (ms) 150 100 50 0 1800 2200 2400 2600 2800 Concurrent Users Figure 6 . in the authenticated content access. However. Liferay Portal scales linearly. 13 . Throughput 140 112 Transactions/sec 84 56 28 0 1800 2200 2400 2600 2800 Concurrent Users Figure 7 .Liferay Por tal Pe r fo rm a n c e Figure 6 illustrates that the best performance point for the Portal in this scenario is at 2. this test case has higher throughput than the login test due to the faster transaction times for content browsing.800 concurrent users. doubling the maximum concurrent user threshold when another physical server was added to the cluster.authenticated content Browsing The throughput of this test case displays significant similarities to the throughput for the login test cases.authenticated Browsing throughput As with the login test case.

3 978 914.Liferay Por tal Pe r fo rm a n c e Collaboration Scenarios Message Boards Due to the complexity of the scenario.966 5.488 1.000 1.6 104 102 109 117 143 139 655 889 59.3 154 104 107 80.1 43.162 1.899 435 769.100 1.200 1. including login.300 30 30 30 30 30 30 30 30 30 96.200 users.990 1.6 3. we see the breakdown for each individual transaction within the test.980 taBle 5 – message Boards part 1 ConCurrent users post threaD μ(ms) post threaD σ(ms) reply threaD μ(ms) reply threaD σ(ms) total μ(ms) total σ(ms) total 2σ(ms) Cpu (%) 500 600 700 800 900 1.3 155 121 113 95.287 7.676.120 65.311.619 24 28 31 38 48 56 63 73 82 taBle 6 – message Boards part 2 14 .2 4.427 67.327 1.100 concurrent users.300 81 83.6 1.7 137 156 235 3.100 1.971.5 233 180 164 166 253 252 341 4.5 118 242 249 443 472 574 5.000 1.679 2.360 1.050 96.6 1.450 42.138. browsing.093 26.6 2.929 3.570 117 122 123 136 149 192 180 202 1.506. At 1. In Table 5 and 6. we begin to see performance degradation with further reductions at 1.180 47.482 1.1 38. 95% of the transactions remain under 1s when we have roughly 1.241 14.8 93.9 130 181 193 1.5 111 217 223 370 358 507 4.101.1 672.283 3.300 users. and posting.740 1. ConCurrent users Duration (min) login time μ(ms) login time σ(ms) Browse Category μ(ms) Browse Category σ(ms) Browse threaD μ(ms) Browse threaD σ(ms) Browse posts μ(ms) Browse posts σ(ms) 500 600 700 800 900 1. In almost every case.200 1.6 86 110 121 168 174 254 3.3 135 100 155 260 243 6.210 188 201 202 229 264 340 332 490 2.710 328 334 342 392 441 621 593 866 4.150 291 294 307 351 390 526 511 774 3.8 2. we have opted to start with lower initial concurrent user counts in our hunt for the performance inflection point.6 1.210 124 90.

as we can see from Figure 9. View.500 users on a single physical server.message Board total µ time Although we have reached the performance inflection point for a single JVM. the statistics indicates that to fully utilize the CPU. we would need to either implement virtualization or activate a second JVM on the same hardware. we have not fully utilized 100% of the CPU on this server. Either technique may allow us to increase the optimal performance point to around 1.message Board cpu utilization 15 .100 concurrent users for a single JVM. Unfortunately. Post. we did not have sufficient time to test this hypothesis for message boards. CPU Utilization 70 60 50 CPU % 40 30 20 10 0 500 600 700 800 900 1000 1100 Concurrent Users Figure 9 .Liferay Por tal Pe r fo rm a n c e Figure 8 shows us the optimal performance point at 1. Thus. and Reply Total Time 2500 2000 Time (ms) 1500 1000 500 0 500 600 700 800 900 1000 1100 Concurrent Users Figure 8 .

577 taBle 8 – Blogs part 2 212.200 74 79. we observed total mean transaction times (µ) at 865ms with 95% of all transactions consuming roughly 1.Liferay Por tal Pe r fo rm a n c e As with previous tests. The blogging components in Liferay reuse many of the components of the Message Boards. to post comments on a blog and to post a new blog entry.2 244.3 66.9 114 103 120 539 57 39 35 44. Individual transactions are substantially lower.1 620.9 1.5 79.065. Blogging As with the message board scenarios.7 974. Thus.100 1.3 577.9 10.1 41. In the case of posting a new entry. at 1.3 65 69.3 222. the statistics point to a performance inflection point of roughly 1.1 117 676 32 44 42.3 39 45.970 55 62 59.9 1.8 143 2.134.6 2. the statistics report 95% of the transaction at about 361ms and 568ms respectively.100 concurrent users we have 282ms + 2 * 143ms = 568ms. we chose to start the blogging scenarios with lower concurrent user counts due to its complexity.910 112 121 132 144 150 162 199 693 45 44 48.8 542.2 43 47.950. As reported in Tables 8 and 9.95s.170 143 166 174 187 199 233 282 927 44 53 57 63 56 75. At 1.2 147 742 34.1 77 83.1 530.5 107 2. we have 147ms + 2*107ms = 361ms 16 .090 taBle 7 – Blogs part 1 ConCurrent users post Comment μ(ms) post Comment σ(ms) total μ(ms) total σ(ms) total 2σ(ms) Cpu (%) 500 600 700 800 900 1.3 34 55 43.100 1.2 ConCurrent users Duration (min) login time μ(ms) login time σ(ms) View summaries μ(ms) View summaries σ(ms) View entry μ(ms) View entry σ(ms) post new entry μ(ms) post new entry σ(ms) 500 600 700 800 900 1.7 1.240 884. For instance.3 283. For posting comments. Liferay confirmed that the maximum user threshold doubled when doubling the number of physical servers.234.2 88 97.3 1.9 1.3 72.2 953. the performance and scalability of the two features are quite similar.3 667.8 24.4 257.100 concurrent users.100 concurrent users.9 58 55.000 1.000 1.3 865 3.200 30 30 30 30 30 30 30 30 76 83 88 97.9 89.057 22 26 29 34 39 45 55 58 2 The 95 percentile bracket is calculated as the mean time + 2 standard deviations away or (µ + 2*σ).1 124 1.2 48 50.1 221.100 460 511.

View.6s at 1. Liferay Portal has only utilized little more than 50% of the CPU. there are sufficient resources to allocate another JVM to help improve maximum capacity. we see total mean transaction time moving to 3. CPU Utilization 60 50 40 CPU % 30 20 10 0 500 600 700 800 900 1000 1100 Concurrent Users Figure 11 . Blog.Blogging µ transaction time Although the statistics point to 1. Thus.200 users.100 as the optimal threshold. from less than 1s at 1.100 concurrent users.100 concurrent users. At 1. From the Table 8. the CPU utilization of the server remains relatively low.Liferay Por tal Pe r fo rm a n c e Figure 10 depicts the total mean transaction time as the system approaches the optimal performance point. and Comment Total Time 1000 800 600 400 200 0 500 600 700 800 900 1000 1100 Concurrent Users Figure 10 .Blogging cpu utilization 17 .

186 3.300 concurrent users.389 1. Liferay allocated a second JVM to improve utilization. individual transaction times remain quite low.400 30 30 30 174 201 376 357 351 496 274 323 518 270 254 419 136 171 301 167 196 306 369 459 728 293 346 552 taBle 9 – Blogging. we can successfully exceed 1.300 concurrent users with acceptable performance before reaching almost full CPU utilization (94%).451 2. In Tables 9 and 10.930 4. we see the results of benchmarking beyond 1. At 1.3s.200 1. In fact.286 6. Although the total times seem high.400 concurrent users that we begin to performance instabilities caused by nearly 100% CPU utilization.4s and 95% times of 4. two-JVm part 2 The statistics show that by allocating two JVMs onto the same physical hardware. ConCurrent users Duration (min) login time μ(ms) login time σ(ms) View summaries μ(ms) View summaries σ(ms) View entry μ(ms) View entry σ(ms) post new entry μ(ms) post new entry σ(ms) 1.345 1.100 concurrent users.152 1.200 1.300 1. 18 .Liferay Por tal Pe r fo rm a n c e Upon noticing excess capacity on the server. mostly under 1s: • Viewing list of blog entries: 201ms (µ) and 903ms (95th percentile) • Viewing details of a specific blog entry: 323ms (µ) and 831ms (95th percentile) • Adding new blog entries: 459ms (µ) and 1151ms (95th percentile) • Commenting on blogs: 230ms (µ) and 838ms (95th percentile) It is at 1.384 2.100 concurrent users by using two JVMs hosting Liferay Portal on the same physical hardware.400 199 230 422 302 304 413 1. we will see mean total times of 1.300 1. two-JVm part 1 ConCurrent users post Comment μ(ms) post Comment σ(ms) totalμ(ms) total σ(ms) total 2σ(ms) Cpu (%) 1.717 62 74 93 taBle 10 – Blogging. we can push Liferay Portal to successfully host more than 1.

and Comment Total Time 2500 2000 Tme (ms) 1500 1000 500 Optimal performance inflection point at ~1300 users 0 1200 1300 1400 Concurrent Users Figure 12 . two-JVm CPU Utilization 100 90 80 70 CPU (%) 60 50 40 30 20 10 0 1200 1300 1400 Concurrent Users Figure 13 .Blogging µ transaction time.Liferay Por tal Pe r fo rm a n c e View. Blog.Blogging cpu utilization. two-JVm 19 .

we must continue to monitor and improve the portal’s performance. commissioned this benchmark study to demonstrate the performance and scalability of Liferay Portal and to provide statistics for future capacity planning. blogs. a content portal.1 SE. a collaboration portal. The Liferay engineering team will introduce these enhancements to the Liferay Portal 5. This approach ensures that Liferay’s EE subscription customers realize the benefits of the engineering team’s testing immediately while also providing similar benefits to Liferay’s open source community in a future standard edition release. forums.1 EE and not to the 5. the benchmarks apply to Liferay Portal 5. documents.Liferay Por tal Pe r fo rm a n c e Summary Liferay engineering.3 SE in Q4 2009. Based on the results of this study. especially those use cases that rely heavily upon security and permission checking. • The performance characteristics of Liferay Portal in a cloud environment like Amazon EC2 Acknowledgements Liferay would like to thank the Liferay customer network for their contributions in helping develop performance test cases.0 capabilities to the enterprise.0 initiatives. This feature will be introduced late 2009 and should imply significant performance gains portal wide. 20 . Due to the many performance enhancements introduced in the enterprise edition. Specific areas to examine include: • The impact to portal performance with the introduction of collaborative filtering for portal assets like web content. Liferay determined that the Liferay Portal platform provides an extremely scalable and high performance environment for building an infrastructure portal. Liferay would also like to thank the Liferay Portal Open Source Community for their important contributions in performing independent benchmarking and testing. As Liferay introduces new features to Enterprise 2. and wiki articles • The impact to portal performance with the introduction of “bitwise” security authorizations. With its immense flexibility and now proven performance and scalability. Liferay believes the Liferay Portal platform is uniquely positioned to help bring Web 2. and any combination of these capabilities. Next Steps Performance management is never ending. in collaboration with various clients and partners.

Test for 30 minutes with 2.800 test threads.000 user IDs and execute login 3. 2. Test for 30 minutes with 2.000 test threads. Arrive at login page. Create a site with a page containing content portlets TEST SCRIPT: 1.000 unique users 2. sleep for 30 seconds to simulate user reading information 4. testing will execute the following iterations: 1.400 test threads. sleep for five seconds to simulate user input credentials 2. 3. Test for 30 minutes with 2.700 test threads. The login process is the most expensive transaction within Liferay Portal as it requires the portal to retrieve access control lists (ACL) and security authorizations from the database. Load database with 1. Randomly select from 1. 5. CONFIGURATION: 1. Arrive at a community’s home page. This test is to explore how Liferay Portal EE will perform without any external influence. Test for 30 minutes with 2. 6. 21 . Test for 30 minutes with 3. 4.000. Portal performance often depends upon the portlets deployed.100 test threads.000. Test for 30 minutes with 1.Liferay Por tal Pe r fo rm a n c e Appendix A Detailed Test Scenario Descriptions Transaction Centric Scenarios Authenticated User Access DESCRIPTION: This test is designed to test the total number of concurrent logins processed by Liferay Portal per second. Logout TEST PROCEDURE: At minimum.800 test threads.

Test for 30 minutes with 2. Test for 30 minutes with 3. Test for 30 minutes with 2. 4.300 test threads. System Integration Simulation DESCRIPTION: This test will demonstrate the impact of third party portlets on Liferay Portal performance. 5. pending transfers. Arrive at login page.000 unique users 2. Logout TEST PROCEDURE: At minimum. we will examine how the portlet performance will impact Liferay Portal performance. Test for 30 minutes with 2. Arrive at the community page with the two-second delay portlets. Total delay time of two seconds TEST SCRIPT: 1. Load database with 1. 3. 8. each with one-second delay to simulate retrieval of account balances. Test for 30 minutes with 2.600 test threads. Testing will proceed until login transaction times exceed 500ms per login.400 test threads. Summary page with two portlets. Randomly select from 1. Testing will proceed until mean login transaction times exceed 500ms per login.500 test threads.200 test threads.800 test threads. Configure individual user’s home page three pages: a. 6.000 test threads.Liferay Por tal Pe r fo rm a n c e 7.000. b. 22 . Test for 30 minutes with 3. 2. CONFIGURATION: 1. wait for five seconds 2. testing will execute the following iterations: 1.200 test threads. Test for 30 minutes with 1. Test for 30 minutes with 2.000 user IDs and execute login 3. wait for 30 seconds 4. and pending payments. By using a portlet that will sleep for a configurable time (two seconds).000.

Liferay Por tal Pe r fo rm a n c e Informational/Content Centric Scenarios Anonymous Content Browsing DESCRIPTION: This test simulates the system load for unauthenticated users browsing for content on an informational site. Arrive at Home page. testing will execute the following iterations: 1.000 unique content articles 2. Partners page e. 3.000 test threads.000 test threads. wait for 20 seconds to simulate reading 2. TEST PROCEDURE: At minimum.000 test threads. Home page b. Test for 30 minutes with 50. Arrive at Services page. wait for 20 seconds to simulate reading 3. CONFIGURATION: 1. place four content portlets on each page. 23 . Products page c. Testing will proceed until content browsing times exceed two seconds per page. wait for 20 seconds to simulate reading 6. 4. randomly selecting content from content store. Arrive at About Us page. Services page d. wait for 20 seconds to simulate reading 5. Arrive at Products page. a. Test for 30 minutes with 25. Test for 30 minutes with 100. Test for 30 minutes with 150. Arrive at Partners page. wait for 20 seconds to simulate reading 4. Repeat 1 to 5 for four iterations. Load database with 5. 2. About Us page TEST SCRIPT: 1. Create five pages.000 test threads.

CONFIGURATION: 1. Randomly select from 1. Arrive at Business page. Test for 30 minutes with 2. Arrive at Local News page. place four content portlets on each page. Test for 30 minutes with 2.000 unique users 3.Liferay Por tal Pe r fo rm a n c e Authenticated Content Browsing DESCRIPTION: This test simulates the system load for unauthenticated and authenticated users browsing for content on a news site. Arrive at Home page. Home page b. 3. Create five pages. Business page c. 24 .000 user IDs and execute login 5. wait for 20 seconds to simulate reading 6. testing will execute the following iterations: 1.000 unique content articles 2. 2. wait for 20 seconds to simulate reading 4. Arrive at World page.400 test threads. Sports page TEST SCRIPT: 1. Arrive at Sports page. Automatically forward to previously visited site (World page).000. World page d. wait for 20 seconds to simulate reading TEST PROCEDURE: At minimum. Test for 30 minutes with 1. similar to a magazine or newspaper site. a. wait for 20 seconds to simulate reading 7. randomly selecting content from content store. Local News page e.000. Load database with 5. Load database with 1.200 test threads.800 test threads. wait for 20 seconds to simulate reading 2. wait for 20 seconds to simulate reading 3.

000.600 test threads.200 test threads.000 unique users 3. 6. wait 30 seconds to simulate composition 25 . Test for 30 minutes with 3.Liferay Por tal Pe r fo rm a n c e 4. CONFIGURATION: 1. Test for 30 minutes with 3.000 message posts split into six categories.000 test threads. wait for 15 seconds 2. Randomly select from 1. 10% of user threads will reply to an existing thread.300 test threads. Select a thread at random and view the replies to the thread. Create a page with the Liferay Message Board portlet TEST SCRIPT: 1. Select a category at random and view the posts. Repeat 1 to 3 twice 6.000. Test for 30 minutes with 2. wait for 30 seconds to simulate reading 3. Collaboration Centric Scenarios Message Forums DESCRIPTION: This scenario tests the scalability of Liferay’s Message Board capabilities. replying. wait for 30 seconds to simulate reading 4. Test for 30 minutes with 2. Testing will proceed until login transaction times exceed two seconds per page. 5. Test for 30 minutes with 3. 2. Load database with 3. Arrive at Home page.000 user IDs and execute login 5. wait 30 seconds to simulate composition 7.000. and posting new threads. including browsing.800 test threads. 7. 8. 10% of user threads will post a new thread in a random category. Load database with 1.

5. Load database with 10. Load database with three Liferay communities 3.000 test threads. Select a blog entry to read its details and wait for 30 seconds 3.000.000 blogs per community. 4. 6. 8. 3. Test for 30 minutes with 700 test threads.300 test threads. Create a page in each community with the Liferay Blogs and Blogs Aggregator portlet TEST SCRIPT: 1. CONFIGURATION: 1.000. total of 30. Randomly select a community’s home page and wait for 15 seconds 2. Test for 30 minutes with 1. Test for 30 minutes with 900 test threads. 9. Select a blog entry to read its details and wait for 30 seconds 26 . Test for 30 minutes with 1. commenting. Load database with 1. Randomly select from 1. Test for 30 minutes with 1. Test for 30 minutes with 500 test threads. Test for 30 minutes with 1.000 user IDs and execute login 4.100 test threads. and creating new blog posts. including browsing. Testing will proceed until transaction times exceed two seconds per page.000 unique users 2.Liferay Por tal Pe r fo rm a n c e TEST PROCEDURE: At minimum. 2. Randomly select another community’s home page and wait for 15 seconds 5. Test for 30 minutes with 800 test threads.000 entries 4.200 test threads. Blogging DESCRIPTION: This scenario tests the scalability of Liferay’s Blog and Blog Aggregation capabilities. testing will execute the following iterations: 1. 7. Test for 30 minutes with 600 test threads.

100 test threads. 7. Test for 30 minutes with 1. Test for 30 minutes with 700 test threads.Liferay Por tal Pe r fo rm a n c e 6. Test for 30 minutes with 1. 8. Test for 30 minutes with 800 test threads.000 test threads. Testing will proceed until login transaction times exceed two seconds transaction. Test for 30 minutes with 1. 1% of user threads will comment on a blog post TEST PROCEDURE: At minimum. Test for 30 minutes with 900 test threads. 5. Test for 30 minutes with 600 test threads. 5% of user threads will post a blog post in a random community 7. 3. 2. Test for 30 minutes with 1. 27 .300 test threads.200 test threads. 6. 4. testing will execute the following iterations: 1. Test for 30 minutes with 500 test threads. 9.