Difference between revisions of "Server Beta User Group"

From Second Life Wiki
Jump to navigation Jump to search
Line 17: Line 17:
** The only change compared to SLS is a single crash fix
** The only change compared to SLS is a single crash fix
** [[Release_Notes/Second_Life_RC_BlueSteel/13#13.02.21.270686]]
** [[Release_Notes/Second_Life_RC_BlueSteel/13#13.02.21.270686]]
* Aditi is experiencing a partial outage in the inventory system
** This is preventing ~40% of users from logging in
** The ops team is working on this issue


=== Upcoming Stuff ===
=== Upcoming Stuff ===

Revision as of 14:48, 28 February 2013

This is the meeting tracking and progress page for the weekly Server BETA QA Meeting, moderated by Maestro Linden. Please contact him on AGNI for more information. You can join the Second Life Beta group for updates.

The next meeting is Thursday, February 28 2013, 3PM PST at Morris🖈 on the preview grid, ADITI.


Agenda

Updates

  • Aditi is experiencing a partial outage in the inventory system
    • This is preventing ~40% of users from logging in
    • The ops team is working on this issue

Upcoming Stuff

  • The DRTSIM-194 channel has code for threaded rez changes
    • The blocking bug has been fixed, so this project might be a contender for RC next week
  • Some interest list bug fixes are in the works

Upcoming HTTP Improvement Project

Monty is here to present some upcoming HTTP changes for the simulator. Here are the features:

  • More complete and more correct headers on texture and mesh fetches.
    The asset fetch responses, involving texture and mesh fetches, are fairly straight forward. More headers and correct headers will be returned. Viewers will begin to receive the following:
    • Age
    • Cache-Control
    • Content-Encoding
    • Content-Language
    • Content-Length (for meshes)
    • Content-Range (for 206 responses)
    • Content-Type
    • Etag
    • Expires
    • Last-Modified
    The 'Content-Type' for assets will start showing as image/x-j2c and application/vnd.ll.mesh for images and meshes, respectively. Old service behavior will still be present on the grid for a time. And as with HTTP in general, any of these headers may disappear or change in structure or meaning as permitted.
  • Keepalive connections for some HTTP-based services
    The behavioral change for HTTP connections marks the beginning of support for persistent (keepalive) connections. Services transiting the capabilities router, at ports 12043 and 12046, may honor a request for keepalives and keep a connection open after request completion. These services may include such activities as texture and mesh fetching, event delivery to viewer, HTTP-In for LSL scrips, asset uploads and inventory operations. Benefits from keepalives include immediate and future throughput increases and less TCP connection churn (which often disrupts consumer-grade networking equipment).
    The exact set of services that will see this is expected to change over time. There will also be various fairness mechanisms put in place to distribute resources under competing demands. These will come into play dynamically as needed.
    To simulate extremes of environment in which to test viewers and external services, we intend to configure a few special channels on Aditi. These will be one- or two-simhost channels with special configurations. Simulated environments might include:
    • Maximum optimism/trust. Keepalives everywhere.
    • Rapid keepalive timeouts. Keepalives honored but timed out and connections closed 'quickly'. Probably on the order of one second.
    • Punitive fairness. Harsh policy of connection rejection used to keep excess connections out. Requests will fail with 503 and have to be retried. This will likely not produce a workable channel but we're interested in testing.
    Viewer developers can begin to test compatibility with the broader possibilities on the grid. Look for retry and recovery failures in your viewers. Test for asset fetch throughput, particularly for textures. Improvements or any worsening of historical HTTP problems (DNS failures, seed capability failures, etc.).
    Scripters will want to test for general reliability in reaching their running scripts. Particular HTTP client technologies will need to be tested against connections that are broken after a completed request declares that a keepalive will be honored. (Python's httplib is one that may need some special effort to effect a recovery.)

HTTP Improvements 2013-02-28 SBUG.png

Interesting Stuff

Any Other Items

Open Items

Minutes from Previous Meetings