This page last changed on Jun 05, 2009 by pfragemann.

Confluence 3.0 has significant performance improvements over Confluence 2.10 and earlier versions. This page explains the performance characteristics of Confluence 3.0 and shows the improvements that were made when compared to its predecessor Confluence 2.10. In brief, compared to version 2.10, Confluence 3.0 response times in Standalone mode are down by 30% to 40%, and response times in a cluster are down by 50%. In other words, the clustered version of Confluence 3.0 is now twice as fast as before. Confluence also scales a lot better than before: More or faster CPU's are better utilised with Confluence 3.0 than they were with 2.10 and earlier versions.

1 Specific performance improvements

We have fixed a few bottlenecks that were so specific that you might have encountered them while analysing logfiles and thread dumps. Even if you did not see them, they might have been slowing your system down, depending on your use-case.

  • Rebuilding the search index is significantly faster, up to factor 2. In our performance testing, a sample set of 20,000 pages that took 30 minutes using Confluence 2.10 now just takes 16 minutes in Confluence 3.0.
  • Improved Database Queries
    • CONF-14488 : Added composite database index to SpacePermissions table. This will speed up installations with many page or space restrictions
    • CONF-14422 : Now, only the most recent version of an attachment is loaded when retrieving it for the first time. This had slowed down pages (and the dashboard) when an attachment had hundreds or thousands of revisions
    • CONF-14273 : Reduced overall DB load when rendering pages, which can help overall performance in case the database server was under high load already
  • Caching Enhancements
    • CONF-12894 : Improved resource caching to improve HTTPS/SSL speed. This will make the screen render faster when you are using HTTPS.
    • CONF-8034 : Now serving caching headers for attachments to improve user interface responsiveness: Attachments (this includes user avatars) will not be downloaded again by the browser, leading to faster page loads
  • Others:
    • Viewing PDF files through the office connector will use less memory and therefore significantly reduce garbage collection, which has caused some systems to perform a lot slower than needed
    • USGTRK-37 A bug was fixed in the usage statistics plugin that enables it to work smarter. It is still a plugin that is not made for high load so we suggest you disable it on high load scenarios

2 General performance improvements

We have been improving Confluence response time and scalability by implementing small improvements across the board. They are too many and too small to be presented individually, so we will use the results of our general performance-test to demonstrate the effect.

In our general Confluence performance tests, we execute a standardised set of commonly-used functions that simulates the activity of concurrent users. We base this profile on the actual usage patterns of our public Confluence installation, a rather large and active instance. To cater for irregular usage spike, we increase the load by factor 10. On average, this load test performs 10 to 15 Confluence requests per second. Most customer installations do not even get close to these numbers during normal operation. Under normal (low) load, the response times are actually a lot better than what we present here. But we prefer to use this medium load scenario because it simulates cases which may occur infrequently, and in which Confluence still needs to perform reasonably well. In addition to this scenario, we defined two additional, more extreme scenarios that perform the same requests, but at 20 to 35 requests per second to simulate an even higher load.

How to read and understand the statistics

Please note that we use the term "request" for anything that requests or posts data to Confluence. So viewing a Confluence page is a request, performing a search is a request, posting a comment is a request, and also using the quick navigation drop-down performs requests.

The data table

Each row in the table represents one use case. All use cases are run in parallel for 30 minutes, with a 5 minute ramp-up period.

  • Samplers: The first column is the name of the requests performed in this scenario, like reading pages, commenting pages, or performing searches.
  • 95% Percentile: This is the time (in milliseconds) by which 95% of all requests of this scenario have completed. This is not an average value, you rather can think of it as a "how long the slowest requests (except the very worst 5% cases) take" - scenario.
  • Average: the third column shows the average response time of the requests in this scenario - the lower the better.

The most important use-cases are the following:

  • View Page: This loads one out of hundreds of different Confluence pages. Some are short, others are long. Some have many images, others have many comments. Some have many macros, others do not. The pages are accessed through their full URL, as if someone had clicked a link within the application or a bookmark.
  • Search Site: A search across the whole system.
  • Quick Nav: This simulates typing a character into the search field and getting back suggestions in real time. This is one of the most popular and time-critical operations. Therefore, this operation needs to be very fast.
  • Dashboard: Simulates visiting the Confluence dashboard.
  • Edit Page: This saves a page back to Confluence, and notifies all people who are watching this page.
The graph

The chart shows how many concurrent requests per second are being processed. The blue line indicates the moving average per second, and they green lines indicate variation. The blue line is not constant, since the pages and operations requested are extremely different in their CPU usage: A short page with no comments will render faster than a long page with many macros and comments, which in turn, will render faster than a page-edit that triggers many notifications. These differences in requests result in different CPU loads over time.

The more stable the blue average line is, the more consistent the user experience. The higher the line is, the more users can access and use Confluence simultaneously.

Applying the numbers to your company's usage patterns

The notes on this page geared at showing the performance differences between 2.10 and 3.0, using the same tests we used to test Confluence 2.10.

Hardware specification

All tests were conducted on two to four servers, each of which had the following specifications:

Name
Value
Server model
Dell 2950
CPU type
Intel(R) Xeon(R) CPU E5405 @ 2.00GHz (4 Cores)
CPUs per server
1 or 2, depending on test. See test details
RAM
32Gb (but just 2Gb are used for the JVMs, and the database uses 3Gb)
Disks
2 x 15K, 72Gb SAS
Network
1Gbps
Webserver
Tomcat 6, Java 6
Database
Postgres 8.2.4

When testing the Confluence Standalone version, one server acts as the application server and one as the database server, which is the setup we recommend to customers to enable high performance. A third server is used to generate the load, using JMeter. In the cluster, we use two application servers and one database server. In the cluster configuration we use the Pound load balancer, which runs on the same (fourth) server as the load generator JMeter. We do not use any webserver or caching proxy for our tests, and we cannot make any recommendations about which one to use. We want to measure the raw performance of the application server and suggest that you use the webservers/proxies with which you are most familiar.

Software and Settings

The JVM settings we used were -XX:MaxPermSize=192m -Xmx2000m -XX:+PrintGCTimeStamps -verbosegc -XX:+PrintGCDetails -XX:+PrintTenuringDistribution -XX:NewSize=384m -XX:SurvivorRatio=2 -XX:+UseParallelGC -XX:+UseParallelOldGC.

The usage tracking plugin was disabled during these tests because it is known to have performance issues and we recommend that it be turned off in high load deployments.

Confluence standalone

Confluence is most frequently installed on one physical machine. Unless you know you are using (or are planning to use) a cluster, then this section is for you.

Confluence 3.0 Standalone has significantly better performance characteristics than Confluence 2.10 Standalone. We compare three load scenarios and give the details below.

Medium Load scenario, Standalone, 1 CPU

We define Medium Load as requesting roughly 15 requests per second from the loadtest. Most customers with smaller user bases never get even close to this usage, so they will experience a lot faster response times than what you can see below. But occasionally even customers with less than 1000 active users might experience spikes in usage, so we chose 15 requests per second as our medium load scenario.

We are using modest hardware (see above) with just one Xeon CPU with 4 cores, since we assume this is what a medium sized company would be using.

Confluence 2.10 vs Confluence 3.0 response times
Scenario Average time in 2.10 Average time in 3.0 Improvement 95 percent in 2.10 95 percent in 3.0 Improvement
Browse Label 1619ms 1129ms 43% 3979ms 2387ms 66%
Commentor submit comment 306ms 338ms -9% 805ms 794ms 1%
Commentor view commented page 737ms 628ms 17% 3386ms 1783ms 89%
Commentor view page 989ms 707ms 39% 4133ms 2168ms 90%
Creator add page 402ms 211ms 90% 765ms 391ms 95%
Creator submit new page 525ms 387ms 35% 1161ms 882ms 31%
Creator view page 256ms 233ms 9% 704ms 501ms 40%
Dashboard 554ms 382ms 44% 1685ms 634ms 165%
Editor display page 520ms 417ms 24% 1881ms 1065ms 76%
Edit Page 332ms 250ms 32% 831ms 620ms 34%
Editor submit edit 1199ms 961ms 24% 3949ms 3459ms 14%
Go to log in page 274ms 456ms -39% 486ms 2795ms -82%
Log In 342ms 333ms 2% 774ms 480ms 61%
Quick Navigation Search 134ms 57ms 133% 597ms 110ms 439%
Reader Not Found 551ms 369ms 49% 1266ms 615ms 105%
Reader RSS Blogpost Atom 170ms 59ms 184% 637ms 67ms 838%
Reader RSS Blogpost RSS2 206ms 95ms 116% 754ms 97ms 675%
Reader RSS Comment Atom 203ms 126ms 60% 929ms 481ms 92%
Reader RSS Comment RSS2 369ms 151ms 143% 1602ms 477ms 235%
Reader RSS Page Atom 628ms 513ms 22% 2725ms 2147ms 26%
Reader RSS Page RSS2 800ms 547ms 46% 3381ms 2196ms 53%
View Page 890ms 584ms 52% 3259ms 1854ms 75%
Reader for Space Page 904ms 677ms 33% 2219ms 1566ms 41%
Search Site 505ms 340ms 48% 2006ms 598ms 235%
Confluence 2.10 throughput

Confuence 3.0 throughput

Medium Load comparison between 2.10 and 3.0 in standalone mode

The most important scenario ("View Page") used to take about 900ms in Confluence 2.10, but in 3.0 it is down to 600ms, which is a performance improvement of about 50%. Almost all other scenarios have improved as well, some even by more than 100% (e.g. more than twice as fast). The throughput in this scenario has only changed from approximately 13/s to 14/s. However, this is because the test itself is not making more requests. The main improvement here is that the throughput has less variations (ups/downs) for example when rendering very complicated or large pages. You can improve the smoothness of the line even further by using a different garbage collector, as explained on our tuning page.

High Load Scenario, Standalone, 2 CPUs

We define a High Load Scenario as one in which the load generation equates to approximately 25 requests per second. In this test, we are using the same hardware as above, but with 2 CPUs. We assume that any company which expects 20 or more requests per second, even if this occurs during a short time frame, will have greater hardware resources (of equivalent cost) than to what is used in this test.

Confluence 2.10 vs Confluence 3.0 response times
Scenario Average time in 2.10 Average time in 3.0 Improvement 95 percent in 2.10 95 percent in 3.0 Improvement
Browse Label 2389ms 1531ms 56% 6196ms 4195ms 47%
Commentor submit comment 424ms 397ms 6% 1779ms 1603ms 10%
Commentor view commented page 1211ms 815ms 48% 4729ms 2863ms 65%
Commentor view page 1402ms 912ms 53% 5284ms 3094ms 70%
Creator add page 558ms 297ms 87% 1962ms 1543ms 27%
Creator submit new page 783ms 522ms 49% 2567ms 1545ms 66%
Creator view page 443ms 284ms 55% 1845ms 843ms 118%
Dashboard 905ms 506ms 78% 2771ms 1245ms 122%
Editor display page 807ms 504ms 59% 2650ms 2165ms 22%
Edit Page 551ms 338ms 63% 1961ms 1461ms 34%
Editor submit edit 1524ms 1180ms 29% 5115ms 4189ms 22%
Go to log in page 409ms 419ms -2% 1171ms 982ms 19%
Log In 520ms 346ms 50% 2124ms 700ms 203%
Quick Navigation Search 318ms 124ms 155% 1895ms 369ms 413%
Reader Not Found 866ms 492ms 76% 2439ms 1579ms 54%
Reader RSS Blogpost Atom 300ms 105ms 186% 1549ms 191ms 709%
Reader RSS Blogpost RSS2 299ms 98ms 203% 1954ms 183ms 965%
Reader RSS Comment Atom 390ms 224ms 74% 1946ms 931ms 108%
Reader RSS Comment RSS2 362ms 254ms 42% 1824ms 1196ms 52%
Reader RSS Page Atom 1098ms 777ms 41% 4804ms 2848ms 68%
Reader RSS Page RSS2 1126ms 807ms 39% 4532ms 3406ms 33%
View Page 1248ms 742ms 68% 4188ms 2839ms 47%
Reader for Space Page 1410ms 914ms 54% 3749ms 2487ms 50%
Search Site 804ms 411ms 95% 2611ms 1475ms 76%
Confluence 2.10 throughput

Confluence 3.0 throughput

High Load comparison between 2.10 and 3.0 in standalone mode

This scenario shows the performance improvements between Confluence 2.10 and 3.0 best. Confluence 2.10 managed about 22 requests per second, Confluence 3.0 about 27 requests per second. Although this is a significant improvement, those in response times are even more impressive. If you have times when there are 20 requests per second, Confluence will respond a lot better and end users will notice the difference.

Peak Load Scenario, Standalone, 2 CPUs

We define a Peak Load Scenario as one in which approximately 35 requests per second from the load generator. Very few of our customers ever reach these high levels of requests per second, but if you do have 100.000 users and many of them view pages at the same time, then the peak load scenario may occasionally be reached. Again, these tests are run on a 2CPU hardware.

Confluence 3.0 vs Confluence 2.10 response times
Scenario Average time in 2.10 Average time in 3.0 Improvement 95 percent in 2.10 95 percent in 3.0 Improvement
Browse Label 4747ms 3207ms 47% 10951ms 7575ms 44%
Commentor submit comment 1517ms 1146ms 32% 4521ms 3611ms 25%
Commentor view commented page 3148ms 2173ms 44% 9222ms 6184ms 49%
Commentor view page 3302ms 2317ms 42% 9891ms 6410ms 54%
Creator add page 1693ms 934ms 81% 3904ms 3170ms 23%
Creator submit new page 2777ms 1959ms 41% 5812ms 5170ms 12%
Creator view page 1589ms 1065ms 49% 3523ms 3358ms 4%
Dashboard 2121ms 1420ms 49% 5492ms 3704ms 48%
Editor display page 2216ms 1502ms 47% 5081ms 4233ms 20%
Edit Page 1714ms 1062ms 61% 4008ms 3452ms 16%
Editor submit edit 3945ms 3205ms 23% 10523ms 9467ms 11%
Go to log in page 934ms 818ms 14% 4544ms 4091ms 11%
Log In 807ms 913ms -11% 2879ms 3531ms -18%
Quick Navigation Search 1121ms 568ms 97% 4288ms 2704ms 58%
Reader Not Found 2159ms 1222ms 76% 4265ms 3472ms 22%
Reader RSS Blogpost Atom 864ms 531ms 62% 2796ms 2511ms 11%
Reader RSS Blogpost RSS2 1099ms 527ms 108% 4307ms 2691ms 60%
Reader RSS Comment Atom 1110ms 736ms 50% 3469ms 2760ms 25%
Reader RSS Comment RSS2 1159ms 863ms 34% 3959ms 3130ms 26%
Reader RSS Page Atom 2395ms 2300ms 4% 7588ms 7342ms 3%
Reader RSS Page RSS2 2661ms 2258ms 17% 8295ms 7922ms 4%
View Page 3038ms 2055ms 47% 7809ms 5702ms 36%
Reader for Space Page 3005ms 1990ms 51% 6298ms 4850ms 29%
Search Site 1950ms 1247ms 56% 4902ms 3647ms 34%
Confluence 2.10 throughput

Confluence 3.0 throughput:

Please note that this test is slightly skewed by the Load generator sitting one the same machine. The actual results will look a bit better.

Peak Load comparison between 2.10 and 3.0 in standalone mode

Confluence 2.10 is able to deliver about 22 requests per second, but response times are not so good. Rendering a page takes 3s and rendering the dashboard takes 2s on average. Confluence 3.0 delivers improved throughput of about 28 requests per second and response times are significantly better than 2.10 (rendering a page is down to 2s, and rendering the dashboard is down to 1.4s). However, response times under Peak Load in 3.0 are still not ideal. Even with 2 CPUs Confluence 3.0 starts reaching its limits here. While standalone is able to deliver results, what we really recommend for this peak load scenario is a clustered solution. Read on for more details.

Confluence Clustered

When rolling out Confluence to a larger amount of users, Clustering becomes important to balance spikes in load. The most commonly used deployment is a 2-node cluster, running on three physical machines (two application servers connected to one database server).

Clustering does not make a single request faster in low load scenarios, but it helps the system dealing with a larger number of requests in parallel, without degrading in performance.

Medium Load Scenario, Clustered, 2 nodes, 1 CPU per node

As above, we define the Medium Load scenario as making 15 requests per second. This test uses just 1 CPU per machine.

Confluence 3.0 vs Confluence 2.10 response times
Scenario Average time in 2.10 Average time in 3.0 Improvement 95 percent in 2.10 95 percent in 3.0 Improvement
Browse Label 2477ms 919ms 169% 6365ms 2143ms 196%
Commentor submit comment 410ms 380ms 7% 1127ms 856ms 31%
Commentor view commented page 1029ms 595ms 72% 4193ms 1826ms 129%
Commentor view page 1367ms 786ms 73% 5264ms 2557ms 105%
Creator add page 611ms 214ms 184% 1463ms 414ms 253%
Creator submit new page 692ms 422ms 63% 1596ms 938ms 70%
Creator view page 329ms 131ms 150% 1034ms 205ms 404%
Dashboard 1319ms 395ms 234% 3787ms 556ms 581%
Editor display page 750ms 387ms 93% 2592ms 1420ms 82%
Edit Page 493ms 208ms 136% 1569ms 433ms 261%
Editor submit edit 1500ms 980ms 53% 4903ms 3435ms 42%
Go to log in page 854ms 357ms 138% 2898ms 547ms 429%
Log In 961ms 422ms 127% 3320ms 597ms 455%
Quick Navigation Search 183ms 56ms 226% 1178ms 107ms 1001%
Reader Not Found 663ms 351ms 89% 1562ms 554ms 181%
Reader RSS Blogpost Atom 499ms 73ms 577% 2674ms 118ms 2166%
Reader RSS Blogpost RSS2 453ms 65ms 589% 1863ms 122ms 1420%
Reader RSS Comment Atom 776ms 194ms 300% 3143ms 633ms 396%
Reader RSS Comment RSS2 742ms 186ms 297% 2930ms 576ms 408%
Reader RSS Page Atom 1378ms 618ms 122% 4693ms 2109ms 122%
Reader RSS Page RSS2 1497ms 584ms 156% 4767ms 1899ms 150%
View Page 1352ms 631ms 114% 4538ms 2246ms 102%
Reader for Space Page 1251ms 793ms 57% 3124ms 1736ms 79%
Search Site 709ms 258ms 174% 2652ms 399ms 564%
Confluence 2.10 throughput

Confluence 3.0 throughput

Medium Load comparison between 2.10 and 3.0 in clustered mode

As you can see, the response time of each request is a lot better in Confluence 3.0. On average the performance has doubled, leading to response times that are just 50% of what they used to be. This means that a clustered installation provides the same responsiveness as a standalone installation, while still being much better at scaling, which will be shown below. In this example the load was so low that throughput did not increase very much.

High Load Scenario, Clustered, 2 nodes, 2 CPUs per node

As above, we define the High Load scenario as making 25 requests per second. Few customers will reach these levels of requests per second, but if you have several ten thousand users these levels can be reached during peak business hours. This test is run on servers with 2 CPUs per machine.

Confluence 3.0 vs Confluence 2.10 response times
Scenario Average time in 2.10 Average time in 3.0 Improvement 95 percent in 2.10 95 percent in 3.0 Improvement
Browse Label 4674ms 1447ms 222% 12831ms 3822ms 235%
Commentor submit comment 584ms 442ms 31% 1948ms 1340ms 45%
Commentor view commented page 1728ms 680ms 154% 5943ms 2164ms 174%
Commentor view page 2048ms 893ms 129% 7111ms 2868ms 147%
Creator add page 838ms 245ms 241% 2333ms 562ms 314%
Creator submit new page 896ms 466ms 92% 2308ms 1181ms 95%
Creator view page 443ms 155ms 186% 1300ms 234ms 454%
Dashboard 2707ms 339ms 697% 7781ms 427ms 1722%
Editor display page 960ms 446ms 115% 2909ms 1633ms 78%
Edit Page 735ms 255ms 188% 2276ms 699ms 225%
Editor submit edit 1888ms 1108ms 70% 6513ms 4060ms 60%
Go to log in page 1525ms 256ms 494% 4650ms 524ms 786%
Log In 1278ms 406ms 214% 3712ms 598ms 520%
Quick Navigation Search 540ms 49ms 1000% 4292ms 95ms 4418%
Reader Not Found 882ms 413ms 113% 2151ms 813ms 164%
Reader RSS Blogpost Atom 1165ms 49ms 2245% 5052ms 72ms 6888%
Reader RSS Blogpost RSS2 1494ms 51ms 2825% 5565ms 69ms 7872%
Reader RSS Comment Atom 1655ms 195ms 748% 5990ms 763ms 684%
Reader RSS Comment RSS2 1497ms 197ms 656% 5892ms 822ms 616%
Reader RSS Page Atom 2440ms 630ms 287% 8300ms 2263ms 266%
Reader RSS Page RSS2 2562ms 685ms 273% 8027ms 2530ms 217%
View Page 1780ms 750ms 137% 5560ms 2728ms 103%
Reader for Space Page 1668ms 835ms 99% 4177ms 1976ms 111%
Search Site 1691ms 275ms 513% 5853ms 407ms 1338%
Confluence 2.10 throughput

Confluence 3.0 throughput

High Load comparison between 2.10 and 3.0 in clustered mode

In this test we show how using a Cluster for high load instances can increase throughput and reduce response time.  Confluence 3.0 has many improvements which benefit the clustered version.  In the case of the test above, we can see that as the load is increased, Confluence is able to use more of the available CPU power on the 8 core machines to scale up and handle the higher load with an very good response time.  This is where clustering makes a lot of sense now.

Peak Load Scenario, Clustered, 2 nodes, 2 CPUs per node

As above, we define peak load as the load generator making around 35 requests per second.  During this test we used 2 CPUs per machine.

Confluence 3.0 vs Confluence 2.10 response times
Scenario Average time in 2.10 Average time in 3.0 Improvement 95 percent in 2.10 95 percent in 3.0 Improvement
Browse Label 9179ms 2150ms 326% 22987ms 5695ms 303%
Commentor submit comment 999ms 859ms 16% 3175ms 2712ms 17%
Commentor view commented page 2760ms 1213ms 127% 8739ms 3908ms 123%
Commentor view page 3225ms 1672ms 92% 10941ms 5323ms 105%
Creator add page 2396ms 379ms 532% 7285ms 1487ms 389%
Creator submit new page 1913ms 858ms 122% 4850ms 2548ms 90%
Creator view page 1070ms 270ms 296% 2925ms 1130ms 158%
Dashboard 7383ms 466ms 1481% 19349ms 1429ms 1254%
Editor display page 2460ms 761ms 223% 7388ms 2737ms 169%
Edit Page 2609ms 357ms 630% 7143ms 1385ms 415%
Editor submit edit 4064ms 1821ms 123% 12599ms 6287ms 100%
Go to log in page 3622ms 280ms 1191% 13728ms 497ms 2657%
Log In 3603ms 497ms 625% 12477ms 1045ms 1093%
Quick Navigation Search 1268ms 92ms 1273% 9515ms 435ms 2084%
Reader Not Found 1591ms 539ms 195% 3616ms 1622ms 122%
Reader RSS Blogpost Atom 4514ms 78ms 5688% 14570ms 136ms 10605%
Reader RSS Blogpost RSS2 4666ms 84ms 5416% 14554ms 134ms 10689%
Reader RSS Comment Atom 4750ms 328ms 1346% 14934ms 1545ms 866%
Reader RSS Comment RSS2 4723ms 302ms 1460% 16526ms 1412ms 1070%
Reader RSS Page Atom 6443ms 1012ms 536% 20556ms 4005ms 413%
Reader RSS Page RSS2 6287ms 1109ms 466% 17762ms 4175ms 325%
View Page 3363ms 1345ms 150% 10510ms 4717ms 122%
Reader for Space Page 3069ms 1161ms 164% 9475ms 3023ms 213%
Search Site 3334ms 378ms 780% 10560ms 1368ms 671%
Confluence 2.10 throughput

Confluence 3.0 throughput

Peak Load comparison between 2.10 and 3.0 in clustered mode

This test highlights how well Confluence 3.0 can now scale.  Response times remain low as the load is increased.  Confluence 3.0 is able to make far better use of more powerful hardware than Confluence 2.10 which is shown by the improved response times for key scenarios like Page view and Dashboard.

Feedback welcome

We welcome your feedback! Is this document understandable, does it cover the areas that you are most interested about? Tell us and leave comments on this page!


2.10-standalone-peakload-throughput.png (image/png)
2.10-standalone-highload.png (image/png)
2.10-cluster-throughput.png (image/png)
2.10-cluster.png (image/png)
2.10-standalone-highload-throughput.png (image/png)
3.0-cluster.png (image/png)
3.0-cluster-throughput.png (image/png)
2.10-standalone-peakload.png (image/png)
2.10-standalone-throughput.png (image/png)
2.10-standalone.png (image/png)
3.0-standalone-throughput.png (image/png)
3.0-standalone-peakload.png (image/png)
3.0-standalone-highload.png (image/png)
3.0-standalone-highload.png (image/png)
3.0-standalone-peakload-throughput.png (image/png)
3.0-standalone.png (image/png)
3.0-standalone-highload-throughput.png (image/png)
2.10-standalone-peakload-throughput.png (image/png)
2.10-standalone-highload.png (image/png)
2.10-cluster-throughput.png (image/png)
2.10-cluster.png (image/png)
2.10-standalone-highload-throughput.png (image/png)
3.0-cluster.png (image/png)
2.10-standalone-peakload.png (image/png)
3.0-cluster-throughput.png (image/png)
2.10-standalone-throughput.png (image/png)
2.10-standalone.png (image/png)
3.0-standalone-throughput.png (image/png)
3.0-standalone-peakload.png (image/png)
3.0-standalone-highload-throughput.png (image/png)
3.0-standalone-highload.png (image/png)
3.0-standalone-peakload-throughput.png (image/png)
3.0-standalone.png (image/png)
2.10-cluster-peakload-throughput.png (image/png)
2.10-cluster-highload-throughput.png (image/png)
3.0-cluster-highload-throughput.png (image/png)
3.0-cluster-peakload-throughput.png (image/png)
3.0-cluster-peakload.png (image/png)
2.10-cluster-highload.png (image/png)
2.10-cluster-peakload.png (image/png)
3.0-cluster-highload.png (image/png)
Document generated by Confluence on Nov 05, 2009 23:27