On 07.10.2006, at 00:39, Stephen Deasey wrote:
But the call may take longer than the caller budgeted for, due to all
the hidden timeouts, which are additive.
True.
So the callers time budget is 5 seconds, and that's what they pass to
-evaltimeout. But by default both the sendtimeout and recvtimeout are
5 seconds. So the total time spent on a successful call to ns_proxy
eval could be over 15 seconds, which is 3x the time budget.
The time budget is a single target value. In the future, for the
majority of users, this is going to be set per URL. For /checkout you
may allow up to 60 seconds to serve the page before deciding you're
overloaded. For /ads you may give up much sooner. Your server is busy
and you need to shed load, so you shed the least important traffic.
For a single page with some time budget, which depends on the URL,
some of it may be used up in a call to ns_cache_eval before there is a
change to call ns_proxy eval. i.e. the time budget is pretty dynamic.
I don't see how the multiple fine-grained settings of ns_proxy can be
used effectively in the simple case of a web page with a time budget
which runs multiple commands with timeouts.
How would you handle this issue then?
Given you have 5 seconds budget to run the proxy command
and the fact that running the command involves round-trips
to some remote proxy on another host, how would you implement
that? You have to send the data to the proxy and then you need
to wait for all the data to come back. Would you break the
potentially valid request because it needs 5.01 secs to get the
last byte transfered back just because your total limit was set to
5 seconds?
If you can give a good solution, I will implement that immediately.
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.
Isn't a severed link a detectable error condition? The reaper will be
notified of the child death, or a hypothetical socket implementation
will have it's socket closed..?
Not necessarily ( a detectable condition). If the remote proxy is
on other host and somebody cuts the wire, you get no error. You
need to timeout sometimes.
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.
Right.
But what is the programmer going to differently when he gets a ESend
vs. ERecv vs. EEval? Log it and continue. Maybe I'm not being
imaginative enough...?
No, you are right. There is not much he can do except to log that
and move on. But the fact that he KNOWS what was the error he CAN
log better.
I'm not saying you absolutely can't pass this back -- the error code
could be the Tcl list {NS_TIMEOUT ESend}. I just can't see the use of
it.
Better not to bug the programmer, log the fault for statistical
analysis, and move on.
YES. Actually who logs it is not that important, just the fact
that this should be logged is important. Seeing it from this
perspective, it is really better to give a "generic" timeout
and adjust statistics rather than expose _exact_ errorcode up to
the script level. I can agree with you on that point.
Or, how about this. If it's agreed that these are fine tunings, could
they perhaps default to -1, and in that case the single timeout (which
is currently the eval timeout?) is used for everything until it runs
out?
Hmhmhm.... tempting... but would be a victim of:
I waited 1 minute for 100-byte result, got 99 of 100 bytes
and the timeout expired. I consider the request timeouted
and break. But the peer would return the last byte in perhaps
10 msec... Too bad.
Lets see what you thing about this.
But if we make this change, then we need no counters of errors at
various places because they will make no sense. Effectively
we have a budget of -evaltimeout which is divided across all
possible points where we will/must wait. A timeout expiring at
any of this point has no meaningfull information at all any more.
Right?
----------------------------------------------------------------------
---
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT & business topics through brief surveys -- and earn
cash
http://www.techsay.com/default.php?
page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
