Author: blue

If you have no interest in the technical side of Second Life, feel free to skip this article.

I run Squid to cache textures, mesh, and other assets that the Second Life servers asks the viewer to fetch to render regions and avatars.  You can read all about using Squid with Second Life via Firestorm’s website.  It’s quite a lot of technical work to set up, and I wouldn’t recommend the casual SL user attempt it.  However, if you have the spare computer resources and know what you’re doing, it can speed up rendering of frequently visited regions tremendously, and save on bandwidth too.

As I’m a software geek, I have an engineering mindset, and let me tell you, we engineers love to measure things.  So once Squid is set up, you can use something like Calamaris to measure the performance of the external cache.  Here’s a screen shot of my performance statistics for just over a week.

I’ve highlighted the interesting numbers in yellow.  I did 567764 requests (asking SL to send me a texture or a mesh, etc) and of those, I found 373864 assets already in my cache, giving me a “Request hit rate” of 373864 * 100 / 567764 ~= 65%, which is pretty good!

Even better are my bandwidth savings.  Without Squid doing its thing, I would have loaded nearly 14.5 gigabytes of assets.  As it was, I loaded less than 2 gigabytes, saving me over 12.5 gigabytes of download.  I saved 87% of my bandwidth requirements!  And Squid estimated my “browsing” performance improvements were a 671% speedup.  That’s pretty cool!

I said “even better” at the start of the last paragraph, but saving bandwidth is exactly what I’m tuning for.

There are a lot of knobs and switches in the Squid configuration file.  Depending on which cache replacement policy you choose, you’ll get either more cache hits or more bandwidth savings.  I’d rather have large assets like mesh instantly load and then perhaps take a little longer to texture.  You can achieve this by tweaking the cache settings after seeing what the cache performance does on average.  That’s why I said at the start that you have to know what you’re doing 🙂

No interest in scripting?  You might like to skip this article 🙂

For those of you who have done any advanced programming in LSL, you’ll know that one of the big things missing from the language is that there is no persistent storage mechanism.  For example, you can read a notecard, but you cannot write one from script, so there is no way to store information that will survive a script reset unless you resort to using an external database via http (or other depreciated) functions.

All that might be about to change, as Rider Linden has just created a wiki page called LSL Linkset Data, in which he describes a set of LSL functions for writing, reading, and deleting up to 64K of key/values pairs associated with a linkset.  The memory to support this is not associated with any script memory, so it will survive script resets.  It will also survive object copy and the transfer of the object to a new owner!

This is very exciting news!  Using http to talk to a script on a webserver is slow, and programming it is cumbersome and difficult to debug.  This new functionality is something we scripters have been dreaming of for years.  Let’s hope it’s not just a proposal but the real deal!