In its current state, JIRA cannot be clustered. This is very bad for high availability environments where we heavily depend on JIRA. Our experience with JIRA over the last year is that it is not a 100% robust application and is prone to falling down. Further, a single instance application does not scale very well. Clustering would help with server stability, allow for scaling to meet high demands, and allow for scheduled server maintenance to not interrupt the service. It is ignorant to believe that one instance is all an enterprise environment will ever need.

The main bottlenecks appear to be:
1) sessions
2) attachments
3) indexes

I would suggest that following strategies to solve these problems
1) remove all session dependencies - make the application stateless by using a combination of cookies, and referrer links. We have undergone the same endeavors with our applications (Java & .NET) and with a little ingenuity, has created a very fast application that is much more resilient to application restarts.

2) Move attachments to the database. Any serious use of this application should be using MSSQL, Oracle or other commercial servers which have very efficient handling of attachments and large binary arrays.

3) A realization that has helped us immensely is that real-time data, does not mean instantaneous synchronization in a web environment. TTL based caching is for most cases, more than good enough. Generally speaking, as long as the current user sees his changes as being applied (searches return with his changes), other users on other cluster nodes can see stale data for a short period of time.