Hi,<br><br>I&#39;m evaluating OTRS&#39;s performance for a ~large scale implementation and I&#39;m wondering if anyone ran into ~steep performance bottlenecks after hitting some threshold for a metric such as total # of tickets, db size, attachment size, etc. Please share if you did.<br>
<br>I ask because I need to formulate a promise towards a potential customer about how long his implementation&#39;s
 performance will scale in terms of some metrics usable to approximate time intervals (something like: if you have 500 new tickets per month and about 30% open tickets then this implementation will very likely scale for ~3 years).<br>
<br>Looking around the docs / Internet I keep hitting a reference for the need to switch the &quot;backend module for the ticket index&quot; from RuntimeDB to StaticDB when the db has ~60000 tickets or 6000 open tickets (<a href="http://doc.otrs.org/3.1/en/html/performance-tuning.html">http://doc.otrs.org/3.1/en/html/performance-tuning.html</a>). However there is no technical explanation for how these numbers came about. Does it depend on hardware or is it a threshold beyond which performance doesn&#39;t scale anymore regardless on how much hardware you throw at it?<br>
<br>Another possible issue would be db size. With this one I saw no clear cut numbers but various mailing list posts led me to believe performance would scale, with adequate hardware, for dbs up to 200 GB.<br><br>My case will require a relatively light workload at first (~100 tickets / day) but these will be tickets with large photo attachments so I may have to offload attachments from the database sooner than I imagine.<br>
<br>Thanks,<br>Bogdan<br><br>