> On 26 Aug 2018, at 15:05, Ethan Gardener <[email protected]> wrote: > > However, everything I've ever learned about databases says that it's a bad > idea to just look at the cost of the disks. The cost of *accessing* the data > (with acceptable performance) goes up exponentially with the size of the > dataset.
This shouldn't be the case; any properly indexed database should have roughly constant, or at worst logarithmic, access times for data. You should only really see big performance drops if the number of assets requests increases beyond what the hardware can cope with (i.e- too many users online simultaneously). > There is a solution which I think practically returns the problem to just > counting the cost of the disks: Cache the asset server. The actual asset > server which never deletes anything can then be very slow, with all regularly > used assets served from the much faster cache. > > I'm almost certain Second Life implemented such a cache years ago. I > remember when I logged in there after a long absence, things which I'd made > or which were old-style took minutes to rez. I don't ever remember seeing > such an effect in InWorldz, so I think it's possible InWorldz didn't have > such a cache. Most (all?) external asset requests are now served to the viewer via HTTP, so you could use Squid proxy or similar to cache those requests before they touch your asset server, it might even be possible to use a reverse proxy such as Cloudflare to do this for you, though I've never tried it (you might need to use page rules to force it to cache asset URLs). - Haravikk _______________________________________________ Opensim-users mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
