# Scale Rasa-X for production

**URL:** <https://forum.rasa.com/t/scale-rasa-x-for-production/30134>\
**Category:** \[Deprecated\] Rasa X Community Edition\
**Created:** [June 12, 2020, 12:33pm UTC](https://forum.rasa.com/t/scale-rasa-x-for-production/30134 "2020-06-12T12:33:17Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![alxbar](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.rasa.com/alxbar/32/8108_2.png) [@alxbar](https://forum.rasa.com/u/alxbar)\
**Post date:** [June 12, 2020, 12:33pm UTC](https://forum.rasa.com/t/scale-rasa-x-for-production/30134/1 "2020-06-12T12:33:17Z")

</div>

We deployed Rasa-x with the official [helm chart](https://github.com/RasaHQ/rasa-x-helm/tree/master/charts/rasa-x) on an Azure AKS Cluster and were stress testing with locust. We noticed that a single rasa-production pod facing around 100 simulated simultaneous users would lead to a non-functioning postgresql pod: `2020-06-12 12:01:46.013 GMT [30481] FATAL: sorry, too many clients already`

And the production pod would complain similarly:

`2020-06-12 12:29:14 WARNING rasa.core.tracker_store - (psycopg2.OperationalError) FATAL: sorry, too many clients already`

The locust task would consist of messages send to /api/conversations//messages in an interval between 5 and 9 seconds.

After scaling the production-pod up to 5, we were getting decent response times for a testcase of 110 users. Around 150ms on average at the beginning but slowly increasing to around 600-700ms as the conversation-length got to 100. With increasing conversation length, the response time increased to over a second. I think this has something to do with tracker serialization/deserialization, as mentioned in another post.

> [@Size of trackers in custom tracker store](http://forum.rasa.com/t/size-of-trackers-in-custom-tracker-store/4998/4):
>
> Hello friend,Could you please tell me how are you fetching specific details from the tracker store. Elaborating my doubt below: in my run\_app.py (socketIO class) i have used mongotracker like this- db = MongoTrackerStore(domain=“d.yml”,host=‘mongodb://localhost:27017’, db=‘xyz’, username=“x”,password=“x”,collection=“x”,event\_broker=None) agent = Agent.load(‘models/dialogue’, interpreter=‘models/current/nlu’,action\_endpoint = action\_endpoint,tracker\_store=db) now i want to fetch some data lik…

Also, we get pod crashes as load increases:

 ![locust](https://europe1.discourse-cdn.com/flex013/uploads/rasa/original/2X/3/3bdadfa9b4d850f52863b80f99d92c4de8a84e77.png)

CPU load suggests there is some room left:

 ![cpu_load](https://europe1.discourse-cdn.com/flex013/uploads/rasa/original/2X/9/902f5bbf39255d9004d319d6566e845e3e1a1940.png)

How would you go on about this? Is this plainly a scaling issue, meaning that more nodes and rasa-production pods would solve the problem, or is there also a database-based bottleneck?

If we would use a Redis managed service from Azure as the Tracker Store (and Lockstore) combined with more pods, would this solve the problem and how would you configure the values.yml in the helm chart?