WhiteCoatSyndrome wrote: »…did anyone actually notice any performance improvement on the PTS? I didn’t, but I allow as that might be my internet connection, which is terrible.
spartaxoxo wrote: »First. This is not a thread to discuss AWA. Please do not discuss it at all here. There are multiple threads that already exist for that. This is also not a thread to discuss whether or not these changes are worth it. That all belongs in the existing AWA threads.
This is a question mostly for the dev team, though anyone is obviously free to discuss perfomance alone in this thread. What exactly are the performance issues this change intends to solve? What will this allow you to do in the future? Does this have to do with console support? What do you mean it allows the game to be performant in the future as the most important aspect?
Essentially the game is a database. Our characters are constantly requesting information from the server for various things which include our inventory when we look at it and our achievements for times we look at it or other things that require achievements.
By reducing how much information that queries go through it reduces the load on the server which in effect improves performance.
BlossomDead wrote: »It is a matter of querying the databases per character rather than per account which is more consuming in terms of resources. Nothing more complicated than that.
It eases bit the load on the backend and probably will speed up char load. Multiply that with millions of accounts and it might be a significant gain.
I would take a guess that this is pretty much because they are moving account and character data to some kinds of 'cold storage' options, which means much lower storage but higher I/O (read/write) costs. So reducing the need for I/O's means overal improvement of 'performance' costwise. From the point of view of individual players this probably won't yield any measurable benefits performancewise.
nightstrike wrote: »spartaxoxo wrote: »First. This is not a thread to discuss AWA. Please do not discuss it at all here. There are multiple threads that already exist for that. This is also not a thread to discuss whether or not these changes are worth it. That all belongs in the existing AWA threads.
This is a question mostly for the dev team, though anyone is obviously free to discuss perfomance alone in this thread. What exactly are the performance issues this change intends to solve? What will this allow you to do in the future? Does this have to do with console support? What do you mean it allows the game to be performant in the future as the most important aspect?
I guarantee the performance difference is negligible. It's just not how databases work.
nightstrike wrote: »spartaxoxo wrote: »First. This is not a thread to discuss AWA. Please do not discuss it at all here. There are multiple threads that already exist for that. This is also not a thread to discuss whether or not these changes are worth it. That all belongs in the existing AWA threads.
This is a question mostly for the dev team, though anyone is obviously free to discuss perfomance alone in this thread. What exactly are the performance issues this change intends to solve? What will this allow you to do in the future? Does this have to do with console support? What do you mean it allows the game to be performant in the future as the most important aspect?
I guarantee the performance difference is negligible. It's just not how databases work.
it actually can be how a database works.
read access is sped up considerably if data is kept in memory. the bigger the database the less of it fits in memory (for same server/amountofram)..
same for indexes and memory..
if we just look at achieves db. in my case reduction of data is 90%. 10 uptodate u33 chars..
10chars->1account..
nightstrike wrote: »On the database side, there are cache layers, multiple indexes, backend optimizers, different kinds of optimized views... there are so many facets to a good database design that simply deleting a few records is like throwing a pebble into the ocean. And any database like this will be monotonically increasing, so this is, at best, a pebble thrown into an ocean that's rising (hi, melting ice caps!)
I guess the things that I don't really understand from the perspective on getting performance gain, are things like...
"Number of achievements" were mentioned, and adding more, so from a lines in the database existence they are all still there. Character and date would be more of an attribute, no? So how would this even help with the size as the achievement still needs to exist to be able to get on the account? Every character and the UI and everything all still HAVE the line there.
Same thing with logging it or having it pop up. The game must have to check if the achievement is blank or not when the action is done in game... right? Anything that still IS an achievement will need that checkpoint, which means it will be read the same amount of times as now.
Plus, the data still needs to be logged somewhere if the Zone Guide is supposed to be the solution for tracking progress, so... where is that data living?
Seems to me like maybe it would have been better to completely remove certain types of achievements to address the issue. For example, one of the #1 achievements mentioned as "grindy" are the trophy ones. Remove those and give anyone who got them some crowns or something. Achievements that acknowledge stepping into a DLC. I like the "kill x number of x" in dungeon achievements, but maybe let's get rid of all of those, if it is an issue with having to watch for each kill. If we're deleting data, anyway...
Completely serious, btw. Wouldn't deleting some achievements altogether, and phasing those type of achievements out forevermore, be much more helpful in terms of increasing/maintaining performance and allowing more to be added?
nightstrike wrote: »spartaxoxo wrote: »First. This is not a thread to discuss AWA. Please do not discuss it at all here. There are multiple threads that already exist for that. This is also not a thread to discuss whether or not these changes are worth it. That all belongs in the existing AWA threads.
This is a question mostly for the dev team, though anyone is obviously free to discuss perfomance alone in this thread. What exactly are the performance issues this change intends to solve? What will this allow you to do in the future? Does this have to do with console support? What do you mean it allows the game to be performant in the future as the most important aspect?
I guarantee the performance difference is negligible. It's just not how databases work.
it actually can be how a database works.
read access is sped up considerably if data is kept in memory. the bigger the database the less of it fits in memory (for same server/amountofram)..
same for indexes and memory..
if we just look at achieves db. in my case reduction of data is 90%. 10 uptodate u33 chars..
10chars->1account..
It would only do that if they loaded every character's data into memory when you log in every time with any character, which is crazy.
It shouldn't make any significant difference except for a small amount of storage (say 15 million accounts, average 5 toons, O(1000) achievements so around 75GB even if they really inefficiently use 1 byte per achievement). As far as data throughput goes it's the same. There's only ever 1 toon loaded in per account at a time so it makes no difference whether you're updating 1 account-wide achievement data blob or 1 character-wide achievement data blob. If there's a performance aspect to this, it probably means some aspect of data storage is being done fundamentally wrong. It would be better to separate the 2 issues, roll data architecture fixes into the general "year of fundamental fixes" plan and hold off on AWA until a future update later in the year when a better approach can have been defined, preferably with more consultation about what the player base actually want from AWA (I guarantee its not loading a new toon to find all your maps marked as complete with no way of telling what delves etc. that specific toon needs to complete just as one example).
nightstrike wrote: »spartaxoxo wrote: »First. This is not a thread to discuss AWA. Please do not discuss it at all here. There are multiple threads that already exist for that. This is also not a thread to discuss whether or not these changes are worth it. That all belongs in the existing AWA threads.
This is a question mostly for the dev team, though anyone is obviously free to discuss perfomance alone in this thread. What exactly are the performance issues this change intends to solve? What will this allow you to do in the future? Does this have to do with console support? What do you mean it allows the game to be performant in the future as the most important aspect?
I guarantee the performance difference is negligible. It's just not how databases work.
it actually can be how a database works.
read access is sped up considerably if data is kept in memory. the bigger the database the less of it fits in memory (for same server/amountofram)..
same for indexes and memory..
if we just look at achieves db. in my case reduction of data is 90%. 10 uptodate u33 chars..
10chars->1account..
nightstrike wrote: »nightstrike wrote: »spartaxoxo wrote: »First. This is not a thread to discuss AWA. Please do not discuss it at all here. There are multiple threads that already exist for that. This is also not a thread to discuss whether or not these changes are worth it. That all belongs in the existing AWA threads.
This is a question mostly for the dev team, though anyone is obviously free to discuss perfomance alone in this thread. What exactly are the performance issues this change intends to solve? What will this allow you to do in the future? Does this have to do with console support? What do you mean it allows the game to be performant in the future as the most important aspect?
I guarantee the performance difference is negligible. It's just not how databases work.
it actually can be how a database works.
read access is sped up considerably if data is kept in memory. the bigger the database the less of it fits in memory (for same server/amountofram)..
same for indexes and memory..
if we just look at achieves db. in my case reduction of data is 90%. 10 uptodate u33 chars..
10chars->1account..
That's what tiered caching is for.
ZOS_MattFiror wrote: »Now that the dust is settling from the launch of Update 26, I'd like to take a moment give everyone an update on what's been happening in the last week. Obviously it was one of the more bumpy releases we've had, and it's important that you all know the issues we found, what we did to fix them, and in general how things are going.
[snip]
The second problem we encountered was much more serious. Update 26 includes many new achievements, especially with a new Chapter and the new Antiquities system. This then combined with an issue where character records saved far more often than intended. These two factors together meant that save times grew over time, backing up all character loads and saves, which led to infinite load screens, timeouts while zoning from one place to another, etc. It took us a while to find the root cause and fix this one, but by Wednesday afternoon (after another maintenance that morning), it was fixed.
Wouldn't that just invite them to be removed again?wenchmore420b14_ESO wrote: »There were some responses in one of the other threads from people who actually work in Programing and Data Coding in RL who broke down the technical aspects of what ZoS was claiming on performance increase , but going back to find and quote them, I found they seem to have been removed.
I invite anyone who does coding and programing as a living to post your opinions about this. Thank You!
Just my 2 drakes.
Zephiran23 wrote: »I'm confused how this actually helps performance. As an example:
Character A has completed 90% of Daedra Slayer, characters B-D have 2-3% each so there's only a small, <1% to go. Player creates a new character to play through Deadlands. Lots of deadra in Deadlands, even more if you can't ride away from them or ignore them with Shadow Rider. In order to complete the total number of kills/account for the achievement, the server now needs to keep a running total of kills on A-D as well as the new character E.
The server also needs to keep checking for other Slayer achievements as well, for all the Waking Flame acolytes etc and whether those count for daily or weekly Endeavors - which would seem to be a separate check added relatively recently.
Yes. Indexes are just b trees stored as part of the DB, which is stored on disk. You cache a portion of that just as you cache a portion of anything else. For a system as large as ESO, the DB should be stored on some kind of layered ZFS backend with SSD R/W cache up front and some low latency access from the scaled server to the SAN (FC, IB, whatever). The "server" itself would be a cluster of servers, a few that are hosting the DB, and others that are running the individual players instances. At least in this (purely theoretical) design, the in-memory portion of the DB is pretty abstract.tiered caching works on indexes?nightstrike wrote: »That's what tiered caching is for.
we are lucky and our hot data and indexes stil fits into RAM easily enough that we can just throw more RAM at the servers. So haven't had to jump off the tiered caching bridge..
SirBedevere wrote: »They could just as easily do the Star Trek script thing and <insert tech speak here>, and it wouldn't be any less satisfying to hear.