multi-threaded

[joonstar]

they say mysql is "multi-threaded".

what does "multi-threaded" mean?

[raf]

maybe i can best explain this by comparing it to single thread applications.

In a single thread application, each new request/job from another user, must be handled by another instance of that program. So if i had a single-thread application that computes some statistics, and i have 10 users that request a statistic, then this program will be openend 10 times. Like if you would open internet explorer 10 times.

If it's a mutli-thread app, it will only be opened once. (If you look at your running processes, MySql there wil be only running once. All 10 request will be handeled 'simultaniously' by this app. (of coarse, the processor can only handle one request at the time, but it'll do some of the steps from request 1, and if he needs to wait for input, will do a bit of request 2, then again from request 1, then request 3 etc. )
MySQL (in any case, the more recent versions) also allow multi-processing, which means you can have more then one processor handeling request from multiple users on 1 instance of MySQL.

Does this make any sense?

[joonstar]

Yes, that make sense.
However, I am still in doubt about this.


quote
--------------------------------------------------------------------------
All 10 requests will be handeled 'simultaniously' by this app.
--------------------------------------------------------------------------

Because the 10 requests are requested by 10 users, the point of the requesting time would be different from each request.

That means, I can think, that the first requester should wait
until the last requester click the summit button.

"open IE 10 times" was a interesting comparison.

[raf]

Because the 10 requests are requested by 10 users, the point of the requesting time would be different from each request.

That means, I can think, that the first requester should wait
until the last requester click the summit button..

Think i kinda confused you (or that you are confused). Hitting the submitbutton and so is not relevant.

Say a user (user 1) of your webapplication loggs in and submits the loginpage, the webserver will proces it and make a connection to the MySQL dataserver (--> a 'virtual' server). It will run a query to select the users with that password and username. This is a request. Say another user hitted an 'order now' button at the same time (user 2). The webserver will load another page, and make a db-connection to insert some records. Etc etc.

All these calls to the MySQL server are handeled in the most efficient way, so they don't hinder eachother and responsetimes are as low as possible. It looks simultanious, but the processor will only treat bits and pieces of each request. If all processes for user 1 are finished, the resulting data (is sent instantly to the webserver which sends it on to the browser). The dataserver doesn't wait until other processes for other users are finished.

All this goes really fast (0.01 sec or so for regular selects on smaller tables).
I believe MySQL can handle about 550 simultanious users with responsetimes under 1 second. But all this sort of benchmarking highly depends on db-structure, number of records, executed statements, buffering and caching- parameters.

But it's nothing you need to worry about. For most apps, MySQL standard setting do the trick quite well. (For a free db, it's superb!)

[joonstar]

thank you for your kindness