XMPP collaboration and scalability testing: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
No edit summary
 
(One intermediate revision by one other user not shown)
Line 4: Line 4:
* XO's and activities not showing up in all neighbourhood views ([http://dev.laptop.org/ticket/6884 #6884],[http://dev.laptop.org/ticket/6888 #6888],[http://dev.laptop.org/ticket/6940 #6940],[http://dev.laptop.org/ticket/7457 #7457])
* XO's and activities not showing up in all neighbourhood views ([http://dev.laptop.org/ticket/6884 #6884],[http://dev.laptop.org/ticket/6888 #6888],[http://dev.laptop.org/ticket/6940 #6940],[http://dev.laptop.org/ticket/7457 #7457])


Specifically, we want to know if these situations occur under all loads or only when the xmmp server has a certain amount of logged in users. And ofcourse, if the bug is on the server side or the client side
Specifically, we want to know if these situations occur under all loads or only when the xmmp server has a certain amount of logged in users. And ofcourse, if the bug is on the server side or the client side.


This plan specifies a high-level overview of what should be done. The actual execution can either be done manually using xo's and sugar or more automated. Ideally we want to focus on the lower level collaboration, specifically gabble and ejabberd, so testing without using sugar is probably more worthwhile
Work in progress..

== Test plan ==

* Setup a ejabberd server running the same version and with the same configuration (including shared roster patches) as on XS.
FIXME: Need information about which version of and patches to ejabber is present on the XS. And also some details about the configuration

* Open a set of xmpp connections to the jabber server, either using xo's, sugar-jbuild, gabbles on a non-sugar system, etc. About 20 is probably a good start
* Check that all xmpp connections succeeded.
* Check that all xmpp connections have all others in their presence/buddy info (either by checking the meshview and/or by using the telepathy interface directly)
* For each connection:
** Start and share an Activity (either through sugar or direct use of telepathy)
** Check if this activity is shown on all instances.
** Stop the activity, check if it has gone away on all instances

When this was successfull, add 5 more instances untill problems start arising. Data about the memory/cpu usage of ejabberd should be collected during the test run.

Latest revision as of 14:15, 8 August 2008

There are three cases we want to test for

  • XO's failing to connect to the xmpp server: (#5908)
  • The xmpp server falling over (runs out of memory) (#5313)
  • XO's and activities not showing up in all neighbourhood views (#6884,#6888,#6940,#7457)

Specifically, we want to know if these situations occur under all loads or only when the xmmp server has a certain amount of logged in users. And ofcourse, if the bug is on the server side or the client side.

This plan specifies a high-level overview of what should be done. The actual execution can either be done manually using xo's and sugar or more automated. Ideally we want to focus on the lower level collaboration, specifically gabble and ejabberd, so testing without using sugar is probably more worthwhile

Test plan

  • Setup a ejabberd server running the same version and with the same configuration (including shared roster patches) as on XS.

FIXME: Need information about which version of and patches to ejabber is present on the XS. And also some details about the configuration

  • Open a set of xmpp connections to the jabber server, either using xo's, sugar-jbuild, gabbles on a non-sugar system, etc. About 20 is probably a good start
  • Check that all xmpp connections succeeded.
  • Check that all xmpp connections have all others in their presence/buddy info (either by checking the meshview and/or by using the telepathy interface directly)
  • For each connection:
    • Start and share an Activity (either through sugar or direct use of telepathy)
    • Check if this activity is shown on all instances.
    • Stop the activity, check if it has gone away on all instances

When this was successfull, add 5 more instances untill problems start arising. Data about the memory/cpu usage of ejabberd should be collected during the test run.