Thanks. IMHO, a 4x increase in CPU usage for the worst
case isn't a problem, as that's a 4x increase in an operation
that's only a few percent of the total cycles anyway.
But since the 4x degradation in the worst case may be
controversial, I'd like to have a vote first. I'm +1 for
making this change in APR. Can a few other committers weigh in?
Thanks,
Brian
On Tue, 2003-05-20 at 17:25, Joe Schaefer wrote:
> Brian Pane <[EMAIL PROTECTED]> writes:
>
> > Thanks, it works much better with that change.
> > One more question: do you have a way to get "before" and
> > "after" profile data for a request with a ridiculously
> > large number of header fields (e.g., 90 different Cookie
> > or Accept lines that need to get merged)? A default httpd
> > config will allow up to a 100-line header, which is a large
> > enough 'n' to make me paranoid about O(n^2) DoS vulnerabilities.
>
> I had to patch ab to allow it to take a large enough
> set of headers.
>
> % perl -wle '$xx="aa";$args.="-H Cook".++$xx.":foo=bar " for 1..48; \
> exec qq{ab $args $args -n 50000 -c 50 http://127.0.0.1:8080/foo}'
>
> % oprofile -rl /home/joe/apache2/bin/httpd | head
>
>
> UNPATCHED:
> vma samples % symbol name
> 00075fb4 9007 20.0071 __GI___strcasecmp
> 00009d3c 8553 18.9986 __pthread_internal_tsd_address
> 0000cf00 2294 5.09563 overlap_hash
> 0000d13c 1900 4.22044 apr_table_overlap
> 0808852c 1867 4.14714 ap_rgetline_core
> 000762d8 1254 2.78549 memcpy
> 000177d4 787 1.74815 apr_palloc
> 0808ddbc 551 1.22393 core_input_filter
> 00075b10 482 1.07066 __memchr
>
>
> PATCHED:
> vma samples % symbol name
> 00075fb4 35642 35.7866 __GI___strcasecmp
> 00009d3c 35549 35.6932 __pthread_internal_tsd_address
> 0000c41c 3134 3.14671 apr_table_compress
> 000762d8 1454 1.4599 memcpy
> 0808852c 1453 1.45889 ap_rgetline_core
> 0000c010 1450 1.45588 apr_array_pstrjoin
> 00017bb8 811 0.81429 apr_palloc
> 00006214 621 0.623519 apr_brigade_split_line
> 0808ddbc 578 0.580345 core_input_filter
>
> So it looks like the worst case scenario is
> worsened by a factor of 4.