[opensource-dev] HTTP connection changes heading to Aditi in the near future

[Monty Brandenberg]

We now have three channels and a number of regions available for testing:

  * DRTSIM-203.  Normal release intended to go to Agni supporting
    keepalive connections and other changes.  Regions:
      o TextureTest2.  High texture count, no meshes, low residency
        limit to prevent interference when doing benchmark testing.
      o (Coming soon)  MeshTest2.  High mesh count (many distinct mesh
        assets which all look the same), few textures.  Low residency
        limit to prevent interference when doing benchmark testing.
  * DRTSIM-203H.  Our 'Happy' channel with more generous limits and
    optimistic service controls.
      o TextureTest2H.  Identical to TextureTest.
      o (Coming soon)  MeshTest2H.  Identical to MeshTest2
  * DRTSIM-203A.  Our 'Angry' channel with stricter and preemptive
    enforcement of limits (generates many 503 errors).
      o TextureTest2A.  Identical to TextureTest.
      o (Coming soon)  MeshTest2A.  Identical to MeshTest2


Test regions share object and texture references so if you are trying to 
measure download rates or really exercise the network, you'll need to 
defeat caching.  Typically with a restart and manual cache clear or your 
own preferred method.  Aditi is also hosting some of the server-side 
baking work and you may not get a reliable avatar appearance unless you 
use a Sunshine project viewer.

What we're looking for on these channels:

DRTSIM-203.  HTTP issues generally.  HTTP texture download reliability 
and throughput.  Script writers using *llRequestURL* and 
*llRequestSecureURL* should try to get an A/B comparison going between a 
normal 'Second Life Server' region on Aditi and DRTSIM-203.  
Particularly with competing traffic like large texture or mesh 
downloads.  Scripts aren't getting a boost with this work but they 
shouldn't be adversely impacted.  Mesh also isn't getting a boost this 
time but, again, negative impact should be avoided. Third-party viewer 
developers should test for overall compatibility with all HTTP services.

We're interested in reports of regressions in any areas.  We *are* 
expecting more 503 errors (0x01f70001) in log files as it will be 
possible to push requests faster than before and certain throttles will 
be hit.  As long as these are recoverable, they're not a regression, 
they're an indicator of better utilization.

DRTSIM-203H (Happy).  Scripts and mesh do get a boost here and other 
limits are generally raised.  This may increase the tendency to get 503 
and 502 (0x01f60001) errors in some areas.  Again, these aren't 
regressions as long as they're recoverable.  Subjective and objective 
comments on Mesh and scripting behavior are sought here.

DRTSIM-203A (Angry).  This channel deliberately restricts resources and 
uses a punitive enforcement policy that should result in a storm of 503 
errors.  Viewers are expected to recover from these. Scripters can use 
this to test against a (reliably unreliable?) grid to see if they're 
handling recovery well.  A higher error rate and lower throughput and 
availability are expected here.  What is being tested is viewer and 
script robustness in the face of constraints. A more rigid enforcement 
policy, if tolerated by external software, might actually allow us to 
set higher limits if we can pull back when required.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130314/827257c9/attachment.htm