[sldev] Proposition of cache improvment

[Philip Rosedale]

Hi Laurent.  Yes, this is definitely a direction LL intends to go - 
blocking together large groups of objects into blocks of data for 
sending/caching.   At present we basically handle prims in an atomic 
fashion relative to culling, interest lists, transmission and caching.  
By grouping them together we can speed the system up.  Challenge (as you 
point out) is that there are lots of considerations and the optimal 
block size is larger than a single prim but smaller than a sim of prims. 

But yes I agree this is the right direction.


Laurent Laborde wrote:
> Friendly greetings !
>
> I'm still worried about cache performance, and come with an idea \o/
> I'm still using this lovely I-Ram for my Secondlife cache. (it's a
> pci-e card with ram slot, and act as a sata hdd, *GOOD* performance)
>
> But... from time to time i have this annoying "greyness" in recently
> visited sim that are supposed to be in cache.
> I don't believe that is because of a slow disk (it's an i-ram)
> I think that :
> - the client request the prims "map" of the sim.
> - then the client request each texture uuid for each prims.
> - it check if it's in cache, if not, it request the texture from LL server.
>
> I got the idea of  declaring a "static object" feature (this prims
> never change and you can cache the texure uuid in a "prims cache").
> But it's not so good.
>
> I found that a lot of crowded sim rarely change, and we could save *a
> lot* of server ressource AND increase user experience.
>
> THE(!) Idea  :
> 1) when you log into a sim, the sim send it's "state_uuid".
> 2a) if the client have this "state" in cache, it can load  (almost?)
> everything from it's own cache.
> 2b) if not, it use the normal procedure (but still using the good(?)
> old(!) texture cache of course)
> 3) everytime something change in the sim, a new state uuid is
> generated and sim cache is discarded.
>
> if( isInCache(state_uuid) ) {
>    LoadSimFromCache();
> } else {
>    LoadSimFromServer();
> }
>
> that's the basic idea. it probably need a lot of tunning. Eg :
> - apply that to set of prims instead of whole sim ?
> - don't cache any scripted object ? (because it may contain texture
> change function (e.g : vendor)
> - add some estate option for tuning/controling the cache behaviour on this sim ?
> - add a "static" property to unscripted rezed object ?
>
> My sim is very static and see 500~1500 unique visitor/day (up to
> 45000+ traffic in very good day).
> It's a shame to use a lot of ressource on something that could be
> efficiently cached (Sysadmin Inside (tm) )
>
> *hugs*
>
>