From: Warren Young
Date: May 14 2010 3:40pm
Subject: Re: problem while handling concurrecy
List-Archive: http://lists.mysql.com/plusplus/8946
Message-Id: <65859790-1057-421F-90EA-863A6CF24906@etr-usa.com>
MIME-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

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. =20

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.=