Confluence 3 Performance improvements
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 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 utilized 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 analyzing 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 standardized 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 distribution, 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
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 has significantly better performance characteristics than Confluence 2.10. We compare three load scenarios and give the details below.
Medium Load scenario, 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
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, 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
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, 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
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 Confluence 3.0 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 Confluence installation provides the same responsiveness as a Confluence 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!