Performance of a Browser-Based JavaScript Bandwidth Test

Size: px

Start display at page:

Download "Performance of a Browser-Based JavaScript Bandwidth Test"

Amber Chandler
8 years ago
Views:

1 Performance of a Brower-Baed JavaScript Bandwidth Tet David A. Cohen II May 7, 2013 CP SC 491/H495 Abtract An exiting brower-baed bandwidth tet written in JavaScript wa modified for the purpoe of further data collection by the CyberTiger Project. The peed tet reult were compared with thoe of iperf, a tandard internet performance meaurement tool, under variou network contraint. Introduction Becaue the brower-baed PHP peed tet [1] ued by the CyberTiger project provided inaccurate reult, I wa aked to improve the tet or find or write a uitable replacement. After reviewing the exiting code and comparing it with the reult of variou other peed tet on the Internet, it became clear that the bet option wa to ue an open-ource peed tet written with node.j by Joh Erickon (Github: noj) [2]. Depite the fact that the node.j peed tet eemed to be more accurate than the one ued by CyberTiger, it had iue at relatively high peed, topping out at megabyte per econd (MBp), a noted in the project README file. After further optimization and the addition of feature, the modified peed tet wa teted for it limit and it accuracy. The remainder of thi paper dicue the peed tet in more detail, a well a the experiment teting it accuracy and their reult. Background JavaScript and node.j The erver-ide i written in the JavaScript language uing node.j [3], a platform deigned for building network application in JavaScript. It i relatively lightweight (compared to Apache/PHP) and fat due to it non-blocking, eventdriven I/O model. The peed client-ide of the peed tet i written in HTML and JavaScript, uing the JQuery library [4]. Server Uage The erver program i run with the command node./bin/peed.j from the project root directory. A oon a it tart, it tart litening for HTTP requet (in the port pecified in bin/config.jon, or port 8080 by default).

The peed tet reult were compared with thoe of iperf, a tandard internet performance meaurement tool, under variou network contraint.

2 Client Uage Once the erver i running, the peed tet hould be acceible in the brower at the machine web root (e.g. When a uer click a button to run the download peed tet, a requet i ent via AJAX (Aynchronou JavaScript And XML) with a number indicating the ize in byte to be downloaded. A repone of zero of the appropriate ize i then ent from the erver. Thi proce repeat everal time, tarting at a download ize of MB, and doubling it in ize each time until a topping parameter a time or ize limit i met. A imilar proce occur during the upload procedure: a tring of zero i repeatedly ent via AJAX to the erver. Unlike the download tet, the upload tet do not double in ize (although both thi parameter and it counterpart for download may be changed in the etting). In both cae, the tranfer peed i meaured from the client ide. If both download and upload peed are teted, reult are then ent back to the erver, which add the reult to the MySQL databae. It wa choen to record the maximum upload and download peed reported for any ingle tranfer, becaue it i more reflective of the maximum utained peed; the reported average of tranfer peed included mall file that did not attain maximum peed due to TCP buildup. Additional Feature The HTML5 geolocation API [5] wa added in order to acquire the phyical location of the uer. If authorized by the uer, data about the uer location (accuracy, longitude, and latitude) i ent back to the erver for torage in the databae. Thi data i helpful to the CyberTiger project, and will be uitable for viualization in the project heatmap of connection quality. The Modernizr library i ued to detect brower without upport for thi geolocation API, and the cript geo-polyfill.j [6] wa ued to acquire the poition with a le accurate method. Experimental Hardware Ued The erver program wa run uing node.j on a Dell Optiplex 755 with an Intel Core 2 Quad CPU 2.40GHz and 8 GB RAM running Ubuntu LTS. The client hot for thi experiment wa a MacBook Pro 5,2 (Early 2009) with an Intel Core GHz and 8GB RAM running Mac OS X

A repone of zero of the appropriate ize i then ent from the erver. Thi proce repeat everal time, tarting at a download ize of 0.

3 Brower Teted There were four brower on the client: Google Chrome (current verion at time of writing) [7], Google Chrome ( Canary development verion) [8], Firefox 20.0 [9], and Safari [10]. Safari and Chrome 26 both ue the WebKit rendering engine (however, Safari i a 64-bit application and Chrome i 32-bit). Chrome ue Blink, a fork of WebKit currently in development. Firefox ue it own rendering engine, Gecko. Safari ue the Nitro JavaScript Engine, Firefox ue the IonMonkey engine, and both verion of Google Chrome ue the V8 JavaScript Engine. Other Tool Ued in thi Experiment The tool Network Link Conditioner, a preference pane for OS X made by Apple, wa ued to place limit on the uptream and downtream bandwidth in order to imulate real-world condition in a controlled environment. Additionally, the open-ource command-line tool iperf [11] wa ued to meaure throughput between hot a a benchmark, and in order to check the accuracy of Network Link Conditioner throughput contraint. Procedure The client hot wa connected to gigabit Ethernet and plugged into AC power. All four brower and SSH window for controlling the erver were open during the experiment. The experiment wa conducted on a day with minimal congetion in order to avoid error. The performance of the network wa teted firt with iperf with the command iperf and iperf c <erver> -fm on each the client and the erver to tet throughput in both direction. Speed tet were then run on each of the four brower multiple time to tet conitency and reliability. The tet indice in the MySQL table and the peed reported by iperf were recorded in Microoft Excel. Thi procedure wa performed without any network contraint, then uing Network Link Conditioner to tet download peed limited at 780kbp, 6mbp, 12mbp, 14mbp, 48mbp, and 96mbp, and upload peed limited at 330kp, 1mbp, 2mbp, 4mbp, 8mbp 32mbp, 64mbp, 128mbp, 256mbp, and 512mbp.

Chrome ue Blink, a fork of WebKit currently in development. Firefox ue it own rendering engine, Gecko.

4 Reult iperf and node.j upload peed tet reult under network bandwidth contraint Upload Speed, Megabyte/ k bp 1mbp 2mbp 4mbp 8mbp 32mb p 64mb p 128m bp 256m p 512m bp Mean iperf reult Mean node.j reult Upload Limit, Megabit/ Mean iperf reult Mean node.j reult iperf and node.j download peed tet reult under network bandwidth contraint Download Speed, Megabyte/ kbp 6mbp 12mbp 24mbp 48mbp 96mbp Downlad Speed Limit, Megabit/ mean iperf reult mean node.j reult

95 1.82 3.46 6.59 9.77 11.61 Upload Limit, Megabit/ Mean iperf reult Mean node.j reult iperf and node.

5 iperf v node.j reult without contraint Download Speed, Megabyte/ Gigabit Download Gigabit Upload Tet Reult (gigabit connection) Mean iperf reult Mean node.j reult Connection Performance of Brower and iperf on uncontrained gigabit 120 Speed, Megabyte/ iperf Chrome Chrome Brower Firefox 20.0 Safari Mean downtream performance Diuion The reult ugget that, when contrained to low peed, the upload and download tet are relatively accurate when compared to reult returned by iperf. However, upload peed tend to be under-reported at peed above 32 Mbp (4 MBp). In contrat, the reult of the download tet remained imilar to thoe of iperf up to 96 Mbp (12 MBp). An iue with Network Link Conditioner eem to affect the maximum download peed, becaue at and above 96 Mbp, reult from both iperf and the node.j peedtet are inaccurate.

j reult Connection Performance of Brower and iperf on uncontrained gigabit 120

6 In contrat, the tet that compare the iperf and node.j peed tet reult without bandwidth contraint how that iperf report higher upload and download peed than node.j, uggeting the node.j peed tet i inaccurate at high peed. Though it appear that accuracy degrade gradually a peed increae in the upload tet, it i unknown whether thi i the cae for the download peed, a it reult remained conitent with thoe of iperf for the other contrained tet. The comparion of brower how that there tend to be light difference in the download reult reported by different brower at the uncontrained gigabit peed, and that all of them are lower than the reult reported by iperf. Thi ugget that the limit of the peed tet are due at leat in part to performance of the client-ide JavaScript. Concluion Though an improvement over the previou peed tet, the data how that thi one i not without it limit. Though the exact detail of thee limit are not yet known, it i hown that the tet remain accurate in the brower teted for peed available with local ISP (other than Clemon Univerity). Further teting i neceary, however, to find out exactly the nature of thee limit, and whether thee limitation are fundamental to JavaScript-baed peed tet. Future Work The future work for thi project include both further development and further teting and analyi. One poible modification i a change in implementation from AJAX-baed tranfer to HTML5 Webocket-baed one. Though not compatible in all brower, it i poible that Webocket could provide more accurate reult, perhap with higher bandwidth limitation. Further teting could include more analyi of the current data, in addition to more tet being performed with different device and brower. Link [1] [2] [3] [4] [5] [6] [7]

Though it appear that accuracy degrade gradually a peed increae in the upload tet, it i unknown whether thi i the cae for the download peed, a it reult remained conitent with thoe of iperf for the

7 [8] [9] [10] [11]

Mobile Network Configuration for Large-scale Multimedia Delivery on a Single WLAN

Mobile Network Configuration for Large-cale Multimedia Delivery on a Single WLAN Huigwang Je, Dongwoo Kwon, Hyeonwoo Kim, and Hongtaek Ju Dept. of Computer Engineering Keimyung Univerity Daegu, Republic