Hey everyone,
I’m curious about the limits of Jira when it’s running on Tomcat. We’ve got it set up on a RHEL machine with 4 cores and 4 GB of RAM. It’s doing fine now, but we’re expecting more users soon.
Does anyone know how many people can use it at once before it starts to struggle? Our Jira is on its own Tomcat server, so even general Tomcat info would be helpful.
Right now we get about 6000 hits each day. I’d love to hear what numbers you’re seeing in your setups. It would be great to compare and get an idea of what to expect.
Thanks in advance for any insights!
hey, i’ve run jira on tomcat for a while. with ur setup, u might hit issues around 150-200 users. we boosted ours to 8GB RAM and it helped tons. also, watch out for big attachments - they can slow things down. maybe think about limiting file sizes? good luck with the scaling!
I’ve been running Jira on Tomcat for a few years now, and I can share some insights from my experience. With your current setup (4 cores, 4GB RAM), you’re likely to hit performance issues as you scale up. In our environment, we saw significant slowdowns around 200-300 concurrent users with similar specs.
To improve capacity, I’d recommend upgrading to at least 8GB RAM and possibly more cores. We saw a big jump in performance after doing this. Also, don’t forget to optimize Tomcat settings - tweaking the JVM heap size and connection pools made a noticeable difference for us.
One thing to keep in mind: the type of Jira usage matters a lot. If users are just viewing tickets, you can handle more. But if they’re running complex JQL queries or updating lots of issues, that’ll hit your server harder. Monitor your performance closely as you grow, and be prepared to scale up your hardware if needed.
I’ve been managing a Jira instance on Tomcat for a while now, and I can share some insights from our setup. We’re running on more robust hardware - 8 cores and 16GB RAM - and it’s handling about 500 concurrent users without breaking a sweat.
Your current setup might struggle as you scale up. We found that RAM was the biggest bottleneck initially. Upgrading from 4GB to 16GB made a world of difference. Also, don’t underestimate the impact of disk I/O - switching to SSDs gave us a noticeable performance boost.
One thing we learned the hard way: keep an eye on your attachments. They can bloat your database quickly and slow things down. We implemented a policy to limit attachment sizes and it helped maintain performance as we grew.
Lastly, consider your workflow complexity. Simple workflows scale better than complex ones with lots of custom fields and automations. We had to refactor some of our more convoluted processes to keep things running smoothly as we expanded.