Confluence 10.2 Long Term Support release performance report
Would you like to measure Confluence Data Center performance without having to run your own tests? We’ve benchmarked it for you.
In line with our performance reports for Jira and Jira Service Management, the Confluence Data Center performance report provides general performance benchmarks through a framework of Non-Functional Requirements thresholds.
About Long Term Support releases
We recommend upgrading Confluence Data Center regularly. If your organization's processes mean you can only upgrade about once a year, upgrading to a Long Term Support release is a good option. It provides continued access to critical security, stability, data integrity, and performance issues.
Highlights
As with all Long Term Support (LTS) releases, we aim to provide the same, if not better, performance. Confluence Data Center 10.2 LTS testing demonstrates largely stable performance across the product, with a few noticeable improvements.
Here are some highlights seen during the testing we ran:
- Common tasks such as View page, View dashboard, Create page, and Publish page are all well below threshold
- Full site reindexing time has been reduced by 34%
We'll continue to improve future performance and scalability so that teams can move with ease through their workspace, and our largest customers can scale confidently.
Performance
Since Confluence 9.2, we’re showcasing the results of our performance testing through a new framework that focuses on Non-Functional Requirements (NFR) thresholds for essential user actions. These thresholds serve as benchmarks for reliability, responsiveness, and scalability, ensuring that our system adheres to the expected performance standards.
We established a target Key Performance Indicator (KPI) threshold for three key types of actions.
| Action type | Response time in ms | |
|---|---|---|
| 50th percentile | 90th percentile | |
| Page interactions | 2500 | 3000 |
| Engagement actions | 2500 | 3000 |
| Content management | 3000 | 5000 |
The recorded response time benchmarks provide insight into the system’s performance:
50th percentile - Showcases the average performance for most users. It's less affected by extreme outliers, so it shows the central tendency of response times.
90th percentile - Shows performance for worst-case scenarios or high load conditions, which may affect a smaller portion of users.
| Action type | Response time in ms | |
|---|---|---|
| 50th percentile | 90th percentile | |
Page interactions | ||
| Target KPI threshold | 2500 | 3000 |
View Dashboard | 763 | 821 |
View attachment | 1613 | 2108 |
View blog post | 899 | 1210 |
View page | 628 | 735 |
View page (w/ small attachments) | 697 | 834 |
View page (w/ large attachments | 699 | 873 |
View page after publish | 630 | 724 |
View page after publish (w/ small attachments) | 695 | 806 |
View page after publish (w/ large attachments) | 698 | 821 |
Edit page | 1048 | 1048 |
Edit page (from shared link) | 1398 | 1719 |
Edit page (w/ attachments) | 707 | 794 |
Create blog post | 974 | 1340 |
Create page (collaborative) | 1406 | 1582 |
Create page (single user) | 641 | 788 |
Publish page | 480 | 528 |
Publish page (w/ small attachments) | 712 | 811 |
Publish page (w/ large attachments) | 719 | 807 |
Log in | 404 | 472 |
Log out | 1284 | 1334 |
Engagement actions | ||
| Target KPI threshold | 2500 | 3000 |
Comment | 1517 | 1765 |
Like page | 526 | 1026 |
Content management | ||
| Target KPI threshold | 3000 | 5000 |
Upload attachment | 2783 | 3292 |
Search | 1340 | 1736 |
Testing methodology
The following sections detail the testing environment, including hardware specifications and the methodology we used in our performance tests.
How we tested
The following table represents the dataset we used in our tests:
Data | Value |
|---|---|
Pages | ~900,000 |
Blogposts | ~100,000 |
Attachments | ~2,300,000 |
Comments | ~6,000,000 |
Spaces | ~5,000 |
Users | ~5,000 |
Actions performed
We chose a mix of actions that would represent a sample of the most common user actions. An action in this context is a complete user operation, like opening a page in the browser window. The following table details the actions that we included in the script, for our testing persona, indicating how many times each action is repeated during a single test run.
Action | Number of times an action is performed in a single test run |
|---|---|
Create page (single user) | 538 |
Publish page | 254 |
Publish page (w/ small attachments) | 38 |
Publish page (w/ large attachments) | 19 |
View page | 395 |
View page (w/ small attachments) | 38 |
View page (w/ large attachments) | 44 |
View page after publish | 394 |
View page after publish (w/ small attachments) | 76 |
View page after publish (w/ large attachments) | 38 |
Search | 2,362 |
Log in | 508 |
Log out | 254 |
Create page (collaborative) | 508 |
Create blog post | 987 |
View blog post | 256 |
Edit page | 508 |
Edit page (from shared link) | 508 |
Edit page (w/ attachments) | 57 |
View Dashboard | 508 |
Like page | 578 |
Upload attachment | 1,353 |
View attachment | 1,184 |
Comment | 762 |
Test environment
The performance tests were all run on a set of AWS EC2 instances. For each test, the entire environment was reset and rebuilt, and then each test started with a five-minute warm-up to prepare instance caches, with each test running for 60 minutes. Below, we show the details of the environments used for Confluence Data Center, as well as the specifications of the EC2 instances.
All tests were run a number of times for consistent results.
Here are the details of our Confluence Data Center test environment:
2 Confluence nodes
Database on a separate node
Shared home directory on a separate NFS Server node
Load Balancer (AWS ALB Application Load Balancer)
Confluence Data Center with 2 nodes
Hardware | Software | ||
|---|---|---|---|
EC2 type | m5.2xlarge | Operating system | Amazon Linux 2 |
vCPUs | 8 | Java platform | Temurin-21.0.6 |
Memory (GiB) | 32 | Java options | 8 GB heap |
Physical Processor | Intel(R) Xeon(R) Platinum 8000 | ||
Clock Speed (GHz) | 3.1 | ||
CPU Architecture | x86_64 | ||
Storage | AWS EBS 200 GB GP2 | ||
Database
Hardware | Software | ||
|---|---|---|---|
EC2 type | db.m5.xlarge | Database: | PostgreSQL 16.3 |
vCPUs | 4 | Operating system: | AWS managed |
Memory (GiB) | 16 | ||
Physical Processor | General Purpose SSD (gp2) | ||
Storage (GiB) | 700 | ||
NFS server
Hardware | Software | ||
|---|---|---|---|
EC2 type | m4.large | Operating system | Amazon Linux 2 |
vCPUs | 2 | ||
Memory (GiB) | 8 | ||
Memory per vCPU (GiB) | 4 | ||
Physical Processor | Intel(R) Xeon(R) Platinum 8175M | ||
Base Clock Speed (GHz) | 2.50 | ||
CPU Architecture | x86_64 | ||
Storage | AWS EBS 100 GB GP2 | ||