On Wed, Feb 12, 2014 at 8:48 AM, Willy Tarreau wrote:
> Hi Ilya,
>
> On Wed, Feb 12, 2014 at 08:36:20AM +0100, Willy Tarreau wrote:
> > > One last set of followup question on configuration and defaults:
> > > - we allow the user to tune buffer sizes - that's great.
> > > - we allow the user to ad
Hi Ilya,
On Wed, Feb 12, 2014 at 08:36:20AM +0100, Willy Tarreau wrote:
> > One last set of followup question on configuration and defaults:
> > - we allow the user to tune buffer sizes - that's great.
> > - we allow the user to adjust record sizes: assuming above logic is in
> > place, can we cha
Hi Ilya,
On Tue, Feb 11, 2014 at 03:54:15PM -0800, Ilya Grigorik wrote:
> Hey Willy. This is great work, thanks!
>
> On Sat, Feb 8, 2014 at 11:49 PM, Willy Tarreau wrote:
> >
> > The observations and analysis are interesting, and the choice of solutions
> > is not easy. I think that relying on a
Hey Willy. This is great work, thanks!
On Sat, Feb 8, 2014 at 11:49 PM, Willy Tarreau wrote:
>
> The observations and analysis are interesting, and the choice of solutions
> is not easy. I think that relying on a pause only is dangerous because
> there
> are generally a number of losses when deli
Hi Ilya,
I've finished the change. It seems to do the right thing for me with
HTTP, though I have not tested with SPDY.
If a read happens after a pause of more than one second where the
output buffer was empty, we reset the streamer flags. Thus it will
cover the case where the client sends a new
Hi Ilya,
On Sat, Feb 08, 2014 at 04:12:03PM -0800, Ilya Grigorik wrote:
> Ok, I have the following setup: client -> haproxy (npn + tcp proxy) ->
> spdylay (spdy 3.1 without TLS).
>
> http://www.webpagetest.org/result/140208_DM_57a2a0feaf3258b93d7e3ce3c802b278/4/details/-
> 100ms RTT / 3Mbps down.
On Thu, Feb 6, 2014 at 11:03 PM, Willy Tarreau wrote:
> > Gotcha, thanks. As a follow up question, is it possible for me to control
> > the size of the read buffer?
>
> Yes, in the global section, you can set :
>
> - tune.bufsize : size of the buffer
> - tune.maxrewrite : reserve at the end o
Hi Ilya,
On Thu, Feb 06, 2014 at 04:14:14PM -0800, Ilya Grigorik wrote:
(...)
> > I preferred to only rely on CF_STREAMER and ignore the _FAST variant
> > because it would only favor high bandwidth clients (it's used to
> > enable splice() in fact). But I thought that CF_STREAMER alone would
> > d
> > (a) It's not clear to me how the threshold upgrade is determined? What
> > triggers the record size bump internally?
>
> The forwarding mechanism does two things :
> - the read side counts the number of consecutive iterations that
> read() filled the whole receive buffer. After 3 consecut
Hi Ilya,
On Wed, Feb 05, 2014 at 05:01:03PM -0800, Ilya Grigorik wrote:
> This is looking very promising! I created a simple page which loads a large
> image (~1.5MB), then onload fires, and after about 5s of wait, another
> image is fetched. All the assets are fetched over the same TCP connection
This is looking very promising! I created a simple page which loads a large
image (~1.5MB), then onload fires, and after about 5s of wait, another
image is fetched. All the assets are fetched over the same TCP connection.
- Sample WPT run:
http://www.webpagetest.org/result/140206_R2_0eab5be9abebd6
Hi Ilya,
On Sat, Feb 01, 2014 at 11:33:50AM -0800, Ilya Grigorik wrote:
> Hi Eric.
>
> 0001-MINOR-ssl-handshake-optimz-for-long-certificate-chai: works great!
> After applying this patch the full cert is sent in one RTT and without any
> extra pauses. [1]
Cool, I'm impressed to see that the SSL
Hi Eric.
0001-MINOR-ssl-handshake-optimz-for-long-certificate-chai: works great!
After applying this patch the full cert is sent in one RTT and without any
extra pauses. [1]
0002-MINOR-ssl-Set-openssl-max_send_fragment-using-tune.s: I'm testing with
/ against openssl 1.0.1e, and it seems to work.
On 01/28/2014 03:58 PM, Emeric Brun wrote:
Hi Ilya,
Ah, interesting. Doing a bit more digging on this end, I see
"SSL_set_max_send_fragment", albeit that's from back in 2005. Is that
what you guys are looking at?
https://github.com/openssl/openssl/commit/566dda07ba16f9d3b9774fd5c8d526d7cc93f
Hi Ilya,
Ah, interesting. Doing a bit more digging on this end, I see
"SSL_set_max_send_fragment", albeit that's from back in 2005. Is that
what you guys are looking at?
https://github.com/openssl/openssl/commit/566dda07ba16f9d3b9774fd5c8d526d7cc93f179
Yes, that's it! it appears in openssl
On Fri, Jan 17, 2014 at 9:50 AM, Willy Tarreau wrote:
> > Yup, that sounds like an interesting strategy. The only thing to note is
> > that you should consider resetting the record size after some idle
> timeout
> > -- same logic as slow-start after idle.
>
> We wouldn't even need this because th
Hi Ilya,
On Fri, Jan 17, 2014 at 09:36:51AM -0800, Ilya Grigorik wrote:
> The 4K+ case is a fairly common occurrence, so it would definitely be worth
> the effort.
Yes clearly, and you got Emeric curious so he already started to take a look
at it.
> Firefox telemetry data for "plaintext bytes re
Hey Willy.
On Fri, Jan 17, 2014 at 2:49 AM, Willy Tarreau wrote:
>
> >
> > (1) Certificates that exceed 4KB require an extra RTT even with IW10: HA
> > ships the first 4KB then pauses and waits for client ACK before
> proceeding
> > to send remainder of the certificate. At a minimum, this result
Hi Ilya!
On Thu, Jan 16, 2014 at 02:35:42PM -0800, Ilya Grigorik wrote:
> Hey all.
>
> I've spent some time looking into HAProxy (1.5-dev21) + TLS performance and
> stumbled across a few areas where I think we could make some improvements.
> In particular I'm interested in time to first byte, as
Hey all.
I've spent some time looking into HAProxy (1.5-dev21) + TLS performance and
stumbled across a few areas where I think we could make some improvements.
In particular I'm interested in time to first byte, as that's a critical
piece for interactive traffic: time to first paint in browsers, t
20 matches
Mail list logo
