Simulating Concurrent Transactions via a single job (was RE: SQL vs. traditional I/O?)

[CWilt@xxxxxxxxxxxx]

> -----Original Message-----
> From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx]
> Sent: Friday, July 23, 2004 12:48 PM
> To: 'Midrange Systems Technical Discussion'
> Subject: RE: SQL vs. traditional I/O?
> 
> 
> 
> > One thing to keep in mind is that the
> > situations in an OLTP where you need to fetch one record at 
> a time are
> > situations where user interaction is required.  That being the case,
> the
> > human wait time required is many orders of magnitude higher than RPG
> or
> > SQL.
> 
> This argument doesn't hold.  When you have thousands of concurrent
> transactions, human wait has nothing to do with it.  It's the 
> cumulative
> processing time that slows down OLTP.  Otherwise, we'd always have
> subsecond response time on everything.
> 

Joe,

I'm breaking this thread out because I see your point.  But I don't think
the results you see in the testing scenario automatically translate over to
thousands of concurrent transactions.

If each user job is doing its own I/O then its obvious that the results
don't fit.  On the other hand, if each user job is communicating to a single
sever program that is doing the work I'm wondering if the comm overhead is
going to make a difference.

I'm hoping others with more benchmarking experience will jump in here.


Charles