Re: [Regops] draft-wullink-restful-epp-00.txt
Luis Muñoz <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
The fact that you can more efficiently pool connections will in many scenarios allow you to get away with less connections that are more long lived and potentially, with less authentications. Per command load balancing also removes the need to have gateways rerouting the requests. This function now is easier to "flatten" into the frontend. Of course I suppose mileage will carry. -lem "Gould, James" <[email protected]> wrote: >What is the basis of the claim that the proposal could be a big win in >performance? What is the fundamental performance issues today with EPP >TCP and how does REST over HTTP solve it? I heard that stateless will >provide benefits, but with SSL and authentication the approach needs to >move to a stateful (RESTful login and HTTP keep-alive) model. I heard >that there can be load balancing done per command instead of per >connection, but per command load balancing can be accomplished today >behind the gateways and there is a question of whether the gateway tier >itself is a problem area from a performance and scalability >perspective. >I heard that existing knowledge to scale web-services can be utilized, >but >the registries already have knowledge on scaling EPP services. I don't >see performance and scalability as a key driver for a new provisioning >protocol. Is there another driver for this proposal? > >-- > >JG > > > >James Gould >Principal Software Engineer >[email protected] > >703-948-3271 (Office) >12061 Bluemont Way >Reston, VA 20190 >VerisignInc.com > > > > > > > >On 4/23/12 5:47 PM, "Luis Muñoz" <[email protected]> wrote: > >> >>On Apr 23, 2012, at 1:57 PM, Gould, James wrote: >> >>> There is still >>> the connection establishment overhead (2-way SSL) that will decrease >the >>> performance. >> >>I don't think there's a way to completely get rid of this. A new TCP >>session will need to be created (or existing connections from a pool >>could be multiplexed). >> >>Still this proposal could be a big win in performance. >> >>-lem >> _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg