First off, thank you *so much* for that detailed explanation comparing with
a real-time application performance benchmark, which was really enlightening
for me.
> How are you handling concurrency? (Are you using FOR SHARE on your
> SELECT statements? Are you explicitly acquiring table locks before
> modifying data? Etc.) You might be introducing blocking somehow.
No, actually am not explicitly locking any tables -- all are *simple*
select, update, insert statements only.
> In particular, I recommend that you *never* leave transactions open
> or hold locks while waiting for user response or input.
Again, we're not leaving any transaction opens until for any user responses,
etc.
> When you hit that issue, there is not a continual slowdown --
> queries which normally run very fast (a small fraction of a second)
> may periodically all take tens of seconds. Is that the pattern
> you're seeing?
Yes, you're correct. Queries those normally run fast are becoming slow at
the time of this slowdown.
> Besides the outdated PostgreSQL release and possible blocking, I
> would be concerned if you are using any sort of ORM for the update
> application. You want to watch that very closely because the
> default behavior of many of them does not scale well. There's
> usually a way to get better performance through configuration and/or
> bypassing automatic query generation for complex data requests.
Am not able to understand above statements (...any sort of ORM for the
update application ...) clearly. Can you help me in understanding this?
