Re: 10,000 queries per second: Can it be done?

A couple of points you will need to consider -

The uniqueness of queries - as already mentioned - a major cost and bottleneck on 'new' queries is the parse time, so if every query is a different literal string you won't be able to hit 10,000 per sec. Make sure you make use of bind variables.

Connecting to the database requires dozens of messages, so plan on opening a number of servers and keeping them open to execute the queries.

Once this is done, 10,000 queries per second is not unreasonable, and you could basically use Oracle's years of buffering experience to avoid writing you own cache code. If the total data set is relatively small, then a 'small' query may be little more than identifying a pre-parsed query following by 4 logical I/Os. In which case you could address this comfortably with a large memory and a handful of CPUs.

No doubt I'm making it sound easier than it really will be, but at this point I'm only talking broad feasibility/scope.

--

Jonathan Lewis
Yet another Oracle-related web site:  http://www.jlcomp.demon.co.uk

uqmoore_at_my-deja.com wrote in message <8p8c1q$pf3$1_at_nnrp1.deja.com>...


>In article <8p8923$5bh$1_at_neptunium.btinternet.com>,

>  "Gary" <garygfx_at_hotmail.com> wrote:

>> How many unique queries are there out of the 10,000 you have each

 second?


>> I'm getting my application to store the data it gets back from the

 database


>> in memory for a definable period, so it works like a cache. Repeated

 queries


>> come from the applications memory istead of the db. Our application

 runs up


>> to 100 faster compared to hitting the db each time. I've written it

 for


>> ColdFusion - you're welcome to the code but I suspect you're using

 Perl or


>> something.

>>

>> Gary.

>>

>

>Thanks for your input Gary.  I really like the idea of using a "cache".

>I'm not sure about the uniqueness of the queries yet for I just started

>looking into this problem.

>

>We are using C.  The last time we tested compiling a large set of data

>in the C source code, we terminated compilation at the two hour mark! :)

>Since our data could get updated frequently, we have no interest in

>waiting 2+ hours for updates to become available. ;-)

>

>QM

>

>

>Sent via Deja.com http://www.deja.com/

>Before you buy.