in reply to Re^2: a IO:SELECT problem
in thread a IO:SELECT problem

Unless your MySQl server is running distributed, or on a machine that has dozens of processors, your 200 'concurrent' queries are going to be seriealised anyway.

It might be better to start a (small, 2 or 3) pool of DB worker threads in your application, and queue the queiries and results to/from the server. However you choose to do it, only 1 or 2 of your 200 queries are actually going to run concurrently, and the 200 threads/processes that issue those queries will all be waiting for their results anyway.

It's really quite hard to see what you hope to achieve by issuing concurrent queries from a client process?


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^4: a IO:SELECT problem
by ablmf (Acolyte) on Jun 26, 2006 at 16:09 UTC

    Do you mean that, the best way to solve this problem, is to have all the most frequently used data kept in the memory?

    Maybe having concurrent queries won't save the total time of query, but at least I could avoid that my server could not do anything when waiting for query result. For example, the server might process some request that do not need DB queries while other connections are waiting for DB response.