AI Zone Admin Forum Add your forum

CHATBOT MEETUP CHATBOT MEETUP CHATBOT MEETUP CHATBOT CHATBOT MEETUP CHATBOT MEETUP CHATBOT MEETUP CHATBOT MEETUP

On June 28th, 2017 we're organizing our next Chatbot Meetup in Amsterdam, The Netherlands. Feel free to join!'

Max number of concurrent humans chatting
 
 

Which chatbot platform is capable to support the maximum number of concurrent humans chatting at the same time?
Chatterbot, Rivescript, Program-O Program-AB, Chatscript or which else?

 

 
  [ # 1 ]

I use AIML on Pandorabots servers and my bot talked quite happily to a few thousand concurrent users after I won the Loebner Prize in 2013.

 

 
  [ # 2 ]

Program O is similarly capable of large numbers of concurrent users. I suspect that with the right web interface, ChatScript would be capable of the same. As to which one can handle the most users? I don’t really know.

 

 
  [ # 3 ]

And what about Program AB and Rivescript?

 

 
  [ # 4 ]
Matteo Raggi - Feb 13, 2015:

Which chatbot platform is capable to support the maximum number of concurrent humans chatting at the same time?
Chatterbot, Rivescript, Program-O Program-AB, Chatscript or which else?

Since each of these runs on/with a web host & server, it may depend most on the hardware configuration of each server. Cloud/virtual computing could enable very large numbers. What might be a better question is which is most efficient and if there is any max or blocking pieces of the system.

However, because of its design, Skynet-AI/JAIL is the fastest system and could handle the most concurrent humans chatting at the same time.

 

 
  [ # 5 ]

The main limitation of RiveScript (as far as RAM anyway) would be with the size of the brain (number of replies) rather than the number of concurrent users.

The amount of data stored (edit: stored in RAM) for each individual user is extremely small (it just stores the most recent 9 inputs and replies from them, which topic they’re in, and then any other user variables (name, age, etc.) that they’ve volunteered to your bot). The amount of RAM needed for the replies though scales linearly with the number of replies you have. I’ve tested using A.L.I.C.E.‘s brain in RiveScript and it works pretty well, for having some 40,000 responses or so. A RiveScript brain would typically be smaller in raw size than an AIML one, due to the way that RiveScript can consolidate tons of triggers down into just one or two (since the pattern format in RiveScript is like a regular expression, whereas in AIML you need one pattern for every little variation of the same question).

Also, RiveScript is largely a “read only” bot, as in once your RiveScript code has been read, the bot no longer needs to read or write your replies. This lends it towards being infinitely scalable horizontally (i.e. you could have a cluster of servers spread across multiple data centers, and have a shared NFS mount or similar where the bot can read its replies only as it starts up, and then each server would be autonomous from then on out). Edit: you could also keep your RiveScript replies in a database, and stream them in from a SQL query rather than reading files from disk, i.e. using stream() instead of loadFile().

But that’s probably true of other systems too, i.e. AIML bots could potentially be distributed across multiple servers as well, although I don’t know how that will play into how an AIML bot saves user data (IIRC, Alicebot Program D saves user variables as XML files on disk, which may raise complications with distributed servers). RiveScript has no built-in feature to save user variables and leaves that to the programmer to deal with; you could save/load them to disk for small bots or stick them in a PostgreSQL database for distributed bots.

 

 
  [ # 6 ]

Well relatively new, SuperScript[1] is based on RiveScript and also supports multiple concurrent users at once. However the conversation engine is stored in mongoDB and allows gambits to be re-written on the fly.

1. http://superscriptjs.com

 

 
  [ # 7 ]

who can say?  Do you mean with a single server?  ChatScript supports running a copy of the engine on each core of a machine, using the same filesystem. and it directly talks to postgres database.

 

 
  [ # 8 ]

In the case of ChatScript, how can be concurrency handled? if a number of users a1, a2, ... etc start a “session” with the engine in the same server, will global variables be mixed between users or handled independently with each session?

 

 
  [ # 9 ]

Every user has their own session with the engine (extending into the future across sessions). Nothing mixes. All is independent.

 

 
  login or register to react