I’ve got a 2 year old second hand server with 32 Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz cores and 128 gigs of memory (it was only $2k AUD) it doesn’t break a sweat with 10 concurrent users. It could easily run on 2 cores. memory is never wasted, I’m not sure how little memory I could get away with, but I’ve configure postgres and elasticsearch to make use of as much as possible.
With my limited experience I’ve found clock speed matters atm because the job queue runner is a single thread. If you have a choice between cores and clock speed go for less cores and higher clock speed. Things like ldap integration will add 100s of jobs to the queue every hour and some jobs take many seconds to process. The more agents logged in the more jobs added to the queue too as they work. If the job queue gets backed up their interface doesn’t block, they can still work, but there might be a delay for them to be notified of a new ticket.
The more tickets you have the more memory you can give to elasticsearch and postgres, the recommendation for elasticsearch is not to go above 30G for a single node. I’ve got 20k tickets, elasticesearch’s store size is 400M. I got a bit of headroom there.
postgres needs a bit of tuning, there will be a lot of updating the session table, with 10 users I see an occasional backlog of threads waiting to update it, sometimes 500ms. My postgres config is here [SOLVED] High number of delayed_jobs