When Benchmarking Goes Bad

For some reason, the benchmarking utility has started going into an infinite loop whenever I run it. Any fixes I try mess up the sample collection (e.g. out of 5000 successful XHRs in one loop I got 12 data points). I don't exactly know what changed--I certainly haven't touched the benchmarking code (though I re-downloaded it for good measure), and I got two successful benchmarks out of it (read: two on each client for a total of six) after the last change I made to the server, meaning it was definitely working. The oddest part is it's still receiving good data from the server. I've tracked the received data several times, and it's dynamic with what the sensor is seeing.

Whatever is happening here, it's clear that I can't be certain of the reliability of any of my previous benchmarks until I figure out what's wrong.


UPDATE:
Apparently I've found some means of controlling the number of requests again. Everything seems to be an order of magnitude slower now, though, which is moderately irritating.

UPDATE 2:
Apparently this is only really an issue over localhost. Walter slowed some, but that's more likely to be a result of network traffic in our lab than anything else (~2ms slower than usual). Dragon had the same time as usual. It's only on localhost that I'm forced to sit through ~6000 requests with a slowdown of an order of magnitude--meaning that the Air on localhost is about as slow as Walter concerning asynchronous sever calls. I'm going to keep looking into this.

Cloud of Computers

When trying to define cloud computing, it's fairly easy to be confused. The simplest explanation I could find is that something as simple as a Google search using cloud computing principles. The principle being you, the user, is using Google's many connected computer network to search for cat images, check your email, or type up your blog. This is also known as SaaS (Software as a Service) where software is not stored/ran locally on your computer. As a student, it's much easier to type up a quick document in Google's text editor as opposed to waiting for Microsoft Word to open up. Also, email via SaaS is the only way I know how to access email! Even if you use an email client, like Thunderbird, you still are drawing data from servers that handle emails like software data.

Preliminary Results

So far, I've conducted benchmarks on my MacBook Air, Walter (the lab's Pi running Raspbian), and Dragon6 (one of the CS lab computers running Ubuntu). The results are telling me that data transmission times involve negligible server turnaround time--I feel confident saying this because the different client computers are averaging different amounts of time.

Air: ~.8ms
Walter: ~1.1ms
Dragon: ~.3ms

Walter and Dragon are running on ethernet, and the Air runs over wifi. The Tactonic server is also situated on the Air, so it has been running on localhost. What all of this seems to indicate is that transmission time is largely client-bound.

In previous AJAX-based web pages that tried to render the Tactonic device's data in "real-time" I encountered a noticeable lag when I set AJAX requests to occur at intervals less than 100ms. Based on the data above, this behavior may be more on the browser-end, dealing with replacing currently displayed content. At that point it becomes a client-side issue of optimizing rendering.

Testing will continue into next week due to a late start on Walter and the Dragon machine.