Difference between revisions of "Server Beta User Group"

From Second Life Wiki
Jump to navigation Jump to search
Line 23: Line 23:


=== Upcoming Stuff ===
=== Upcoming Stuff ===
* Monty's simulator HTTP changes are (partially) ready for testing on Aditi
* A round of interest list bugfixes looks ready for RC next week
* A round of interest list bugfixes looks ready for RC next week
** Includes a fix for the infamous BUG-1814 vehicle region crossing issue, along with the 'sim teleporter' bug.  
** Includes a fix for the infamous BUG-1814 vehicle region crossing issue, along with the 'sim teleporter' bug.  
* Nyx Linden is planning another server-side baking pile-on test for Aditi this week, after SBUG
* Nyx Linden is planning another server-side baking pile-on test for Aditi this week, after SBUG
** The viewer to use for next week's pile on test can be downloaded from [[Project_Sunshine-Server_Side_Appearance#Source_code_.26_build_links|here]].  The build number to test is 271419.
** The viewer to use for next week's pile on test can be downloaded from [[Project_Sunshine-Server_Side_Appearance#Source_code_.26_build_links|here]].  The build number to test is 271419.
==== HTTP updates to simulator, from Monty ====
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 TextureTest2.
** (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 TextureTest2.
** (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.


=== Interesting Stuff ===
=== Interesting Stuff ===

Revision as of 14:23, 14 March 2013

This is the meeting tracking and progress page for the weekly Server BETA QA Meeting, moderated by Maestro Linden. Please contact him on AGNI for more information. You can join the Second Life Beta group for updates.

The next meeting is Thursday, March 14 2013, 3PM PST at Morris🖈 on the preview grid, ADITI.


Agenda

Updates

Upcoming Stuff

  • A round of interest list bugfixes looks ready for RC next week
    • Includes a fix for the infamous BUG-1814 vehicle region crossing issue, along with the 'sim teleporter' bug.
  • Nyx Linden is planning another server-side baking pile-on test for Aditi this week, after SBUG
    • The viewer to use for next week's pile on test can be downloaded from here. The build number to test is 271419.

HTTP updates to simulator, from Monty

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 TextureTest2.
    • (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 TextureTest2.
    • (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.

Interesting Stuff

Any Other Items

Open Items

Minutes from Previous Meetings

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Server_Beta_User_Group&oldid=1177301"