Does anyone have any experience of using multiple CS instances with a single Mongo database for topic logging? We are looking at scaling to 1000’s (possibly 10,000’s) of simultaneous users and was wondering if anyone else had operated at this scale and how it was approached? Our current thinking is to dockerise our CS instance and use a single Mongo instance (possibly part of a replicated set) for topic storage.

Also how did you approach conversation logging? Ideally we’d like that centralised as well not local, is that the purpose of ltm logging? Can’t find much info on ltm in the docs so if anyone can shed more light on this it would be much appreciated.

Thanks

We currently have multiple CS instances talking to a single Mongo database. That is CS on several servers and each of those servers running with multiple forks, but they are all talking to a single db. I don’t know the specifications of those servers because that is not my area on responsibility.

A CS instance can only support a single mongo connection for the topic files so if you want multiple db’s then you’ll probably have to shard further up the stack, perhaps by peeking into the user part of the CS protocol message.

LTM (long term memory) is under CS script control whereas reading and writing topic files (to mongo) is integral to the engine. But CS has this convention that if a fact file that you are ^import() or ^export()‘ing uses a file name that starts “USERS/ltm” then the engine will redirect that to a database if you have included a ltm definition as part of the database connection parameter. We read/import LTM in preprocess and write it out in postprocess topics, but it is totally under script control and therefore you could use different file names at different places.

What you put into ltm is totally up to you. We use it to record bits of data that we want to hang on to longer than the current transaction.

For actual conversation logging then our system has an internal api that we POST to, because that is ever increasing and there is no need to keep it around in the CS world.

JustAnswer only runs a single cs server using a single instance. So topic files merely reside on that machine.
Using a single machine with say 8 forks will scale roughly linearly and still just use the local file system.
JA does not have tens of thousands of SIMULTANEOUS user conversations. But it does process millions of conversations a month (each conversation being around 5 volleys)

Thanks for the replies, I will definately investigate the fork parameter as running a single CS instance will simplify the architecture.

One thing to remember if you are running multiple forks/servers is to have some queuing technology before CS so that utterances from the same user are not being processed at the same time.
Having two processes simultaneously reading/writing the topic file will lead to confusion
And that also has implications for load testing.

Thanks for the tip. We have a nodejs app that fronts CS and serializes requests/responses although we are at the mercy of clients adhearing to the request/response model, which isn’t a problem at the moment as we have tight control over the clients. But is in the back of my mind how we would prevent asynchronous requests should we open up the api to clients we don’t have so much control over.