Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MongooseIM: Testing Massively Concurrent System

MongooseIM: Testing Massively Concurrent System

Distribution to multiple virtual machines in the cloud or servers is the way to scale horizontally when there is no more room or resources to grow vertically. In this talk we will discuss how to load test an XMPP server and distribute load generation using Erlang/OTP as a platform. Experiences from testing production ready MongooseIM systems will be presented.

Michał Ślaski

February 01, 2015
Tweet

More Decks by Michał Ślaski

Other Decks in Programming

Transcript

  1. MONGOOSEIM • Instant messaging for Social Media, Gaming, etc. •

    Solution designed for high volume • Easily scalable distributed system
  2. MONGOOSEIM • Instant messaging for Social Media, Gaming, etc. •

    Solution designed for high volume • Easily scalable distributed system • Meeting challenges of mobile
  3. ESCALUS • A library for acceptance testing XMPP servers •

    Complicated scenarios
 - several users,
 - several resources per user,
 - setting up & tearing down the state.
  4. ESCALUS % TEST CASE
 % Alice sends a chat message

    to Bob’s bare JID % Bob gets the message on both resources
  5. ESCALUS % TEST CASE
 % Alice sends a chat message

    to Bob’s bare JID % Bob gets the message on both resources % Bob replies to one of Alice’s resources
  6. ESCALUS % TEST CASE
 % Alice sends a chat message

    to Bob’s bare JID % Bob gets the message on both resources % Bob replies to one of Alice’s resources % Alice receives the reply only on that resource
  7. LOAD TESTING • Compile all the scenarios • Start my_scenario

    • Users with ids from 1 to 100000 $ ./run.sh my_scenario 1 100000
  8. • Scenario = Erlang module • two exported functions: init/0

    and start/1 AMOC SCENARIO -module(my_scenario). -export([start/1]). -export([init/0]).
  9. • called once at the very beginning • used to

    initialize state INIT/0 init() -> exometer:new(?MESSAGES_CT, spiral), exometer_report:subscribe( exometer_report_graphite, ?MESSAGES_CT, [one, count], 10000), ok.
  10. • called once at the very beginning • used to

    initialize state • return state (coming soon™) INIT/0 init() -> exometer:new(?MESSAGES_CT, spiral), exometer_report:subscribe( exometer_report_graphite, ?MESSAGES_CT, [one, count], 10000), ok.
  11. • describes the scenario for one user • argument is

    an unique integer START/1 start(MyId) -> % connect user (using escalus) % fetch history % send some messages
 % wait
 % send some messages again
  12. • describes the scenario for one user • argument is

    an unique integer • function is called START/1 start(MyId) -> % connect user (using escalus) % fetch history % send some messages
 % wait
 % send some messages again • again, and again, and again, and again, and again, and again, and again, ...