Hi Willy.

Am 27-07-2014 16:22, schrieb Willy Tarreau:
Hi Aleks,

On Sun, Jul 27, 2014 at 01:44:01PM +0200, Aleksandar Lazic wrote:
>Peers are a bit different, as they can be accessed at a very high rate.
>However I'm pretty sure we'll move that to a shared memory just like
>the SSL session storage at some point, except that we still have to
>inform each process about the changes synchronously. I'm also thinking
>that stick tables could possibly be shared between multiple processes
>if we allocate entries from a shared memory area.

This way is only able to handle the informations on one machine.

Due to the fact that haproxy have already

peer <peername> <ip>:<port>

I thought to extend this to a more or less opener protocol.

Yes and that's why I wrote that we need to improve support for
peers synchronization.


>>When haproxy is able to send $Session-Information to redis, memcache,
>>... then you can "better" use current environment resources.
>It's by far too slow, you have to communicate over the network for
>even if it's on the loopback, meaning you need to poll to access them
>and stop/start any processing which needs them. You really want to have
>the information accessible from within the process without doing a
>context switch!

But isn't this

peer <peername> <ip>:<port>

a similar solution?

No, because peers are push-only, so it's asynchronous. Thus every node
has all the information, there's never any need for requesting something
outside. This makes a huge difference.

Ah ok thanks for explanation.

I would understand this part of the documentation as a similar solution
but with haproxy on protocol.
Maybe I have misunderstand it.

Not necessarily, I know that the doc on the protocol is missing. It was
planned but you know how it is when the doc is planned and not written
before the code...

Oh yes ;-)

I'm sure you have thought like a http-generic "plugin" and depend on the
request the http-1 or the http-2 plugin handle the request.

Not exactly, because as you might remember when you implemented the
appsession code, the HTTP code is spread all over the processing and
not easy to adapt to two different architectures. Thus I'm thinking
about changing everything to have an internal representation that
suits HTTP/2 and convert HTTP/1 to that representation. The code will
then have to be ported to work with this new representation. That
means that HTTP/1 to HTTP/1 proxying will more or less look like
it's converted to HTTP/2 then to HTTP/1 again, at least for headers
indexation. But I'd rather do it this way than the other way around,
since performance-sensible sites will definitely go the HTTP/2 route.

Pffu. That's a big BIG Change.

Maybe you will design it as library so that some other Projects can use this converter too ;-)



Reply via email to