Doug McNaught wrote:
> A very valid objection. I'm also dubious as to the utility of the
> whole concept. What happens when Sendmail refuses a message based on
> load? It is requeued on the sending end to be tried later. What
> happens when PG refuses a new client connection based on load? The
> application stops working. Is this really better than having slow
> response time because the server is thrashing?
That's exactly the point why I suggested to delay transaction starts instead. The client app allways gets the
connection. Doing dialog steps inside of open transactions is allways a bad design, leading to a couple of
problems (coffee break with open locks), so we can assume that if an application starts a transaction, it'll
keepthis one backend as busy as possible until the transactions end.
Processing too many transactions parallel is what get's the system into heavy swapping and exponential
usage of resources. So if we delay starting transactions if the system load is above the limit, we probably
speedupthe overall per transaction response time, increasing the througput. And that's what this discussion
isall about, no?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com