Second Life Forums Archive - Wild-a** conjecture ...

Templar Baphomet

Man in Black

Join date: 13 Sep 2005

Posts: 135

10-31-2005 19:59

Here's some wild-ass conjecture ....

I think I found a couple of technical issues that may be contributing to many of the performance problems SL is having .... um, the architecture and the platform.

I read today a second-hand account that the asset server is "running on Apache". For those systems architects in the membership ... (well, at least for this one) ... it implies that LL is running the asset server behind a web service interface. If you're in the business, you know that web services are good for interoperability and poor for performance.

I also read a help wanted ad for Linden Labs ... need an "internal web developer" experienced with the usual stuff, plus MySQL. MySQL?!?! My God, are they trying to run SecondLife using what is basically a hobbyist's database server? So, in my usual 1 + 1 = 3 fashion, I believe that the asset server (the single-point-of-failure for the entire shebang) is running on MySQL behind a web service interface.

If you're in the business, you know that's a laugh. MySQL has two things going for it ... it's cheap and it's not Microsoft. That's it. As for using a web service interface for an internal resource ... pffft!! 1. Interpreted Perl. 2. Serialize. 3. Deserialize. You only do this when you HAVE TO.

So, 1 + 1 = 3!

Aww, can't blame a guy for having a little fun, can you?

Kathmandu Gilman

Fearful Symmetry Baby!

Join date: 21 May 2004

Posts: 1,418

10-31-2005 23:29

So, what would be a better solution?

_____________________

It may be true that the squeaky wheel gets the grease but it is also true that the squeaky wheel gets replaced at the first critical maintenance opportunity.

Spuds Milk

Registered User

Join date: 28 Sep 2004

Posts: 94

10-31-2005 23:58

Well Mysql and IBM might be suprised to find out it's only a hobbiest db, And based on the number of large-scale companies using it, seems a little presumptous. PErsonally, I think using UDP instead of TCP, then reinventing TCP is a bigger mistake, but *Shrugs*

Templar Baphomet

Man in Black

Join date: 13 Sep 2005

Posts: 135

11-01-2005 00:18

From: Kathmandu Gilman

So, what would be a better solution?

2 + 2 = 5?

But seriously (not!), after my last message, you want more wild-ass conjecture? OK, no shortage of wild-ass conjecture around my house! So here's the oh-so-considered opinion from the guy who has exactly two really questionable data points. LOL

1. Distribute that asset server! Partition the asset service for the grid so if an asset server goes down, only parts of the grid go with it. Maybe something like, "old continent", "new continent", "new new continent" and "islands"? Yes, I realize that the user context will have to shift servers if teleporting or flying from one to the other. Just an implementation detail. LOL!

2. Tightly bind the data tier with the application tier for performance. Lean and mean! It's a closed architecture, right? Right, LL? (I have no idea).

3. Partition the heavily-loaded tables on the asset servers (again, I'm assuming that the asset server is a database) across multiple disk arrays with distributed views for performance gains on reads at higher load levels.

4. Cluster the asset servers (at least active-passive) for failover.

5. Improve the caching mechanism in the client ... but that's another thread ... in the Feature Suggestions forum, where I'm also holding forth on the world according to Temp.

6. The list goes on ad nauseum. I think about this crap for a living. LOL

Hey, just to be clear ... I have nothing against web services, Perl, Apache, J2EE, MySQL or any other particular platform/tool/technology. In my line of work (a contract database architect), you can't afford to be a snob about a particular technology). But a tool is most effective in its niche. A screwdriver makes a lousy tool to drive nails.

Templar Baphomet

Man in Black

Join date: 13 Sep 2005

Posts: 135

11-01-2005 00:37

From: Spuds Milk

Well Mysql and IBM might be suprised to find out it's only a hobbiest db, And based on the number of large-scale companies using it, seems a little presumptous. PErsonally, I think using UDP instead of TCP, then reinventing TCP is a
bigger mistake, but *Shrugs*

Presumptous or not, and believe it or not, I work with a goodly number of those "large scale companies" on a regular basis. For example, British Petroleum uses MySQL ... as a workgroup-class database server -- for a single application (although that application might have hundreds of seats). Not as an enterprise-level server. Same with Hewlett-Packard. Same with Best Buy. And a lot of big local government agencies, like the NYFD. Nothing wrong with MySQL.

IBM is a great example. Ask IBM what they recommend for an enterprise-level database. You think they'll say "MySQL"? You've heard of DB2? You've heard of Informix?

I don't follow your comment on UDP versus TCP. Is that something you're saying MySQL did?

Regards, -- Temp

Wild-a** conjecture ...
Templar Baphomet Man in Black Join date: 13 Sep 2005 Posts: 135	10-31-2005 19:59 Here's some wild-ass conjecture .... I think I found a couple of technical issues that may be contributing to many of the performance problems SL is having .... um, the architecture and the platform. I read today a second-hand account that the asset server is "running on Apache". For those systems architects in the membership ... (well, at least for this one) ... it implies that LL is running the asset server behind a web service interface. If you're in the business, you know that web services are good for interoperability and poor for performance. I also read a help wanted ad for Linden Labs ... need an "internal web developer" experienced with the usual stuff, plus MySQL. MySQL?!?! My God, are they trying to run SecondLife using what is basically a hobbyist's database server? So, in my usual 1 + 1 = 3 fashion, I believe that the asset server (the single-point-of-failure for the entire shebang) is running on MySQL behind a web service interface. If you're in the business, you know that's a laugh. MySQL has two things going for it ... it's cheap and it's not Microsoft. That's it. As for using a web service interface for an internal resource ... pffft!! 1. Interpreted Perl. 2. Serialize. 3. Deserialize. You only do this when you HAVE TO. So, 1 + 1 = 3! Aww, can't blame a guy for having a little fun, can you?
Kathmandu Gilman Fearful Symmetry Baby! Join date: 21 May 2004 Posts: 1,418	10-31-2005 23:29 So, what would be a better solution? _____________________ It may be true that the squeaky wheel gets the grease but it is also true that the squeaky wheel gets replaced at the first critical maintenance opportunity.
Spuds Milk Registered User Join date: 28 Sep 2004 Posts: 94	10-31-2005 23:58 Well Mysql and IBM might be suprised to find out it's only a hobbiest db, And based on the number of large-scale companies using it, seems a little presumptous. PErsonally, I think using UDP instead of TCP, then reinventing TCP is a bigger mistake, but Shrugs
Templar Baphomet Man in Black Join date: 13 Sep 2005 Posts: 135	11-01-2005 00:18 From: Kathmandu Gilman So, what would be a better solution? 2 + 2 = 5? But seriously (not!), after my last message, you want more wild-ass conjecture? OK, no shortage of wild-ass conjecture around my house! So here's the oh-so-considered opinion from the guy who has exactly two really questionable data points. LOL 1. Distribute that asset server! Partition the asset service for the grid so if an asset server goes down, only parts of the grid go with it. Maybe something like, "old continent", "new continent", "new new continent" and "islands"? Yes, I realize that the user context will have to shift servers if teleporting or flying from one to the other. Just an implementation detail. LOL! 2. Tightly bind the data tier with the application tier for performance. Lean and mean! It's a closed architecture, right? Right, LL? (I have no idea). 3. Partition the heavily-loaded tables on the asset servers (again, I'm assuming that the asset server is a database) across multiple disk arrays with distributed views for performance gains on reads at higher load levels. 4. Cluster the asset servers (at least active-passive) for failover. 5. Improve the caching mechanism in the client ... but that's another thread ... in the Feature Suggestions forum, where I'm also holding forth on the world according to Temp. 6. The list goes on ad nauseum. I think about this crap for a living. LOL Hey, just to be clear ... I have nothing against web services, Perl, Apache, J2EE, MySQL or any other particular platform/tool/technology. In my line of work (a contract database architect), you can't afford to be a snob about a particular technology). But a tool is most effective in its niche. A screwdriver makes a lousy tool to drive nails.
Templar Baphomet Man in Black Join date: 13 Sep 2005 Posts: 135	11-01-2005 00:37 From: Spuds Milk Well Mysql and IBM might be suprised to find out it's only a hobbiest db, And based on the number of large-scale companies using it, seems a little presumptous. PErsonally, I think using UDP instead of TCP, then reinventing TCP is a bigger mistake, but Shrugs Presumptous or not, and believe it or not, I work with a goodly number of those "large scale companies" on a regular basis. For example, British Petroleum uses MySQL ... as a workgroup-class database server -- for a single application (although that application might have hundreds of seats). Not as an enterprise-level server. Same with Hewlett-Packard. Same with Best Buy. And a lot of big local government agencies, like the NYFD. Nothing wrong with MySQL. IBM is a great example. Ask IBM what they recommend for an enterprise-level database. You think they'll say "MySQL"? You've heard of DB2? You've heard of Informix? I don't follow your comment on UDP versus TCP. Is that something you're saying MySQL did? Regards, -- Temp

Welcome to the Second Life Forums Archive

Wild-a** conjecture ...