HTTP pipelining viewer reaches release status as CDN support is grid-wide

On Wednesday, October 29th, the Lab promoted the HTTP pipelining viewer to the de facto release viewer, a move that came just after the grid-wide deployment of CDN support on Tuesday, October 28th. While the two are complementary rather than reliant upon one another, both should help improve the majority of users’ Second Life experience to some degree.

Monty Linden: the HTTP pipelining viewer marks the culmination of over 2 years of work inproving SL's HTTP capabilities
Monty Linden: the HTTP pipelining viewer marks the culmination of over 2 years of work improving SL’s HTTP capabilities

The HTTP pipelining viewer is the latest phase of over two years of work on Second Life by Monty Linden, and which has involved both the viewer and the servers and back-end services which support SL.

The work, originally a part of Project Shining, which was itself heralded as complete in June 2014, initially focused on texture handling between the servers and the viewer. Since then, Monty has gone on to tackle a number aspects of improving the use of HTTP in Second Life, such as making connections more robust and reliable, improving throughout to the viewer via HTTP, and so on.

The HTTP pipelining viewer, as the name suggests, leverages HTTP pipelining, a technique in which multiple HTTP requests are sent on a single TCP connection without waiting for the corresponding responses, which significantly improves the download of data (currently avatar baking information, texture data, and mesh data) to the viewer. The upshot of this is that the impact of a user’s physical location on scene loading is reduced, improving their overall experience.

As well as this, the HTTP viewer includes significant improvements to inventory folder and item fetches, which can markedly decrease the time taken for inventory to load, particularly if a user’s local inventory files have been flushed as a part of a cache clearing (or similar) exercise.

These inventory updates alone are liable to be appreciated by users as the viewer-side HTTP code gains wider adoption by TPVs. Tests have shown that a decently structured inventory (e.g. one that uses a folder hierarchy, rather than everything dumped into just a handful of top-level folders) of 100K can have a “clean” load time of 16-18 minutes reduced to around 3 minutes.

Earlier in October 2014, Monty blogged on his work, showing how both the CDN and the HTTP pipelining viewer, coupled with his earlier HTTP improvements have benefited texture and mesh fetching in SL. If you’ve not read that blog post, I recommend that you do.

Monty Linden's recent blog post shows how the HTTP work has improved texture and mesh fexture within SL
Monty Linden’s recent blog post shows how the HTTP work has improved texture and mesh texture fetching within SL

As well as working on HTTP, Monty has also been engaged on rebuilding and cleaning-up many of the third-party libraries used in the building of the viewer. This work should not only improve the viewer build process and such third-party libraries are consistently used in the build process, it may also help pave the way toward the Lab producing 64-bit versions of their viewer in the future.

Continue reading “HTTP pipelining viewer reaches release status as CDN support is grid-wide”

SL project updates week 44/1: Server, CDN update

The Pines at Jacob's Pond, Jacob; Inara Pey, October 2014, on FlickrThe Pines at Jacob’s Pond, Jacob (Flickr) – blog post

Server Deployments Week 44

As always, please refer to the server deployment thread for the latest information and updates.

Main (SLS) Channel

On Tuesday, October 28th, CDN support was deployed across the Main channel, meaning that the entire grid now utilises the Highwinds CDN for texture and mesh fetching.

As the 130 regions deployed to the Snack channel were all originally from the Main channel, they have been / will be reabsorbed into that channel, and Snack will once again be dissolved.

Release Candidate Channels

On Wednesday, October 29th, all three RC channels should receive the same server maintenance project. which includes some minor improvements.

SL Viewer

There are currently two RC viewers possibly vying for promotion to the de facto release viewer. These are the HTTP Pipelining RC (version and the Benchmark viewer (version, which should put an end to the use of a manually maintained list of GPUs in order to initially set the graphics defaults in the viewer.

Both of these were updated on Friday, October 24th, which has delayed any promotion to the de facto release viewer while the Lab gathers performance statistics on both of them. commenting on the status of both during the Simulator User Group meeting on Tuesday, October 27th, Oz Linden indicated that all things being equal, the HTTP Pipelining viewer should be promoted in the next 24-48 hours. He also indicated that there may be a further round of updates to come to Benchmark viewer in the offing as the Lab continued to tweak it.

CDN: Next Steps

In the vast majority of cases, the CDN is working as expected for users. There is a very small minority who, possibly because of their geographical closeness to the Lab’s servers or possibly due to issues between their ISP and the Highwinds services, are experiencing slightly worse ping times to their nearest CDN nodes when compared with pinging the Lab’s servers directly.

Even with the deployment to the Main channel, the Lab is continuing to monitor reports from CDN closely. However, as previously mentioned in my CDN coverage, it is likely the scope of CDN usage will be expanding in the future to handle other asset data – sounds, animations etc.

Also, and as noted in my week 43 TPV Developer meeting report, an offshoot of the CDN work is that there is a belief within the Lab that viewer caching may not be working as well as it might be. Internal discussions have held on possibly validating whether or not this is the case, and it is likely some work will be carried out in this area – and may well involve TPVs.

However, where both the viewer cache and extending the use of the CDN to cover other asset data are concerned, there are no time frames currently in mind. At the moment, the focus is very much on get the new tool chain and build process for the viewer finalised and into production, and in dealing with bugs and issues. As such, it might be a while before specific work on the viewer cache and / or work on extending the use of the CDN gets underway.

On a wider front, as well as monitoring the direct effectiveness of the CDN service, the Lab will be “spending quite a bit of time and effort assessing just what the effect of this change has been on operations from a number of perspectives”, to quote Oz.

Other Items

LI Issues?

There are reports circulating of unexpected changes to Land Impact (LI) values. While the Lab hasn’t altered land accounting, there have apparently been incidents of LI suddenly increasing in builds which have gone unchanged; one instance quoted during the Simulator User Group meeting referenced a door which apparently increased from 0.5 LI to 3 LI.

There have been instances in the past of the viewer incorrectly reporting the LI for an item when it is pulled from inventory. Corrections can generally be made either by relogging or by returning the item to inventory and rezzing it again. Altering the physics shape of linksets (from prim to convex and back again) can sometimes lead to problems, particularly if a prim in the linkset is contains torturing (such as a hollow or advance cut / twisting) or a script. However, this issue appears to be new, and a cause is proving hard to identify.

As always, if you have encountered the problem, and it is both persistent and reproducible, please raise a bug report.

Graphics Profiles in the Viewer

A suggestion was put forward during the Simulator User Group meeting for the Lab to allow the saving of graphics profiles. This would mean, for example that you could have a graphics profile where various options – the quality slider, shadows, occlusion, draw distance, etc., could be pushed towards their upper limits; and another where the setting are more conservative and less taxing on your GPU / system.

Then, where you are in a region (your own, or somewhere you know), where you know you can use the higher settings, you can quickly enable that profile, but when you move on to a region where (say) there are a lot of avatars and a lot going on, you can select the more conservative profile and thus reduce the potential performance issue on your system without actually having to go through and manually adjust all your settings.

Responding to the idea, Oz suggested the idea might be best suited to being a code contribution – and there was some potential interest in taking the idea on. However, this does not guarantee the idea will be carried forward – but it will be interesting to see if the idea does move forward at all in the coming months.