===== BBB ===== === Test method === Open sessions in the browser to the bigbluebutton application in increments of 10 then 2 then 10 and so on via the following script.\\ Record SAR data for CPU (All cores), RAM and Network before and after. \\ Also, connected via JConsole tracing JVM health and resource consumption. #!/bin/bash # Copyright (c) 2008-2011 by BigBlueButton Inc. # Documentation: # http://code.google.com/p/bigbluebutton/wiki/Testing VERSION=0.1 IP=$(ifconfig | grep -v '127.0.0.1' | grep -E "[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*" | head -1 | cut -d: -f2 | awk '{ print $1}') while [ $# -gt 0 ]; do case $1 in --h|-h) HOST=$2; shift 2 ;; --n|-n) NUMBER=$2; shift 2 ;; *) echo "$0: Unrecognized option: $1" >&2; exit 1; esac done if [ -z "$HOST" ] || [ -z "$NUMBER" ]; then echo "BigBlueButton Testing Utility - Version $VERSION" echo echo "$0 [options]" echo echo "To launch BigBlueButton clients that connect to remote server:" echo " -h remote_bigbluebutton_host" echo " -n number_of_clients" echo echo "Example:" echo " $0 -h 192.168.0.104 -n 10" exit 1 fi # # We'll use a get request to demo1.jsp to create clients # # http://192.168.0.104/bigbluebutton/demo/demo1.jsp?username=Fred2&action=create # HOST="http://$HOST/bigbluebutton/demo/demo1.jsp?action=create&username=user" HOST="http://$HOST" if ! wget $HOST/bigbluebutton/api -O - --quiet | grep -q SUCCESS; then echo "Startup unsuccessful: could not connect to $HOST/api" exit 1 fi if ! which firefox >/dev/null 2>&1; then echo "Unable to locate firefox" exit 1 fi firefox & sleep 3 i=0 while [ $i != "$NUMBER" ]; do echo "Connecting user $IP-$i" firefox -a firefox -remote "openURL($HOST/demo/demo1.jsp?action=create&username=$IP-$i,new-tab)" & # We'll give BigBlueButton a moment to process the incoming request from this IP. # If we try to open 10 clients at the same time, the session IDs for each client will # likely not go to the specific tab (as thay all share the same IP address) sleep 5 i=$[$i+1] done echo === HW Configuration and Location=== == Server == 6core, 16G, 10+100G, located in Virginia, USA == Clients == #1: 4core, 8G, default hdd - SFO, USA #2: -same- - NY, USA #3: -same- - Amsterdam #4: -same- - Singapore === Results for the said configuration === == Hard limit == Max number of clients supported: 109. == Real world limits == == Audio == Test: conversation between two clients, others listening. \\ Limitation: Human ears. Only one person was available to help with the test hence only conversation between two clients. \\ 109 users: Extremely lossy audio. \\ One word barely audible out of ten spoken. \\ 84 users : Somewhat functional audio, 1-4 words loss at times out of ten spoken. \\ 62 users: Fully functional audio. No loss of words observed. \\ == Webcam == Test: Conversation between two clients, others watching and listening with webcam on. Limitation: Webcam. Only one person was available to help with the test. 109 users: Highly lagged stream, with 4-9 secs lag between frames (best case) and about 30 seconds lag (worst case). \\ 84 users: Lagged but otherwise OK stream. 1-2 sec lag between frames. Noticeable affect on Audio stream. Audio becomes lossy, 6-8 words out of ten spoken. \\ 62 users: Webcam streams fine. Noticeable affect on Audio stream. Audio becomes lossy, 1-4- words loss out of ten spoken. \\ 42 users: Webcam streams fine. No noticeable affect on audio stream. \\ === Analysis and notes === Stress test results mostly fall in place with standard performance systems used for Audio applications. |Users|CPU load|RAM|GC time| |32|3.2|300m-550m| < 2 s| |62|4.12|500m-600m| < 4 s| |75|4.58-5.01m|550-700m| <4s| |100|5.9|650m-950m|<5s| |110|6.33|750m-1.2g|<10-25s| ===== Application ===== ==== Test # 1 ==== === Command Used === ab -t 5 -n 500 -c 10 http://10.166.152.11/ where, \\ -t is the target test time. \\ -n is the total number of requests. \\ Network and associated variables were removed from the equation by executing this test on the same machine. \\ Follow up with JMeter based test while capturing data from the server itself such as CPU/RAM/IO use. \\ === Observations === 1) A clear upward trend is noticeable with increase in the number of requests over time. \\ 2) Requests per second drop by more than half when trying to achieve <5s serve time. \\ === Next Steps === Observed randomness in data captured earlier for over 2500-10000 requests per second range.A few other tests need to be done, across 2500 - 10000 range to normalize it. \\ Should check Passenger configuration and retest. \\ === Data and Charts === [[https://www.google.com/fusiontables/DataSource?docid=1vTJp7iL4JWpfJyZVSdcu0_1v6U5M0oEJlA9bz1Mk|External Link]] === April 22nd, 2014 === - Need to execute the following and capture output. Worked on doc, will execute tomm. - Check w/ Murali re: passenger config === April 23rd, 2014 === - Executed tests for the following configuration. [n=500,c=10,t=5],[500,10,],[3500,250,5],[3500,250,],[7000,250,5],[7000,250,],[10000,250,] - Also, executed following test 5 times, to capture data for sustained load: [500,10] - With any test above 200 users, the server was thrown out of LB configuration by default (as the response time increased). — Production maintenance activity: - Reconfigure Haproxy (10:10pm). Rescheduled - tomorrow. - Started at 5:30am timeout connect 5000ms server prodapp01 10.166.152.11:80 check port 80 cookie app1 maxconn 64 inter 5000 rise 2 fall 3 server prodapp02 10.166.152.19:80 check port 80 cookie app2 maxconn 64 inter 5000 rise 2 fall 3 with timeout connect 50000ms server prodapp01 10.166.152.11:80 check port 80 cookie app1 maxconn 200 inter 5000 rise 2 fall 3 server prodapp02 10.166.152.19:80 check port 80 cookie app2 maxconn 200 inter 5000 rise 2 fall 3 and revert back at (10:30pm) 6:30 am