Summary appears to be wrong.
"...were able to deduce that Voyager was traveling through a less dense medium — i.e. interstellar space."

Interstellar space is apparently 40 times more dense than space in the solar system. The solar wind pushes the particles back to the edge of the solar system, making the plasma more dense at the edge (not less dense).

To quote from NASA
http://www.jpl.nasa.gov/news/news.php?release=2013-277
"Voyager 1's plasma wave instrument detected the movement. The pitch of the oscillations helped scientists determine the density of the plasma. The particular oscillations meant the spacecraft was bathed in plasma more than 40 times denser than what they had encountered in the outer layer of the heliosphere. Density of this sort is to be expected in interstellar space."

Old news, they have had wireless devices in coconuts for years. Maybe they are expecting better antenna diversity from the rough end of the pineapple, I dunno.
See, http://goo.gl/VoirWo

Yes, in all probability.

The $150 Edge-of-Space Camera: MIT Students Beat NASA On Beer-Money Budget.
http://www.wired.com/gadgetlab/2009/09/the-150-space-camera-mit-students-beat-nasa-on-beer-money-budget/

I don't get it.
Why spend $375 million sending a camera to the moon only to return such poor quality images?

I looked a dozens of them, they all seem small, grainy, out of focus and black and white. (of course the moon being mostly grey might explain this last point)

Couldn't they afford a better camera? My smartphone would have done a better job.

We have done the actual benchmarks, and the original post matches our experience.
PHP gives processing times of around 1 second (for a search function) and C++ code via a CGI gaves times of 0.1 sec. A ten times improvement.

Graphs and numbers are here,
http://www.wrensoft.com/zoom/benchmarks.html

Further when we switched to FastCGI we saw another 5 fold improvement, after optimising the code for FastCGI.

So I would believe a 50 folder improvement should be possible by going from PHP to FastCGI (and rewriting code to suit a FastCGI)

We are the developers of the Zoom search engine.
http://www.wrensoft.com/zoom/

We have spent some time recently looking at the problem if indexing large amounts of data, for see,
http://www.wrensoft.com/zoom/support/faq_large_sites.html

Many people above have recommended using external appliances, or external hardware. This doesn't make sense in our opinion. Using an external indexer that crawls your files means that 1) You are loading up your network, 2) You are limited to network bandwidth speeds (rather than SATA or SCSI data transfer speeds) 3) You have the overhead of the HTTP protocol.

What makes sense is to run the indexer on the server that is hosting the files and index them directly off the disk. Don't spider them, and don't do it across a network. This can save you many days of indexing time.

But with this much data, I don't think there is any really quick solution. Whatever you decide to do is going to take some setup effort.

As pointed out in this New benchmark Chrome doesn't perform so well when using an independent benchmark. One of the most popular and commonly used test suite is SunSpider. It is worth noting that this is developed by the WebKit team (WebKit being the rendering engine in Safari and now, Google Chrome). So the benchmark being used was created by the developers of the JS engine. So it is hardly surprising that they do well in their own benchmark.