RE: [Geopriv] review comments on draft-thomson-geopriv-held-beep-00.txt

Hi Andy one quick response now.

> 
> 3) The justification for using BEEP is that multiple HTTP connections
> are bad.  Why?  Many, many multi-tier servers work this way, with the
> app server maintaining a pool of persistent TCP connections to its
> back-end database.  I remain unconvinced that this BEEP binding is
> anymore efficient for the purpose outlined than multiple HTTP
> connections.
> 

Our experience with using HTTP in the manner you describe in systems
where requests can each have a different response time is that for a
similar sized system using HTTP you get about have the peak rate of
something BEEP-like. That is not to say that you cannot perhaps tweak an
HTTP system to improve performance, but I remain unconvinced that you
can tweak to get a 100% increase in performance.

The problem is of course dimensioning enough threads and ensuring that
you don't get queuing of low-delay requests immediately after
delay-tolerant requests thereby failing to meet QoS. You also need to
avoid queuing multiple delay-tolerant requests to avoid starving.

Cheers
James

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv