Meursault wrote on Aug 3
rd, 2016 at 9:02pm:
Bad queries, poor indexing, mismanaged storage, or inadequate server provisioning might cause lag, but storing a lot of shit doesn't. It's not NP, it's not even O(N^2), it's O(N). It's trivial. If they claim it's slowing down the game, it's because they are too lazy to do it even half right.
There aren't more than 300-400 people on at a time these days, and even if each one had 100 inventory, 100 bank, 100 TR cache, and 100 Mail items, that's still not 200k objects that could be accessed. And how many of that would be at once? 10% would be ridiculously high (10% of the population opening everything they own in under a second?).
Even a mediocre DB would barely break a sweat, and that's with horribly over-estimated load. We aren't talking about an ISAM system on MSDOS, even single instance free databases today can handle 10k queries per second on off the shelf hardware.
Yup yup.
Once upon a time the quest list in the favor panel was sorted by level... then an update came... and the sort got lost and filling that screen started to takes time ( before that it was instantaneous )... it has never been fixed because they can't get their shit together enough to fix the query/view/index that got broken.
Another typical example is cannith Crafting, when you open the interface and do some serious deconstruct, you'll no tice that there's a 'lag' for the recipe to show up... it's again a brokenb query/view/index.
My guess is an index here, as it also extend to the recipe once you have deconstructed, up to the point that fropm time to time you hit the query timeout ( and get an unresponsive UI that needs to be closed and reoppened )
Now lets go in a complete domain, where people do their database stuff the right way... Long ago, a Telecom Operator phoned me and my colleagues, they had an issue with the alarm list of their early OSS system... It was taking 2 minutes to show up. ( technical note : HP 9000 D320 Server, 256Mb RAM, single PA-RISC processor, single threaded, HP-UP 10.20 with Sybase 11 for the database, 9GB SCSI HDD with Software mirrorring ( LVM and Sybase Raw Devices ) )
After a short investigation, it occured to us that the issue was the size of the active alarm list... there was more than 16 million alarms in it.
So the view used to collect the data from the database table was taking 2 minutes to collect said datas.
( with a correct index, I don't want to know with no index )
We dumped the culprit ( truncate table ) and everything became fine again ( 1-3 sec to open the alarm list, just the time for the NFS mount + software launch ). Further investigation gave us the root cause : a buggy software in the telecom exchanges the system was collecting the alarms from was sending more than 60K alarms an hour to the server. We put an automatic size control in place ( 1Day ) so that the problem wasn't going to occur again, and everything was fine.
Side note : It was still working despite the long query time... compare that to Cannith Crafting where 3 second gives you a timeout. Shitty Database programing is shitty.
TL; DR :
The overal conclusion : if 20 years ago a database donbe the right way could handle ( slowly ) 16M entries in a table with the tech from that time with today's technology no database ( Sybase, MS-SQL, Oracle, ... ) should break a sweat dealing with the datas from DDO. ( and I'm not talking of the simultaneous number of queries... I'm talking single query performances, because concurential queries is just ridiculous considering databases are designed to be optimized in that domain )
Pages: 1
TRing the snowball (Read 4534 times)
