List:MySQL++« Previous MessageNext Message »
From:Warren Young Date:May 14 2010 3:40pm
Subject:Re: problem while handling concurrecy
View as plain text  
On May 14, 2010, at 2:09 AM, anindh thomas wrote:

> if the number of such
> operations increase, the delay is also increasing,which compromises my purpose.
> I tried to find the cause of the delay and it seems that the select statement is
> taking too much time (in range of 10-20 milliseconds).

Are you sure a remote RDBMS server is the right tool for the job?  If someone came to me
saying they had many processes all trying to update the same few values in an overlapping
fashion, and that these updates all needed to happen in a sub-ms time scale, I wouldn't
recommend any remote SQL DB.  

There's a lot of overhead in the remote RDBMS server model.  You have IPC to send the
query, SQL query string parsing, ACID-compliant disk updates, and more IPC for the reply.
 Cramming all that into less than 1 ms -- I assume you're looking for at least an order of
magnitude improvement -- is tough.

Best if you can find a way to do without some of these things.  Don't actually need SQL? 
You can use a DB with a binary data format to save the parsing time.  Don't actually need
IPC?  You can use an in-process DB, then.  Don't actually need full ACID compliance?  You
can probably use an in-memory DB, possibly with occasional flushes to disk.
Thread
problem while handling concurrecy anindh thomas14 May
  • Re: problem while handling concurrecyJonathan Wakely14 May
  • Re: problem while handling concurrecy Warren Young14 May