Performance tuning for confluence run as a service

Jörg Köplin

Dear Team,

I am running confluence as a windows-service on a virtualized WIN10 64-Bit System. 

Due to the virtualization, the overall performace of confluence - as you can imagine - is limited.

That's why I wonder, whether there are some configuration hints on how to speed up the performance of the confluence window-based service? (I already tried to set the to process to 'Real-Time').

I am using a Postgres-DB, for which you might also have some recommendations in stock?

Maybe I should install Confluence + Postgres-DB on a Linux-System? Would that help with regards to increased performance? BTW: Which Linux do you recommend?

Am I permitted to download the Linux-Version for my Licence as well? I started with the Windows-Version?

Thanks a lot for your support.

K.rgds. Jörg. 

Nic Brough -Adaptavist-

I've not seen any noticable difference between "run in foreground" vs "run as a service" in terms of performance.

Running it in a VM on Windows does not change what you'll need to do for performance tuning - monitor it and investigate slowness when it happens.  The primary things are generally to make sure that the home directory (at least caches and indices) are on a fast local disk, and make sure there's enough memory for it to play with.

When it comes to the database, I'd always choose Postgres first, then MySQL, then Oracle and MS-SQL last, when given a free choice.  But that's just because Atlassian target Postgres first, and I've had increasingly poor experiences as you work down the list.  The difference between Postgres and MS-SQL is however tiny, and that's 1% of the decision.  The other 99% of weight in choice of database is "what does your organisation know best?"

As a general rule, you'll find Linux systems are faster than Windows.  I know there's a potential flame war there, but I'm afraid that deep down, even MS knows it's the truth.

However, again, you should stick with the OS that suits you best.  The bits of performance gain you might get from a swap to Linux are probably not going to compensate for your main problem here. 

If you do swap, then, yet again, the advice is "what you know best".  Atlassian target RedHat first, probably because of the support options for it, but that flows over fine into CentOS (as it's pretty much RedHat rebranded and without support options), and then Ubuntu as the next most popular option.  Frankly, it works fine on most - I can vouch for it running a little faster on Arch than CentOS (same hardware), but that's almost certainly because my Arch build was taking advantage of "only build what you need" and "dedicated build for this single machine", not that "it runs faster on Arch".

Your licence does not care what you are running the service on!  It'll even work on OS's Atlassian don't formally support.