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

[Ricky]

AFAIK Script -> External HTTP Server, Script -> HTTP Script Server
(llRequest*URL), and external client -> HTTP Script Server (llRequest*URL)
all use HTTP traffic in and out of the region server.  Also, again AFAIK,
many objects/textures/&c. are now being sent across HTTP to the connected
viewers.  The common thread here: the region handling HTTP connections.  If
those get throttled, anything using HTTP-based communication (viewers,
scripts, &c.) all get impacted.

Ricky
Cron Stardust


On Thu, Mar 14, 2013 at 6:46 PM, Darien Caldwell
<darien.caldwell at gmail.com>wrote:

> 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
>>
>
>
> _______________________________________________
> 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/a0438a9e/attachment-0001.htm