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 keep this 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 speedup the overall  per
    transaction  response  time,  increasing  the  througput. And
    that's what this discussion is all 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


Tue, 24 Apr 2001 13:28:13 -0500 (EST)
Jan Wieck <JanWieck@Yahoo.com>
Re: refusing connections based on load ...