Against "Simultaneous Logout Measures"

[Tamianth]

Oh it really worked well, didnt it.......just been booted out for the 10 mins, try to log back in after waiting to 552 in queue! Yeah. Really solved the issues.

[TaleraRistain]

Each server cluster probably runs off of the SAME code. Each shared data center resource has the SAME code. The beauty of that is that when you do a new code deploy, you can have an automated service go out and push the SAME code to every node, and the update takes minutes instead of hours.

We know this isn't entirely true. They have taken down individual servers before more than once. And you have a pretty poor system if you design it in such a way that you can't take problem pieces down to fix them and have to take the whole thing down every time there is a problem with one area. Which it doesn't appear that they do, since as I mentioned, they've taken just the problem pieces down before.

[Cure]

Logged out at 13:00 today, logged back in 13:13 and queue just over 1000. More in queue than there was at peak time last night. Omega server.

Alert over: queue going down really fast.

[Faliandra]

Oh it really worked well, didnt it.......just been booted out for the 10 mins, try to log back in after waiting to 552 in queue! Yeah. Really solved the issues.

cry me a river. I was 900 something on ragnarok, and after 5 mins im now 200 something in the queue. Oh my god. those few minutes will totally kill me.

[Ayrie]

Oh it really worked well, didnt it.......just been booted out for the 10 mins, try to log back in after waiting to 552 in queue! Yeah. Really solved the issues.

I'll say again that which has been said countless times already regarding this fact:

There are two login queues:

1) To protect the login servers from a massive influx of people hitting it at once. It gates people and allows them to trickle into the servers at a predefined rate. This queue goes fast because the underlying server processing the login is quick. But if you hit it too hard at once, it will crash, and no one will get in. Necessary evil when your player base functions like a DDoSing botnet.

2) The server capacity queue. This is the queue the measures address. Every person in the game takes up a slot. There are only so many slots before the server has reached capacity. Once that number is reached, you sit outside waiting for your slot to open up. If you've been to a busy club/bar, you would know all about fire code and occupancy limits. This one usually does NOT move fast, because someone has to leave to free up that slot. And when they're all chatting with Greg for 12 hours, or still trying to craft that hempen thread (that stuff is notoriously difficult...)... well, it doesn't create much movement in the population.

So... I guess what I am trying to say is: be appreciative that you're stuck in queue 1 and not queue 2. You're probably already in and playing...

[Lexia]

Oh it really worked well, didnt it.......just been booted out for the 10 mins, try to log back in after waiting to 552 in queue! Yeah. Really solved the issues.

Oh no you had a 552 queue that probably took no more then few minutes to get through?

[barnabyswift1]

So tell me again how this is supposed to help the login queues? Kicking everyone out has created a login queue of over 1,000 people on my servers and its only gonna get worse as peak time beings to roll around.

I love this game but holy cow, how many bad decisions are SE gonna continue to make in this frankly shambolic launch period?

[Anzaman]

Oh no you had a 552 queue that probably took no more then few minutes to get through?

It was still lovely trade of 4 seconds before mass-boot compared to 5 minutes after.

[Ayrie]

We know this isn't entirely true. They have taken down individual servers before more than once. And you have a pretty poor system if you design it in such a way that you can't take problem pieces down to fix them and have to take the whole thing down every time there is a problem with one area. Which it doesn't appear that they do, since as I mentioned, they've taken just the problem pieces down before.

So that specific and targeted server fix - that was likely done for a specific reason, by a specific person or team. That is a manual process. It was probably done for a very specific reason that was unplanned (like, a failing SAN or they lost a blade on a cluster).

I know I'm getting a little deep here, but the point is: emergency maintenance is likely just for that reason. This would not fall into "emergency" maintenance. They're not going to sit and measure server performance vs load, and then reboot the server when the performance does not equal what is expected for the load (aka: people are idle and not consuming system resources). This would be what is known as a process. A temporary process, but a process. And you want processes to be divorced from human intervention as much as possible. Humans work slower, less efficient, and more accident prone than scripts and code. If possible, you want code to handle the event.

Likely, what I would do is set up a crontab job (task scheduler) to send out notices, and then to actually kick off the reboot job. Your team then monitors the condition of the job, because this is pretty high profile and you'll want to have eyes on it, to make sure everything executes properly and then responds quickly in the event things did not go well.

I would also venture to say that Square's team is meagre in size when compared to their server footprint.

[Mikhaill]

Guess one can never truly leave Balmung, You can take the person out of Balmung but not Balmung out of the person. The game will be forever haunted by it.

This is for all the years that people hated and bashed Balmung to death lol.
Balmung strikes back! xP

The true test of AFK will be the weekend, since the game was super congested then.