• No results found

Performance of a Browser-Based JavaScript Bandwidth Test

N/A
N/A
Protected

Academic year: 2021

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

Copied!
7
0
0

Loading.... (view fulltext now)

Full text

(1)Performance of a Browser-Based JavaScript Bandwidth Test David A. Cohen II May 7, 2013 CP SC 491/H495 Abstract An existing browser-based bandwidth test written in JavaScript was modified for the purpose of further data collection by the CyberTiger Project. The speed test’s results were compared with those of iperf, a standard internet performance measurement tool, under various network constraints. Introduction Because the browser-based PHP speed test [1] used by the CyberTiger project provided inaccurate results, I was asked to improve the test or find or write a suitable replacement. After reviewing the existing code and comparing it with the results of various other speed tests on the Internet, it became clear that the best option was to use an open-source speed test written with node.js by Josh Erickson (Github: snoj) [2]. Despite the fact that the node.js speed test seemed to be more accurate than the one used by CyberTiger, it had issues at relatively high speeds, topping out at 20-30 megabytes per second (MBps), as noted in the project’s README file. After further optimization and the addition of features, the modified speed test was tested for its limits and its accuracy. The remainder of this paper discusses the speed test in more detail, as well as the experiments testing its accuracy and their results. Background JavaScript and node.js The server-side is written in the JavaScript language using node.js [3], a platform designed for building network applications in JavaScript. It is relatively lightweight (compared to Apache/PHP) and fast due to its non-blocking, eventdriven I/O model. The speed client-side of the speed test is written in HTML and JavaScript, using the JQuery library [4]. Server Usage The server program is run with the command node ./bin/speed.js from the project’s root directory. As soon as it starts, it starts listening for HTTP requests (in the port specified in bin/config.json, or port 8080 by default)..

(2) Client Usage Once the server is running, the speed test should be accessible in the browser at the machine’s web root (e.g. http://localhost:8080). When a user clicks a button to run the download speed test, a request is sent via AJAX (Asynchronous JavaScript And XML) with a number indicating the size in bytes to be downloaded. A response of zeros of the appropriate size is then sent from the server. This process repeats several times, starting at a download size of 0.125 MB, and doubling it in size each time until a stopping parameter—a time or size limit—is met. A similar process occurs during the upload procedure: a string of zeros is repeatedly sent via AJAX to the server. Unlike the download test, the upload tests do not double in size (although both this parameter and its counterpart for downloads may be changed in the settings). In both cases, the transfer speed is measured from the client side. If both download and upload speeds are tested, results are then sent back to the server, which adds the results to the MySQL database. It was chosen to record the maximum upload and download speed reported for any single transfer, because it is more reflective of the maximum sustained speed; the reported average of transfer speeds included small files that did not attain maximum speed due to TCP buildup. Additional Features The HTML5 geolocation API [5] was added in order to acquire the physical location of the users. If authorized by the user, data about the user’s location (accuracy, longitude, and latitude) is sent back to the server for storage in the database. This data is helpful to the CyberTiger project, and will be suitable for visualization in the project’s heatmap of connection quality. The Modernizr library is used to detect browsers without support for this geolocation API, and the script geo-polyfill.js [6] was used to acquire the position with a less accurate method. Experimental Hardware Used The server program was run using node.js 0.8.23 on a Dell Optiplex 755 with an Intel® Core™ 2 Quad CPU Q6600 @ 2.40GHz and 8 GB RAM running Ubuntu 12.04.2 LTS. The client host for this experiment was a MacBook Pro 5,2 (Early 2009) with an Intel® Core™ 2 Duo @ 2.66 GHz and 8GB RAM running Mac OS X 10.8.3..

(3) Browsers Tested There were four browsers on the client: Google Chrome 26.0.1410 (current version at time of writing) [7], Google Chrome 28.0.1499 (“Canary” development version) [8], Firefox 20.0 [9], and Safari 6.0.3 [10]. Safari and Chrome 26 both use the WebKit rendering engine (however, Safari is a 64-bit application and Chrome is 32-bit). Chrome uses Blink, a fork of WebKit currently in development. Firefox uses its own rendering engine, Gecko. Safari’s uses the Nitro JavaScript Engine, Firefox uses the IonMonkey engine, and both versions of Google Chrome use the V8 JavaScript Engine. Other Tools Used in this Experiment The tool Network Link Conditioner, a preference pane for OS X made by Apple, was used to place limits on the upstream and downstream bandwidth in order to simulate real-world conditions in a controlled environment. Additionally, the open-source command-line tool iperf [11] was used to measure throughput between hosts as a benchmark, and in order to check the accuracy of Network Link Conditioner’s throughput constraints. Procedure The client host was connected to gigabit Ethernet and plugged into AC power. All four browsers and SSH windows for controlling the server were open during the experiment. The experiment was conducted on a day with minimal congestion in order to avoid error. The performance of the network was tested first with iperf with the commands iperf –s and iperf –c <server> -fM on each the client and the server to test throughput in both directions. Speed tests were then run on each of the four browsers multiple times to test consistency and reliability. The test indices in the MySQL table and the speeds reported by iperf were recorded in Microsoft Excel. This procedure was performed without any network constraints, then using Network Link Conditioner to test download speeds limited at 780kbps, 6mbps, 12mbps, 14mbps, 48mbps, and 96mbps, and upload speeds limited at 330kps, 1mbps, 2mbps, 4mbps, 8mbps 32mbps, 64mbp, 128mbps, 256mbps, and 512mbps..

(4) Results. 30.00 25.00 20.00 15.00 10.00 5.00 0.00 Mean iperf results. Mean iperf results Mean node.js results 330k 1mbp 2mbp 4mbp 8mbp 32mb 64mb 128m 256m 512m bps s s s s ps ps bps ps bps 0.05. 0.10. 0.25. 0.48. 0.96. 1.90. 4.76. 7.50 14.80 26.63. Mean node.js results 0.04. 0.11. 0.25. 0.49. 0.95. 1.82. 3.46. 6.59. 9.77 11.61. Upload Limit, Megabits/s. iperf and node.js download speed test results under network bandwidth constraints Download Speeds, Megabytes/s. Upload Speed, Megabytes/s. iperf and node.js upload speed test results under network bandwidth constraints. 10.00. 8.20 8.53. 8.00 5.50 5.36. 6.00 4.00 2.00 0.00. 2.80 2.72 0.10. 0.09. 780kbps. 0.80 0.68. 6mbps. 1.40 1.37. 12mbps. mean iperf results mean node.js results. 24mbps 48mbps 96mbps. Downlad Speed Limit, Megabits/s.

(5) Download Speed, Megabytes/s. iperf vs node.js results without constraints. 120.00. 112.00. 100.00. 107.50. 80.00. 75.28. 60.00. Mean iperf results. 40.00. 43.99. Mean node.js results. 20.00. 0.00. Gigabit Download. Gigabit Upload. Test Result (gigabit connection). Connection Performance of Browsers and iperf on unconstrained gigabit . Speed, Megabytes/s. 120. 100. 80. 60. 40. Mean downstream performance. 20. 0. iperf. Chrome 26.0.1410. Chrome 28.0.1499. Firefox 20.0 Safari 6.0.3. Browser. Disussion The results suggest that, when constrained to low speeds, the upload and download tests are relatively accurate when compared to results returned by iperf. However, upload speeds tend to be under-reported at speeds above 32 Mbps (4 MBps). In contrast, the results of the download test remained similar to those of iperf up to 96 Mbps (12 MBps). An issue with Network Link Conditioner seems to affect the maximum download speed, because at and above 96 Mbps, results from both iperf and the node.js speedtest are inaccurate..

(6) In contrast, the test that compares the iperf and node.js speed test results without bandwidth constraints shows that iperf reports higher upload and download speeds than node.js, suggesting the node.js speed test is inaccurate at high speeds. Though it appears that accuracy degrades gradually as speed increases in the upload test, it is unknown whether this is the case for the download speed, as its results remained consistent with those of iperf for the other constrained tests. The comparison of browsers shows that there tend to be slight differences in the download results reported by different browsers at the unconstrained gigabit speeds, and that all of them are lower than the results reported by iperf. This suggests that the limits of the speed test are due at least in part to performance of the client-side JavaScript. Conclusion Though an improvement over the previous speed test, the data show that this one is not without its limits. Though the exact details of these limits are not yet known, it is shown that the test remains accurate in the browsers tested for speeds available with local ISPs (other than Clemson University). Further testing is necessary, however, to find out exactly the nature of these limits, and whether these limitations are fundamental to JavaScript-based speed tests. Future Work The future work for this project includes both further development and further testing and analysis. One possible modification is a change in implementation from AJAX-based transfers to HTML5 Websocket-based ones. Though not compatible in all browsers, it is possible that Websockets could provide more accurate results, perhaps with higher bandwidth limitations. Further testing could include more analysis of the current data, in addition to more tests being performed with different devices and browsers. Links [1] http://www.brandonchecketts.com/open-source-speedtest [2] https://github.com/snoj/speedtest [3] http://nodejs.org [4] http://jquery.com [5] http://dev.w3.org/geo/api/spec-source.html [6]  http://www.calormen.com/polyfill/#geo [7] https://www.google.com/intl/en/chrome/browser/.

(7) [8] https://www.google.com/intl/en/chrome/browser/canary.html [9] https://www.mozilla.org/en-US/firefox/new/ [10] http://www.apple.com/safari/ [11] http://sourceforge.net/projects/iperf/.

(8)

References

Related documents

Recommends to the county board and provides leadership for the development of policies, programs, initiatives or services necessary for school district progress, especially relating

For example, hollow calcium carbonate has been utilized as paper filler; hollow glass microspheres are used as fillers to improve and modify the dielectric properties of the

For the US Department of Energy (DOE) Multi-Year Research, Development, and Demonstration Plan, fuel cell systems for CHP (combined heat and power) and distributed

La resolución estableció alguno de los principios esenciales a considerar en la evaluación de un sis- tema electoral: el principio de publicidad, en tanto las elecciones representan

In March 2000, the United States government renewed the license of a nuclear power plant for the first time.. The Calvert Cliffs plant obtained approval to operate

The study of the nanoindentation response of materials in combination with real-time imaging, heating, and/or electrical measurements in situ can create a broader understanding

To use SPROG with DecoderPro you must first ensure that character echoing is disabled by clearing bit 1 of the mode word (see description of M command) using a terminal emulator

Maximální velikost, kdy na jedincích ještě probíhá evoluce a vlastnosti nejlepšího řešení konvergují k vlastnostem původního neredukovaného grafu, je závislá na