When the DB table is write only, with no other activity then the performance
has shown to be about the same. It's when other update/read activity
happens to the table during the normal operations that the journal receiver
will outperform the database. That's with no indexes other than a primary
key constraint on the physical table. I suspect more indexes and other
activity will slide the performance advantage to the journal receiver in a
hurry, but I have not tested that.
On a P7 system with about 20 DASD units/2 cores/128GB memory running about
60% CPU and average disk busy in the 8% -- 9% range. Almost all SQL based
data access with about 5% record level access.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Nathan Andelin
Sent: Wednesday, March 23, 2016 1:34 PM
To: Midrange Systems Technical Discussion
Subject: Re: Track all records read from a table
I've tested it on production servers with heavy volume. It performs
about the same with the journal entry having a very slight edge.
Thanks for adding your benchmark experience. Could the slight performance
advantage of writing to a journal be due to the database writes updating
both physical and logical files simultaneously?
Irregardless, when addressing the performance concern, the performance of
queries should be considered too. In most applications, reads outnumber
writes by a multiple number. And more often than not, read performance is
dramatically improved with appropriate keys.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
midrange.com
