On Mon, 7 Jun 2004, Haitao Jiang wrote:
>
> Yes. The time I measure like I said is purely around
> statement.execQuery() call. Connection creation is not
> a factor here at all.
>
> My database has 1.64 million rows and 4 queries are
> all selects, which are identical in both serial and
> parallel cases.
>
> In serial cases:
> Query 0 took 590
> Query 1 took 431
> Query 2 took 461
> Query 3 took 440
>
> In parallel cases:
> Queryer 3 query took 1552
> Queryer 1 query took 1632
> Queryer 2 query took 1783
> Queryer 0 query took 1923
>
> I don't understand why in 4 concurrent connection
> cases (already created not included in the timing) it
> takes more than 3 times longer to exec. a query.
Umh... if your queries are limited by some bottleneck on the server (such
as, for example, CPU) then why would running them in parallel make it any
faster?
It seems that in the sequential case they are taking a total of 1922
(whatever those units are) while in the parallel case they are taking
1923. What this is telling you is that, in this case, a single query is
able to fully utilize the resources (likely CPU given these numbers,
although it is possible it could be disk) on the server. If a single
query can fully utilize the server, all that adding more concurrency
can possibly do is slow the total throughput down.
