RFC: mod_ssl output buffering

[Joe Orton <jo...@redhat.com>]

mod_ssl's output buffering has been bothering me for a while.

1) it buffers the encrypted output stream (to some extent) coupled with 
regular use of FLUSH buckets.  This seems redundant/inefficient; the 
core output filter should be doing this kind of thing optimally already.

2) it does /not/ do any buffering of the plaintext input brigades.  This 
leads to some pathological inefficiency as discussed here in the past:

http://marc.info/?l=apache-httpd-dev&m=125070085316400&w=2

The one justification I know for (1) is in the ssl_engine_io.c comment:

        /* the first two SSL_writes (of 1024 and 261 bytes)
         * need to be in the same packet (vec[0].iov_base)
         */

but I see no evidence this will not happen if the core output filter is 
allowed to operate as normal.  Maybe that was not true in the psat.

So I'd propose to remove (1), which is simple and add (2), which is not 
so simple.  I've hacked up (yet another) "coalescing" filter for (2) 
which works to coalesce chunked brigades as expected; proof of concept 
attached.  Would welcome some discussion before I work on this 
further...

Regards, Joe

RE: mod_ssl output buffering

["Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>]

 

> -----Original Message-----
> From: Joe Orton  
> Sent: Freitag, 5. November 2010 16:22
> To: dev@httpd.apache.org
> Subject: RFC: mod_ssl output buffering
> 
> mod_ssl's output buffering has been bothering me for a while.
> 
> 1) it buffers the encrypted output stream (to some extent) 
> coupled with 
> regular use of FLUSH buckets.  This seems redundant/inefficient; the 
> core output filter should be doing this kind of thing 
> optimally already.
> 
> 2) it does /not/ do any buffering of the plaintext input 
> brigades.  This 
> leads to some pathological inefficiency as discussed here in the past:
> 
> http://marc.info/?l=apache-httpd-dev&m=125070085316400&w=2
> 
> The one justification I know for (1) is in the 
> ssl_engine_io.c comment:
> 
>         /* the first two SSL_writes (of 1024 and 261 bytes)
>          * need to be in the same packet (vec[0].iov_base)
>          */
> 
> but I see no evidence this will not happen if the core output 
> filter is 
> allowed to operate as normal.  Maybe that was not true in the psat.
> 
> So I'd propose to remove (1), which is simple and add (2), 
> which is not 
> so simple.  I've hacked up (yet another) "coalescing" filter for (2) 
> which works to coalesce chunked brigades as expected; proof 
> of concept 
> attached.  Would welcome some discussion before I work on this 
> further...
> 

Sounds reasonable.

Regards

Rüdiger

Re: RFC: mod_ssl output buffering

[Rainer Jung <ra...@kippdata.de>]

Interesting stuff. I patched trunk and ran the test suite (using OpenSSL 
0.9.8o).

All tests pass for MPMs prefork, worker,event on Solaris 10 (but maybe 
you knew that already).

I didn't really check the intended functionality though.

Compilation showed two trivial warnings:

ssl_engine_io.c: In function `flush_coalesced_data':
ssl_engine_io.c:1348: warning: long unsigned int format, apr_size_t arg 
(arg 8)
ssl_engine_io.c: In function `ssl_io_filter_coalesce':
ssl_engine_io.c:1422: warning: long unsigned int format, apr_size_t arg 
(arg 8)

Both are about trace logging, using %lu for ctx->bytes resp. len. Using 
APR_SIZE_T_FMT instead of "lu" fixes those.

There are some strange lines in the switch which is part of 
bio_filter_out_ctrl() (the part starting with "PENDING"; note the 
"break" in the previous line):

  227     case BIO_CTRL_GET_CLOSE:
  228         ret = (long)bio->shutdown;
  229         break;
  230       case BIO_CTRL_SET_CLOSE:
  231         bio->shutdown = (int)num;
  232         break;
  233         /* _PENDING is interpreted as "pending to read" - since this
  234          * is a *write* buffer, return zero. */
  235         ret = 0L;
  236         break;
...

Finally: I wasn't able to find eeeko, only eeko [1] and eeek [2]. Though 
there is eeeko! [3].

Have a nice weekend

Rainer

[1] http://www.urbandictionary.com/define.php?term=eeko
[2] http://www.urbandictionary.com/define.php?term=eeek
[3] http://eeeko.com/