[Opensim-dev] nhibernate progress, baby steps

[Brian Wolfe]

I havne't done large scale testing yet, so I dont' know the answer of
where the curve is at.

Where are you seeing cpu cost associated with using binary UUID data vs
string? I'm guessing wildly here that it's within the region servers
that you are seeing it.

My testing involved power of 10 sets of region, inventory, and prim
rows. from just 10 to 100,000,000 rows. At the 10,000 entry point I
started seeing a ~50% speed improvement in select, insert, update calls
to mysql. At 1,000,000 rows it was a factor of 800% speedup. At
100,000,000 rows it was 1000% faster. So for small data sets, string is
just fine. For larger 8+ region sets that share a central asset and
local storage server the speedups become important.

As a side note, when I did a test of using byte[16] vs string for
storing my stuff on a 4x4+2 grid I had no problems getting results back
quickly from the mysql db. If I left it as varchar, one region iwth
1,200+ prims failed to launch in time about 50% of the time. This is on
1core of athlon 4800+ w/ 384MB ram for region and 2GB for mysql on dual
core. The SQL server is shared with other web hosting systems.


I'm no longer working day job stuff, so i'm free to do some more
specific testing if you need me to.


On Thu, 2008-04-03 at 13:49 -0400, Sean Dague wrote:
> On Thu, Apr 03, 2008 at 11:19:58AM -0500, Brian Wolfe wrote:
> > *nod* sounds good to me as well. I just have one request since we'll be
> > changing things up at this level. Can we shoot for UUIDs being stored as
> > a byte[16] in order to gain the 10x speedup in SQL indexing/storage vs
> > string(32|36) ?
> 
> That's definitely an option.  It did however seem like there was some
> speedup on LLUUID processing if we kept strings.  I'm not sure where the
> two end up colliding on speedup effects.
> 
>     -Sean
>