Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future
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. ___ 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
Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future
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 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 rea
Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future
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 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 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. Wh
Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future
On 3/14/2013 9:46 PM, Darien Caldwell wrote: > 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. That only scratches the surface of the issues involved. Even for viewer-to-grid, there are a dozen or more independent variables. > 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. It's a different communication path. llRequestURL and llRequestSecureURL are part of the service also called 'HTTP-In'. The HTTP server is in the script, the client is a non-viewer entity running out on the net. This path transits the gateways and so may be impacted indirectly (DRTSIM-203 channel) and directly (DRTSIM-203H channel) and is worth testing for those who've built services on them. ___ 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
Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future
Sure, it's all HTTP. But the issue as LL has been representing it, is not that the region can't handle the traffic, it's that the clients (the residents on their viewers) can't. I could see a blanket throttle if Regions were the problem, maybe. But The whole point of what LL has been doing is to limit the # of connections the clients require. That should in fact free up even more overhead for things that don't face the user at all, such as scripts. Not that they need more, from what I see they do quite fine as they are. (though there are more Squid failures than I like to see. :P ) So I'm a little confused. On Thu, Mar 14, 2013 at 7:33 PM, Ricky wrote: > 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 >> 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 >>>
Re: [opensource-dev] HTTP connection changes heading to Aditi in the near future
Are these regions on the Main grid or Beta grid? I can find MeshTest2 on both grids, but the server version is 13.03.04.271238, so I'm not clear that this is the correct server version. Also TextureTest2 on beta seems to be closed off. On Thu, Mar 14, 2013 at 5:13 PM, Monty Brandenberg 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
