1
votes

Assuming this conceptual setup:

  • ejabberd cluster (either instances in cloud or hosted SaaS)
  • ejabberd MySQL database (some hosted solution elsewhere)
  • website instances
  • website MySQL database (same place as ejabberd database, but different database)

Also relevant is that currently the website instances already directly access the ejabberd MySQL database, in order to add new users (no need for rosters and other stuff like that, so xml_rpc overhead is avoided- though that might change in the future).

Now I want to write a module which will store presence info in a database that can be accessed from the website.

Which solution would be better for scalability and stability?

  1. Add a new table to the ejabberd MySQL table and use the same sort of code that's used elsewhere in ejabberd for talking to the database to write presence info

  2. Spin off http requests and let the webserver do the writing

I'm not familiar with Erlang and where the hangups/bottlenecks might be... I guess the two approaches are somewhat similar, and the database approach will be better since there's already internal support for connection pooling... but just wanted to check before starting to code.

1

1 Answers

0
votes

You have other approaches that you can use, alternatively:

  1. Query ejabberd to get the presence from memory. You can use HTTP for that, using XML-RPC or Rest API.

or

  1. Use Redis Session backend for ejabberd and read sessions state from Redis. You may want to look into the sm_db_type option. It will only store a record, if the session is online, but not the actual presence of the user, for performance reason. This Redis approach does not change authentication back-end and is used for transient sessions.

Case 1 is more efficient, but may not be practical depending on how you plan to use presence. Case 2 is a bit less efficient, but in all cases, more efficient than using MySQL or HTTP requests.