OTRS Hardware resource planning

[flippertom]

Hello,

How to plan for hardware resources for OTRS?
We have oracle database back end which is on a separate server and we get about 3000 tickets per day.
The system has about 1500 agents configured.
Majority of the tickets are created via email.

How to determine the suitable hardware requirements (RAM/CPU/Storage) and what to consider when forecasting for future requirements?

Regards,
Tom.

[wurzel]

Hi,

Check one agent session memory apache2 needs and you should get a estimated memory forecast.
Add enough memory for caching and think on more sessions per agent if the agent uses more tabs/devices

Storage depends on the attachements you'll receive, just calculate here


future estimations is hard to say, you should know your growing forecast by yourself.
Assuming a apache session takes ~200MB memory (including caching and reserves) I calculate 300GB Memory

CPU? don't know how to caluclate here

As you could think that apache might not be able to handle 1500 agent requests you have to think on clustering,
which is very very difficult (maybe impossible with proper knowledge) to set up. Speaking for myself
(and i know linux + OTRS really good) I would not be able to set up a cluster for a production system in this size.
You'll need a good performant load balancer, a fast storage, fast connections...

In summary: ask a specialist for this big scenario

Florian

[root]

Hi,

Physical or virtual? If virtual which platform?

- Roy

[wurzel]

Hi,

I doubt to get this running with good performance on virtual system.

Flo

[root]

I doubt to get this running with good performance on virtual system.

Maybe you doubt, I not. Without knowing more details I don't do any estimate. 1.5k agents with 3k tickets a day could mean 2 tickets a day per agent. Could also be 500 agents per 8 hrs in a 24/7 workload.

OP please provide more details: how many concurrent users, any restrictions, limitations? Do you HA or redundancy? etc etc

- Roy

[wurzel]

Hi,

yes, I was expecting 1500 sessions with a high load
2 tickets per agent can also be a high load of 200 articles per ticket at the end

root: your're right... let's see what we get

Flo

[flippertom]

I doubt to get this running with good performance on virtual system.

Maybe you doubt, I not. Without knowing more details I don't do any estimate. 1.5k agents with 3k tickets a day could mean 2 tickets a day per agent. Could also be 500 agents per 8 hrs in a 24/7 workload.

OP please provide more details: how many concurrent users, any restrictions, limitations? Do you HA or redundancy? etc etc

- Roy

Thank you both for the replies.
There is no HA. As for concurrent load at peak times, I would say 300 agents.
We're running on a virtual machine with SUSE Linux.
There is a 2 hour session idle time. No restriction on number of active sessions.
These are the points which I could think of right now. Let me also check if there is some more information which could be relevant.