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.caldw...@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 <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 >
_______________________________________________ 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
