I know this is an older thread but figured I would add my experience of this issue for future readers.
InMemoryStoreTrackerStore and InMemoryLockStore are for situations where you have a single Rasa Core instance. I.e. If you have one instance for a chatbot it can store trackers and perform conversation locks in it’s own memory without issue.
If you want to scale up to multiple rasa instances for a single chatbot (i.e. load balancing) you will need a shared/external place to store trackers and lock conversations. I.e. in the case of TrackerStore all Rasa Core instances need access to the same trackers, allowing any instance to respond to any conversation (Yay, no need for sticky sessions). In the case of LockStore each Rasa Instance needs to be able to lock a conversations to ensure other instances don’t respond to the same conversation and messages are all processed in the correct order.
Either way you are storing and retrieving the same data, but I would imagine using InMemoryTracker and InMemoryLockStore would generally be faster, but as they don’t allow us to scale we sometimes need an external tracker store/lock store like Redis/SQL/Mongo/etc.
We had a similar issues with response time increasing due to the increasing size of trackers throughout a conversation. Each tracker is essentially a stack/list of previous conversation events that allows the chatbot to continue the conversation context, so they are expected to get bigger (and each input actually equates to multiple events).
To tackle this issue we decided to create a custom tracker using Firestore (GCP NoSQL DB). In the custom tracker code we trim the conversation history so that we only actually store the most recent n (e.g. 20) events. This seems to be working for us so far, but we will see when we scale up.
You should be able to do the same for Redis/Memory/whichever - have a look at the rasa code for the trackers, create your own version with trimmed tracker, then refer to the custom tracker file and Class name in your endpoints.yml ("."):
tracker_store:
type: custom_tracker.MyCustomTrackerStore
Hope the above is helpful and accurate. If anyone notices any issues please advise - my understanding needs some fine tuning.
The only thing I was unsure about was whether trimming would remove SlotSet events and result in slots no longer being populated, so in the end I actually avoided trimming SetSlot events (except for older SlotSet events for slots that have since been set again). I guess this means we will still get a slight increase in memory usage but hopefully not too noticeable.