Synchronous vs. asynchronous database access

Question

I want to develop a complex game with possibly thousands of functions and database calls.

I am wondering if it's really necessary to do my database queries in async. Its a pain to code, and all of my functions will need to use callbacks instead of the clean return method. Is this a normal approach?

Are coding these calls in async really that much faster, considering a MySQL database processes a single query at a time?

"MySQL database processes a single query at a time" - per connection. Mysql spawns new thread for each connection, having at least as much connections as number of cores on mysql box should increase performance. — Andrey Sidorov, Feb 20 '12 at 01:50
Why consider node.js if you arent sold of virtues of async programming? Please ensure you are not just another fanboy without due reason, please see video http://www.youtube.ug/watch?v=bzkRVzciAZg — Mâtt Frëëman, Feb 20 '12 at 02:03

score 13 · Accepted Answer · edited May 23 '17 at 12:24

Unless something changed drastically in Node.JS recently, you're pretty much forced to use async database access to scale well since all your user requests will execute on one single thread and synchronously waiting for the database will really drop your performance. If one user does a slow operation, all other users will have to wait until it's done.

Node.JS is really built for an async event driven flow, you'll get much better performance working with it than working around it.

score 7 · Answer 2 · answered Feb 19 '12 at 22:55

Asynchronous request are not faster than synchronous ones, no matter how you do them they still do the same exact thing. The only this that changes is rather you block on the request or not.

When you go with a synchronous the method that made the request will stop its execution waiting for the return of the request, only when that got through will it continue with its execution. Though when using asynchronous request, there's no need to wait for the request to complete, you can jut keep on and when it's done the callback will be called upon.

Another thing is that usually the database is the bottleneck when the application is making a lot of calls to the dbms, because of that you might want to consider using come kind of caching to reduce to load from the dbms.

score 1 · Answer 3 · answered Feb 19 '12 at 22:52

The speed of the database engine + transmission times will be pretty much the same either way. The issue is that async calls do not block the caller. Thus async arch is the way to go for any "realtime-ish" systems that need to be highly responsive to other inputs. (Such as games which should always be very responsive to the human.)

score 1 · Answer 4 · answered Feb 19 '12 at 22:54

1

The queries will be queued up at the database level in MySQL. There are lot more options if you can think of using Mongo DB for some of your data.

answered Feb 19 '12 at 22:54

Srikar Doddi

15,499
15
65
106

score 1 · Answer 5 · answered Feb 20 '12 at 00:09

Like Nitzan, you must know that "Asynchronous request are not faster than synchronous ones, no matter how you do them they still do the same exact thing."

No one talked about, but if there are a lot of users and a lot of requests, you have other solutions to limit database access :

Creating cache files

And update them by users actions or by CRON tasks.

Users informations
Users alerts
Users actions
Users inventory ...

Stocked database process

For some recurrent requests you can stock them in MySQL. Those will be executed faster than a user request.

Synchronous vs. asynchronous database access

5 Answers5