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!

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

Have a question about this article?

See questions about this article

Powered by Confluence and Scroll Viewport