[TAP] sync vs async - time outs

[Alex Szalay]

I REALLY LIKE THIS APPROACH!!! 

In practice we found that the following numbers work pretty well

	Instantaneous <  1 min
	Interactive	  < 15 min
	Beyond that it should be async

--Alex

-----Original Message-----
From: Guy Rixon [mailto:gtr at ast.cam.ac.uk] 
Sent: Wednesday, March 04, 2009 5:13 AM
To: Gerard
Cc: dal at ivoa.net
Subject: Re: [TAP] sync vs async - time outs

Perhaps a mapping campaign is needed. if we can work out the
minimum timeout that is generally imposed by the network -
a sort of worse-probable value - then we can say to TAP implementors
"make it work faster than this in all cases or you need an async mode".

Cheers,
Guy

On 4 Mar 2009, at 08:42, Gerard wrote:

> Dear Dave
>>> Guy wrote:
>>>> However, I see no reason why a TAP installation that
>> always operates
>>>> quickly has to have the asynchronous mode. I would be
>> happy for the
>>>> asynchronous interfaces to be made optional; but only on the
>>>> understanding that most TAP services will need them and that
>>>> software authors be prepared to add them when that need
>> is discovered.
>>>>
>>> I support this, but think we should let a service specify what they
>>> think is "quickly".
>>
>> In practice 'quickly' is controlled by the settings on all
>> the various network routers, switches and proxies handling
>> the connection between client and server.
>> A database server may take 25 seconds to think about a
>> complex query, but if one of the network switches handling
>> the connection thinks 20 seconds is an appropriate timeout,
>> the response will never arrive.
>>
> Point well taken.
> This is indeed the main problem I have encountered.
> Queries that require a complete scan through a table to be  
> completed before
> obtaining any result, for example
> when calculating aggregate quantities, have timed out because of  
> session
> timout settings on proxy and web servers.
>
> There clearly is a place for /async.
> Another motiviation for implementing it is because it makes it
> easier/possible to queue jobs.
> It seems that "I/O concurrency" scales much worse than linear.
> Being able to queue requests so that at most a few access the same  
> disk at
> the same time seems better for performance.
>
> Thanks
> Gerard