It’s always fun to watch performance graphs for the sandboxes – especially combat sandboxes. Here are a few:
Here are two combat sims – Bannockburn is actually a resident-owned combat sim, but is incredibly unpopular.
A standard sandbox:
By comparison, here’s the one I have my chunk of land in:
It’s not really as suitable for servers as my PI was. Since my PI no longer exists, that’s largely besides the point.
Note that all of these graphs are live-updating, so they’re going to change. If they happen to be stable when you read this, trust me that it’s an anomaly. 
My mailserver seems to have died, and I don’t have time to fix it now (gragh!)
Anyone who wants to mail me therefore cannot do so at the usual firstname at thisdomain, and should thus do so at firstname at tslemporium.com, which is working fine right now.
This also means the TSLP pics address is dead.
…but they’re broken. At least partially.
Anyway, TG concurrency is now marked in dark orange on the frontpage image (it’s the flat line at the bottom), and all sims now get a graph like this:
More coming soon! (And I need to work out why the numbers seem to be ±1).
My TG stats are currently being worked on, so I can add detailed data about TG concurrency, and also the number of people on any given sim at any given time.
Just need to wait for this maintenence script to run…
85B42B8 = 140,198,584...
Converted 1 instances of 85B42B8 to 140198584.
85B47DA = 140,199,898...
Converted 3 instances of 85B47DA to 140199898.
85B5DF1 = 140,205,553...
Converted 1 instances of 85B5DF1 to 140205553.
85B8413 = 140,215,315...
Converted 4 instances of 85B8413 to 140215315.
Once that’s done I can restart the concurrency collector (a libsecondlife bot permanently connected to my sim checking the map) with the new system in place, and do interesting stuff with the data.
Off-topic sidenote: Thanks Tateru!
P.S. the script finished running while I was typing this. It had to convert ~970,000 values, which took it 1,089 seconds.
The domains various computers in my house resolve most often:
- a.root-servers.net
- sim3464.agni.lindenlab.com
- www.google.com
- rcw.wc24.wii.com
- 141.7.156.61.in-addr.arpa
- weather.wapp.wii.com
- news.wapp.wii.com
- secondlife.com
- faeriedevilish.blogspot.com
- dwellonit.blogspot.com
The wii.com ones are my Wii doing its WiiConnect24 stuff. a.root-servers.net is a root DNS server. sim3464 is (currently) my sim, Foobar Salad. faeriedevilish.blogspot.com is Mariel’s blog, and dwellonit.blogspot.com is Tateru Nino’s blog. Both blogs are pinged by my RSS reader every twenty minutes.
This is what an update rolling across the Teen Grid looks like. It cuts out for a few minutes (seconds in the animation) where my sim goes down, causing everything to appear online:
We’d also like to that Katharine Berry who has created an effective system for tracking performance stats for the ~100 TSL sims. Displaying the comparative measurements in a series of web-based charts has already resulted in our ability to identify one item’s brief autorez that was regularly and noticeably affecting one region’s performance. I know that Katharine’s tools will be of great help going forward.
Yay. That’s from the February edition of the Second Opinion (published in late March for some reason). I doubt they’ll ever actually use the system again, but eh.
[17:20 GMT] This is now resolved.
I am aware that stats.katharineberry.co.uk is giving 404 errors when you try and view data for certain sims; mostly private islands. This is happening because the links to those pages didn’t previously exist. As part of the database load reduction yesterday, I have removed the checking whether these links should be generated in the first place; this has resulted in a roughly 10,000% speed improvement on generating that page.
No data has been lost where those 404s were, it’s just sending you to a page that never existed, but wasn’t linked to before.
I have an idea for fixing this without having to hammer the database, and (assuming it works) will implement this tonight.
I’m also aware that nobody actually cares enough for it to be worth me making these posts in the first place.
[21:30 GMT] The issues are resolved, I think. Woo!
[21:15 GMT] Most parts of the stats gathering are up again; still working on the individual sim pages (sim graphs are fine) and the average stats graph. I think it might be dumping data too… >.<
[20:59 GMT] HUD Thingies have been re-enabled. Work on the database to avoid excessive load is ongoing.
[20:31 GMT] The problem is not currently occuring, but the system causing it to happen has been disabled; that is, the one that regenerates the pages on the stats site. I’m working on it.
[19:20 GMT] The problem has been located and is being investigated.
[19:03 GMT] The problem is happening again. Still looking into it.
[18:54 GMT] After several hours of maintenance, the server is back up. “Maintenance” meaning updating things and reconfiguring things.
Performance data during the downtime has been lost, but SL data has been logged successfully. This shows that the performance logger is bugged; this will be looked into. (It’s supposed to keep the data whenever it’s recieved, regardless of whether it can be processed yet.)
I’ll keep an eye on it and see if it breaks. Fingers crossed it’s been restored now! >.>
There are 4,312,447 rows of sim stats on record.
My statistics continue to move along, and (mostly) don’t crash my server. Almost 5,000,000. Woo. Also, we’ve passed the highest ever concurrency (and still rising), at over 39,000 online now. We do this roughly weekly.
So… does anyone have any idea as to what I could actually do with these numbers?
