Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Fetching contributors…

Cannot retrieve contributors at this time

116 lines (74 sloc) 3.748 kb
OTP Supervision tree:
====================
The application is now split in two (see tsunami-inside.png for an overview):
** a single controller (tsunami_controller)
* ts_mon (gen_server). Each client send reports of stats to this
server. Several types of messages are handled by ts_mon.
* ts_timer (used by ts_client_rcv when ack is global) (gen_fsm)
servers used to construct messages:
* ts_req_server (gen_server) can generate messages extracted from an external file
* ts_msg_server (gen_server)
* ts_user_server (gen_server) used by ts_launcher and jabber_* for unicity of users id
** several clients (tsunami) Several nodes can be used simultaneously
This application is simpler:
* ts_launcher (gen_fsm) launch simulated users.
* 2 process per simultated client (ts_client, ts_client_rcv), under
the supervision of ts_clients_sup ( using simple_one_for_one )
Main modules:
============
1/ ts_launcher. the master process that spawns other simulated clients:
1.1/ client processes: at each simulated client correspond 2 erlang
process:
a/one that will initiate TCP (UDP) connection and will send
messages (ts_client module). These processes are spawns by
ts_launcher (using an sleeping time between two clients
following an exponential distribution).
b/ Each of these process will spawn a new process to handle
incoming data from the server (ts_client_rcv module).
The total number of clients (NCLIENTS) can be changed in the
config file. It represent the total number of clients that
will be launched, and not the maximal simultaneous number of
client.
Warning: All the messages for a user session are computed by
ts_launcher, just before spawning the user process (in a
list). Therefore, if the number of messages is huge, it can
takes A LOT of memory. If you want to do very long experiments,
use a single 'dynamic' messages (see jabber_dynamic and
Jabber.txt for an exemple), which will be send over and over by
the user.
Important parameters for Jabber :
1/ chat messages size, in bytes (250 by default)
2/ mean time elapsed between two consecutives messages sent by a user
3/ number of messages sent by a user during a session
1.2/ monitoring process (ts_mon)
2/ statistical module (ts_stats)
3/ a generic module for building user sessions (ts_profile)
4/ protocol-specific modules (jabber_online or ts_http, for example).
How to add a new protocol, or extend an existing one:
====================================================
A protocol has to implement the API defined in profile.erl, ie.
must implement these functions:
- get_client/2
- get_random_message/1
If you have to parse the responses from the server, two other
functions has to be implemented:
- parse/2
- new_session/0
References:
==========
- Erlang
http://www.erlang.org/
Design principles:
http://www.erlang.org/doc/r7b/doc/design_principles/part_frame.html
- Jabber
http://docs.jabber.org/general/html/protocol.html
- Stochastics models:
For more details on stochastics models and application to Web
workload generators, take a look at:
Nicolas Niclausse. Modélisation, analyse de performance et
dimensionnement du World Wide Web. Thèse de Doctorat (PhD), Université
de Nice - Sophia Antipolis, Juin 1999.
http://www-sop.inria.fr/mistral/personnel/Nicolas.Niclausse/these.html
Z. Liu, N. Niclausse, C. Jalpa-Villanueva & S. Barbier. Traffic
Model and Performance Evaluation of Web Servers Rapport de
recherche INRIA, RR-3840 (http://www.inria.fr/rrrt/rr-3840.html)
Jump to Line
Something went wrong with that request. Please try again.