Rasa performance for increasingly large trackers

[BlackSwan (Nathasja Franke)]

We are currently building a bot using rasa_core==0.14.4 . During testing we notice considerable slowdown, to the point that it is no longer usable, when having longer conversation. Typically, this happens after around 20 rounds, in our bot this corresponds to 80 events.

After profiling our bots we came to the conclusion that the constant (de)serializing and recreating of the tracker objects is the current bottleneck. Looking at the code, it seems that the processing becomes slower as more events are added to the tracker for two reasons. The line of code is the generate_all_prior_trackers method of the DialogueStateTracker .

First, if we understand correctly, more and more events need to be taken into account to recreate a tracker, but second, more and more trackers are recreated (one for every phase in the conversation). For testing, we are using the InMemoryTrackerStore so it is not related to the SQL or Redis store that can be used in production.

Are we missing something? Or is this a problem other users experience and does someone have a fix?

[Tobias_Wochinger]

Didn’t I respond to this before?

• Yes, Tracker Stores are currently not paginated. There is also an issue for that (Tracker gets very big for long conversations · Issue #3011 · RasaHQ/rasa · GitHub)
• Could be the case that your memory get’s filled since you are using the inmemory tracker store. Have you tried using it with Redis or another persistent tracker store?

[Michael]

@Tobias, facing similar issues, both with in memory (and with plenty of it available) as other tracker stores. Good to see the issue is reported, any idea whether there are plans to address it in the near future (and a developer consensus on the best way forward)? Would be happy to contribute if I can.

[Tobias_Wochinger]

Hi Michael,

there are currently no plans, but I will bring it up and also make a note that several persons are facing this. If you have any suggestions regarding the implementation / requirements, please add them to the issue

[twittmin (mcm)]

Is the main purpose of keeping all events around in tracker to help predict the next action or state? Or is it simply for keeping all historical conversation flows in a storage so that it can be saved and analyzed? If it is the first case, how does it help to keep all events for prediction, and how is it different from the max_history configuration of policies?