Bill,
That is interesting. I can put in my two cents to say: we do not use a
database scenario other than the primary/secondary replication scenario.
Where primary is a single machine and receives updates. The secondary is
configured in read-only streaming replication. All of the bricks are
configured to talk to primary IP/hostname. It would seem that this patch
could bring about a speedup for us with no downside, unless I'm mistaken.
-Blake-
Conducting Magic
Will consume any data format
MOBIUS
On 3/20/2023 3:07 PM, Bill Erickson via Evergreen-dev wrote:
Hi All,
I was recently reviewing some activity logs and found these top 5 API
calls (with counts) for last Thursday:
46398 open-ils.pcrud.retrieve.au <http://open-ils.pcrud.retrieve.au>
41363 open-ils.actor.get_barcodes
33044 open-ils.pcrud.transaction.begin
32591 open-ils.pcrud.transaction.rollback
30549 open-ils.pcrud.search.atc
Way down the list I have:
452 open-ils.pcrud.transaction.commit
If I take out the ~450 begin/commit pairs, which perform real work,
I'm left with ~65k begin + rollback API calls. That's roughly 1 of
every 10 API calls that hit our system.
Not only are there a lot of them, each results in a begin or rollback
call in the database. The calls are fast and generally harmless on a
per-call basis, but they do make it to the database every time, so
they're not exactly trivial/superficial.
The begin/rollback pairs are the result of using "authoritative" data
retrieval -- calls that start a database transaction so the caller can
be sure any data retrieved comes from the primary database. This is
useful when a) data must be up to date to avoid confusion/oddness in
the UI and b) the Evergreen system is running one or more pooled
database replicas that handle live read queries -- live replicas can
occasionally lag behind with replication and return very slightly
older data than the primary database.
For sites like KCLS, where all live queries go to one primary
database, these API calls serve no purpose. (We have replicas, but
they are not part of an active load-balanced pool. They are used
instead for reporting, bulk data collection, debugging, and of course
backups).
Since these begin + rollback pairs (and ".authoritative" APIs) serve
no purpose in our environment, I was considering creating a local
patch to disable them. However, before I start patching locally, I'm
curious if there is a broader desire for deprecating authoritative
APIs? I suspect they can be turned into NO-OP's with 2 or 3
well-placed lines of code.
Do many/any of you use live, read-only pooled database replicas?
I'd love to hear your thoughts/concerns/etc.
Thanks,
-b
_______________________________________________
Evergreen-dev mailing list
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
_______________________________________________
Evergreen-dev mailing list
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
