Can’t speak for Australia as a whole, but here in WA ap-west is definitely more responsive than ap-east. ap-west has about a second of lag, ap-east more like 2 seconds.
NA-East was fastest for me. Unexpectedly, EU-West was nearly as fast (hard to tell the difference) whereas NA-West was a bit noticeably laggy. But AP-East was very laggy and AP-West was the worst of all. (I only tested NA-East and NA-West once each.)
P.
Thanks for the feedback, everyone! I plan to wind down the infrastructure over the weekend; I’ll bring the servers back up once the IFDB bits are in place.
Great data point, thanks! I wasn’t aware of the 4x multiplier. That certainly explains why it’s so sensitive to latency.
Europe would really benefit from a more centrally located server. I have this running through Amazon’s AWS infrastructure and unfortunately their only EU endpoint is in Ireland.
That experience was the motivation for this project. Given the latency factor it’s better to have a lot of local servers rather than one or two central ones. But it’s also important to have a single URL that authors can use to publish their content. tads.io is meant to address both concerns.
It’s distinct from IFDB because not everyone will want the game’s IFDB page to be the jumping off point for new players. The tads.io game servers will be linked into the IFDB network, and players that come via IFDB will be able to take advantage of the session-sharing and file storage features, but it’s entirely optional.
1 second is more or less my standard for acceptable performance. Ideally it would be under 250 ms but that’s a hard target to hit without more edge servers.
I get near-local speeds from Seattle to the data center in Oregon, around 250 miles away (400 km). A rough guideline is that you see about 1s of UI lag for every 1000 miles between you and the server. (Like any good rule of thumb, this ignores virtually every technical factor involved.)
Thanks! My guess is that EA would split the difference, so I’ll probably go with Singapore until AWS adds an Australian data center.
That is really surprising and interesting. I wonder how far west into Canada that holds true? Given equal latency, it would be better to divert the traffic to EU-West for load-balancing reasons.
Since it’s that surprising I redid the first three just to be sure. This time, EU-West and NA-West felt about equivalent – about a 1 second delay in either case. NA-East was the clear winner this time around – the lag felt more like a half-second. NA-East is probably the only one I would not find too frustrating.
Great, thanks! That’s good to know.
After spending a few days tuning performance, I’m much more comfortable with the server speed now. Average response times from my nearest server have gone from 250ms to 25ms; even with the 4x multiplier it still feels quite fast.
Please give Return to Ditch Day another try.
If you were secretly dismayed by the performance before, you should find it to be far more responsive now.
From Boston, I get responses after a long second. (Maybe over 1; definitely less than two.)
However, I should say –
I’m able to run this game in Chrome, but not in explorer. Explorer gives me no cursor, nor does clicking start the game have any effect.
Conrad.
I checked and noticed the same thing at first, though it seems to have gotten itself unstuck now.
A full second between turns is definitely on the long side. Can you try again and see if the results are any better?
Nice work Ben, this is much better than before. For standard commands it’s indistinguishable from desktop play, feels great.
I get a full second turn-around; generally less than two (although the first move did take 2-3).
Doesn’t feel like a terrible outcome to me. I feel it plays smooth enough.
Still not getting anything with Explorer, though.
Conrad.
Very fast in Northern California, using Safari on MacOS 10.6.8. Some responses are up to half a second, others much shorter.
Are people timing this with some technical method?
I’m holding my watch up to the screen and hitting ENTER just as the digits roll around to (for example --:–:50). Keeping my eye on the digits, I know the time when the response shows up.
C.
Thanks everyone for testing this with me!
re: Timing. In Chrome, you can press Ctrl-Shift-J to bring up a JS debug console. (Command-Option J on Mac.)
Inside the console, click the Network button and it will show you subsequent requests. Enter a game command in the game window and you should see five requests pop into the monitor. You can ignore the first one; that’s where you are idling between turns. The sum of the time value for the other four gives you the time it took the server to process your turn. The ideal range is 200-250 ms total.
(I can post a screenshot if it helps.)
re: Slowness. I will investigate the IE issue. I’m also seeing a slow load problem on iOS devices - it takes a few minutes to connect, though it’s quite fast once it does load. I have some packet traces to comb through but I’m optimistic this can be fixed.
Exactly my experience. It takes a long time to load on the iPad, but it’s as fast as a desktop terp between turns. (Unexpected, but very nice!)
Ok, then the delay that I notice is around-about a second. Sometimes a long second.
These are the data from the JS terminal:
348B 48.59s / 119B 55ms / 919B 98ms / 1005B 288ms / 292B 157ms / 263B 1.7min
That last one is certainly the time it took me to get organized and copy the info down. Don’t know what the first one is, but there certainly was not a 48 second lag. Don’t know where that comes from. It’s not the page load, because I cleared the network data and took this off a LOOK command.
Another:
360B 19.34s / 119B 189ms / 919B 109ms / 645B 1.20s / 292B 101ms
–Yeah, I’m not sure about that first entry. It’s a getEvent, just before the only inputLine entry.
Well, that’s the news from Boston.
Conrad.
The bracketed ones happen between turns. Your browser keeps an eye on the server to see if it has anything new to report - messages from real-time fuses & daemons, input from other players in your session, etc. You can disregard these values as it’s just the server waiting on you to do something.
When you type a command, your browser sends your input to the server (#1). Then the server replies with the new statusline contents (#2), the response to your command (#3), and then asks you for a new command (#4).
The time spent waiting for these replies should be relatively constant for the best experience. Yours ranges between 55ms and 1200ms, which is quite a large spread. 55ms from Boston to VA is about right; some of the other values are really high. It’s probably your connection, though there could be a bad router between you and the AWS network.
You can try the west coast server to see if you like it better.
Another thing to try is to open a command prompt (Start → Programs → Accessories → Command Prompt) and type:
ping -t gs-na-east.tads.ioThis will ping the server until canceled with Ctrl-C. You are looking at the “time=” part of each reply. If you see the same fluctuations here that you did in the browser, it’s definitely a network issue. If all the times cluster around the same value then it’s probably on the server end.
Heck, a bad network experience for me is when I spend 15 minutes explaining some obscure point of hypnosis that very few people understand, hit SEND and get a blank ‘Connection lost’ page that indicates my data’s gone.
A long second waiting for a text game is not a bad network experience.
Conrad.
I agree that the stakes are relatively low; most players won’t ragequit if a response here and there lags a bit. That’s life on the Internet. But if every turn is slow, I expect we’d see a lot of abandoned sessions and some frustrated players.
Fortunately we’re in pretty good shape at the moment.
I’ve finished the packet analysis and concluded that the IE issue is the same as the mobile Safari one. I have some ideas for a fix but I’m not sure what the best approach will be.
Ugh, I hate that. This is why I type out anything longer than a couple of sentences into a local text document, and only paste it into the comment/forum/whatever box when I’m done composing. Even on shorter stuff, I often compulsively copy all the text before hitting “send.” I still get hit with it sometimes, though.
[rant]I keep waiting for some super-genius to patent the idea of a page that would replace the blank, “You hit the POST button but your connection died and you lost all your data hahaha sucker” screen with “You hit the POST button but your connection died so here is the information that you just tried to post…” Then one could cut and paste it after the fact.
I also use your workarounds, but every now and then…[/rant]
Entirely off-topic there.
Conrad.