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 <mo...@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
