I am a little confused as to why I cannot transfer over MY OWN characters from other servers to the current server I am on. Currently on Benediction, the server is locked, I understand the reasoning, but what I do not understand is why I can’t transfer my own toons over to Benediction. I can only log onto 1 toon at once, adding more toons of the same account to the server won’t increase the number of ACTIVE users playing.
5 Likes
I’m with you there. I had toons I didn’t finish leveling on Faerlina before Wrath launch. I can make 9 more toons but I can’t transfer a toon there? Lolwut? Make it make sense.
1 Like
That is exactly what happened with me. Toons on Faerlina, I just moved them over via the Free-Transfer, because as stated in Blue Posts - “Free Transfers won’t give you the 90-day cooldown”… Makes no sense to me.
The database is overloaded, so the server is locked.
You’re not the only person that this is relevant to — if transfers are allowed for people that already exist, that can worst case scenario multiply the stored data for characters/banks/mail/AH/etc by up to… what’s the char limit per realm? 10x?
TL;DR: having increased offline chars is still a problem
This is not the reason. If I previously had a toon on Faerlina, I can still create toons even though the server is locked. I can create up to 9 additional toons. It’s not a DB issue, that’s not how this works. This is a server management issue and a poorly executed one at that.
I am aware currently existing accounts with a toon on a locked server can create more level 1s. If everyone created max amount of level 1s and started posting to the AH, you’d run into the same issue. Fortunately most people aren’t interested in doing so. Transferring a max level toon is more engaging/lucrative, so there is less opportunity cost, making it more likely.
It is literally a DB issue. Please go read the myriad of blue posts discussing it in detail before pulling more misinformation out of your rear.
I agree — this should have been caught by blizzard before it spiraled out of control. Their current monitoring/forecasting tools/methods were obviously ill prepared, and needed a more active hand.
Bump, it makes no sense I have characters stuck on other realms just collecting dust.
The original problem was not outlined to be a DB issue, that was stated later on. The original reasoning for the ‘Locked’ servers was due to the lengthy Queues and Blizzard wanting to prevent further addition to the Queues, which would not be a representation of any type of DB Overload.
I can completely understand how a DB Overload would lead to a prevention of migration of characters onto the server, but the problem with this here issue will be that the toons will always be there, unless transferred off. Queues can die, due to inactivity of the server, yet the toons will still be in the DB, so that right there tells me that its not solely a DB overload, but Blizzard just wanting to prevent more Queues.
So again, me transferring a character from another server, would not affect the queues in any manner, thus they should allow transfers for characters who have a max level character on the server.
This has nothing to do with a limitation of a DB. Your statement was Blizzard is blocking moves because of a DB, you’re wrong. You’re so wrong that your in a different universe. I’m an engineer dude and this is not the issue.
yea it has nothigin to do with storage of data and a little to do with many people having to be updated with many other poeples actions O(N^2) also it actually probably has little to do with that too its mainly just a cash grab imo
I think you’re missing the point—
Queues were the reason for the locks.
Why do queues happen? Because having more players logged in at the same time puts too much strain on the server DB, causing severe performance issues for all.
More concurrent players is a larger increase in DB strain than more offline characters, but both affect the outcome.
Correct — concurrent player queues are not affected by the offline player count (although they can be correlated — statistics question with % likelihood of playtime based on number toons per account on realm, etc).
However, the DB contains offline player data, such as guild info, ah entries, mailbox, etc.
I’ll give a crude example:
How long does it take to find one specific persons phone number in a 1 page phone book?
Vs
How long does it take to find one specific persons phone number in a 4,000 page phone book?
When you’re talking about multiple background processes and scripts with O(n^2) or higher complexity, the total data set being parsed affects the outcome significantly.
Since when did engineers start managing RDBMS?
I’m sure it’s completely irrelevant to you that I manage and maintain databases as part of my job.
I can only lead you to water; I can’t make you drink. I’d suggest you audit a Data Management course at the nearest university if you’d like to come back with some prerequisite knowledge.
I have a level 33 on benediction.
Why can I transfer more characters into benediction?
There goes like 10000 players going back to Benediction.
It 100% is irrelevant, because as a platform/devops engineer who’s worked on sites at scale, I can tell you the blocking of xfers from one server to another server when you’ve already toons there is not the result of db capacity. If you’re a DBA and believe this, I’m going to say you’re bad at your job.
The code base to support a concurrent number of players and offer a stable experience is the limiting factor, not the ability to store information about your character in a db.
So are you simply going to ignore the queries that run on that DB to pull data? You know, data that exists regardless of whether that character is online or not? Which I explicitly mentioned in my previous replies?
Edit: why do you keep mentioning the storage size? Processed data != storage. We’re not talking IOPs here… we’re talking big O times on data set sizes.
This is not your first failure in reading comprehension that I’ve seen. If you truly do the work you claim, I hope you have someone else verify that you actually understand what you’re doing before you make changes.
Sincerely, good luck.
Edit: you know, I’ll actually take this one as a failure of communication on my part.
This does not refer to storage size
Here’s where the misunderstanding is. More stored data == longer function times based off the big O of the script in question, which is directly correlated to how many players can be online at a given time. I did not state that ‘blizzard needs bigger hard drives’, but I can see where you may have misinterpreted that.
db writes and reads r clearly not hte case here and btrees logarithmically reduce stuff. only thing youc an get off here is maybe concurrent transacitonal db writes but they dont occur for vidoe game.
if there is sa limiting facotr its gonna be backend O(n^2) actions of players in communicatioon range iwht each other
Increased function/query times increases load (in general), which decreases server performance (on a large scale). I’m currently assuming the maximum concurrent players before queueing is a static number, because being dynamic makes the calculations more complex and difficult to follow.
Ergo (very simplified, limited example of my point):
X active players cause Y load
Queryable data set increases → increase in function parse time → increase of load (Z)
X active players now cause Y + (X*Z) load
Edit: yes, players communicating with the server and each other is always the largest factor, which I’ve stated multiple times. Queryable data sets are a smaller but still significant factor.
what things involving the db are a function of the # of players?? almost nohting except on auction house and those trans dont have to be concurent. you either have the gold and you can buy or not. this isnt if my thing can sell for 100 to player A and my other thing can sell for 200 to player B then if and only that i make this purcahse for 300 from player C. this isnt dekkers/petersons/optimistic db transactional.
draw a graph of relations if you want to get good at dbs. its like some type of algebras (dont udnerstand much personally)
whenever dependencies blow up as a function of more players than it becomes a problem but here its jsut reads which are logarithmically reduced by btrees
Yes, I am going to ignore this and I’m going to try and explain this to you like you’re 5 years old. I hope this helps. This is a ‘server management’ issue and not a db issue.
We need to make sure that we understand what the term ‘locked server’ mean and how it’s being applied to players.
Locked Server:
- A state in which players are prohibited from transferring characters from a different server onto the locked server.
- A state in which players are prohibited from creating new characters on a server in which they previously did not have a created character.
When a player creates a new character on a server, they are effectively creating a new account on that server. The server allows a player to create up to a maximum of 10 characters per server.
Servers have limits in which they are no longer capable of sustaining a X number of concurrent players. There can be db design problems, if the original db was built to only support a maximum number of rows in a table. The engineers, not designers, who work at Blizzard are incredibly smart. They may not play the game like players do, but these people aren’t dumb. This is something that can be retooled. This isn’t going to be the prohibitive component to allowing players to connect to the game. This is a separate issue. This is due in part but not limited to: machine resources and code base.
(Note: Modern databases are able to scale and handle capacity of millions of concurrent users. A good example would be the number of people who are able to concurrently use Facebook, Twitter, TikTok, and Instagram. Each of these applications relies on the ability to fetch data.)
When a server has reach capacity, a login queue is formed, this creates a bad experience for the player. There are more players with characters on the server than there are number of allowed connections at any given time. Players have all sorts of hours they play. Allowing more accounts/characters to be created than you can actually support is really common across all kinds of applications, not just games.
Blizzard made the decision to allow players who did not wish to fight the Queue Boss to transfer their character to a less populated server. The idea here is to repopulate a lower populated server and give that server a more healthy player base. This elevates two issues (or at least it tries to)
- It reduces the queue times for players
- It increases the player base on a lower populated server
What this does not address is that people, being people, gravitate towards engagement with people they already know. So, they are going to want to go back to where they believe the action is. The lower populated server doesn’t always end up benefiting from server transfers.
So, why isn’t this a database issue?
If I as a player on ‘locked server’ have a toon that I xfer’d but still have toons on the locked server, I can create up to 10 total. When I log into the server, I can only play 1 toon at a time.
If I xfer a toon from a different server, I am reducing that servers player population, which has an impact on that server.
If I xfer a toon to a new server, and I log into that server, it is NO different than if I had created a new toon or used a pre-existing toon and logged in. The same number of people are going to be logged in.
Server management is incredibly difficult. You have to make sure that logged in players have a good experience. That’s why you cap the number of concurrent users. Trying to get people to populate and fix server health issues is very, very difficult. Players resent being pushed into something that they don’t have control over.
I hope this explanation helps you better understand what’s going on here.
your slightly wrong there are many small cases of n^2 with the db on large servers. for example u need to read the equip other players are waering and the more players there are the more players u will see at once that u wil need to read. but honestly this is probably not a big deal