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

[Darien Caldwell]

I'm curious how a script would be expected to recover from a 'flurry of
502/503' errors? If my HTTP enabled object is expecting to communicate with
my external-to-SL server, and instead receives an 503 error, all I could
see doing is to retry. So is hammering the server with retries really going
to improve sim conditions?

Would this be expected when communicating with external-to-SL services, or
is this more likely to occur when a scripted service is trying to
communicate with another scripted service within the Grid?

As well I am not sure why scripts are being included in this at all. The
HTTP issues as I understood were the number of http connections a viewer
had to handle, with another factor in that mix being the particular router
the resident uses and how well/badly it handled multiple HTTP connections.
Service to service communcations such as a script to an external server or
a script to another script shouldn't be a contributing factor in these
viewer connection problems. The connections should never be hitting any
viewer.

                                                       - Dari


On Thu, Mar 14, 2013 at 5:13 PM, Monty Brandenberg <monty at lindenlab.com>wrote:

>
> 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:
>       - TextureTest2.  High texture count, no meshes, low residency limit
>       to prevent interference when doing benchmark testing.
>       - (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.
>       - TextureTest2H.  Identical to TextureTest.
>       - (Coming soon)  MeshTest2H.  Identical to MeshTest2
>        - DRTSIM-203A.  Our 'Angry' channel with stricter and preemptive
>    enforcement of limits (generates many 503 errors).
>       - TextureTest2A.  Identical to TextureTest.
>       - (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.
>
>
>
>
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130314/a6ce5a2b/attachment.htm