On 06.10.2006, at 23:12, Stephen Deasey wrote:
On 10/4/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 03.10.2006, at 01:01, Stephen Deasey wrote:
I was also wondering about the ns_proxy send/wait/receive. Why are
wait and receive separate commands?
Because you can wait, get the timeout, do something and then go
repeat
waiting. It makes sense. You can't achieve this with a longer wait
timeout OR with a timed [ns_proxy eval].
Allright, you can argue: one can [ns_proxy receive proxy ?timeout?]
in which case you have the same behaviour. Correct. But what
difference
would it make, really?
Two commands make it twice as hard to use. All that's needed is a
timeout switch:
set result [ns_proxy wait -timeout 10 $handle]
Either way is OK. send/wait/recv is straight foward
and simpler if you usually HAVE to wait, whereas
send/wait_with_receive is more optimal if you mainly
don't need to wait (i.e. you tolerate indefinite block).
Don't forget: options are OPTIONS. Options should be
used optionally not regularily. Or?
The caller has a time budget. That's the total amount of time they're
prepared to wait for a result.
Yes. This is the -evaltimeout limit.
The underlying implementation may break the process down into sub
tasks, but the caller doesn't really care, or know about this. If you
look at the sub-tasks you might be able to say what a reasonable
timeout might be. But note: this is an optimisation. A single time
budget works for all the different sub-tasks, a special timeout for
some sub-task only allows that task to *fail* quicker.
Yes. This is the intention. If you set -recvtimeout to 1000
and -evaltimeout to 10000 then you will wait for _something_
to come over up to 10000 msecs BUT if after 1000 msec you
GET first byte of response you are prepared to wait max 1000
to get all bytes. This is very fine-grained. Because if you
do not get all bytes within 1000 msesc, you might not trust
the comm-channel (it may got severed). So what is the point
of waiting longer? In the current implementation this is
of course ridiculous: the comm channel is a pipe. But if
we ever get this done over sockets, ite becomes quite important.
It's not free though. You get the odd effect of failing with a timeout
when there's plenty of time left in the budget.
Right! Because part of the communication link might be severed.
Although your budged allows you to wait more, what good would that
be? See the above example.
The error handling is also weird. As it's currently implemented,
there's a different error code for each kind of timeout failure.
This way the programmer knows EXACTLY what happened.
The
caller is forced to deal with all the different ways a timeout might
occur. With a generic NS_TIMEOUT errorCode this can be skipped, but
now you're loosing information.
Yes. You are loosing the valuable info about the source of the error.
I think it needs to keep stats on the different failures, with a
ns_proxy_stats command to track it. This is the data you will use to
help you size the pool according to load and server ability.
This is a good idea. Such "counters" are mostly
usable in tuning and optimizing. I agree to that fully.
It's interesting to note that an individual error may not actually be
an error. The goal is to size the pool according to resources
available for maximum performance. If a caller times out because there
are no handles, well maybe the system is doing it's job?
On the other hand, if 80% of the callers are failing dues to timeout,
well then you have a problem. Maybe your pool is undersized, or maybe
your server is overloaded. It's the percentage of failures which
determine whether there's a problem with the system.
Yes. The statistics are most needed for corrrect tuning.
A single concept of timeout with statistics kept on failures would be
easier to implement and describe, would prevent spurious timeouts, and
would allow administrators to size the proxy pools.
I would leave all those timeouts for fine-grained tuning
and I would add statisctic counters for analisys and monitoring.
