cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: Difference in curl performance between RHEL6 and RHEL7

From: Kamil Dudka <kdudka_at_redhat.com>
Date: Fri, 29 Aug 2014 17:32:42 +0200

On Friday, August 29, 2014 11:15:56 bruce wrote:
> hey question...
>
> Will this be backported/available as an update to rhel7/centos7 as
> well at some point in the "near" future??
>
> thanks

It is not for me to decide. The bug needs to be approved by Product
Management. RHEL updates are driven by customer requests. Please
open a customer case if the fix is important for your business.

Kamil

> On Thu, Aug 28, 2014 at 8:16 PM, barry Chung <barry_c_at_mail.com> wrote:
> > On Tuesday, August 12, 2014 12:29:55 Alastair Scobie wrote:
> >>> On 12/08/14 12:18, Kamil Dudka wrote:
> >>> > On Tuesday, August 12, 2014 10:05:37 Alastair Scobie wrote:
> >>> >> Whilst porting an in-house application, which uses libcurl, from
> >>> >> RHEL6
> >>> >> to RHEL7 we noticed that the time taken by libcurl to fetch a page
> >>> >> had
> >>> >> substantially increased. Even an attempt at fetching a non-existent
> >>> >> page
> >>> >> has increased from 10-20ms to around 150ms. This with just plain
> >>> >> HTTP.
> >>> >
> >>> > What exactly do you mean by a non-existent page?
> >>>
> >>> A page for which you'll receive a 404. Ie. HTTP server address is
> >>> correct, but actual page requested doesn't exist.
> >>>
> >>> >> Our first thought was that the API has changed in some subtle way and
> >>> >> the fault must be in our code, but then we thought to try measuring
> >>> >> the
> >>> >> performance of the curl tool itself. To our surprise, we found the
> >>> >> same
> >>> >> performance disparity.
> >>> >>
> >>> >> Interestingly...
> >>> >>
> >>> >> * Adding the DNS address of the HTTP server to /etc/hosts (and
> >>> >> specifying files,dns in /etc/nsswitch.conf) does not improve things
> >>> >
> >>> > Did you try to measure the time consumed by 'getent ahosts'?
> >>>
> >>> Small number of ms for both RHEL6 and RHEl7.
> >>>
> >>> >> * but, performance when using an IP address in the URL is fine (~
> >>> >> 10-20ms) for both RHEL6 and RHEL7
> >>> >
> >>> > I was not able to reproduce this behavior. Is it reproducible locally?
> >>>
> >>> Yip, on several machines. I can ship you an strace if you like?
> >>
> >>I would prefer a self-contained program that I can use to repeat the bug.
> >>
> >>> (Daniel's suggestion of disabling the threaded resolver has fixed the
> >>> issue for us).
> >>>
> >>> Cheers, Alastair
> >>
> >>The problem is that either you will not receive security updates for
> >>(lib)curl any more, or the threaded resolver will be re-enabled on the
> >>next update. Kamil
> >>
> > We are also hitting this while porting our software to RHEL7. Like
> > Alastair
> > mentioned, using IP address does not have the issue. wget also works fine.
> >
> > Kamil, you should be reproduce this by
> > 1) bring up a RHEL7 minimal installation
> > 2) install httpd or lighttpd
> > 3) sudo tail -f /var/log/lighttpd/access.log
> > 4a) while [ 1 ]; do curl http://localhost/badpage; done
> > 4b) while [ 1 ]; do curl http://127.0.0.1/badpage; done
> >
> > There will be huge difference in the access count per second between 4a)
> > and 4b).
> >
> > BTW, I uninstalled 7.29.0-19.el7 and installed 7.37.1-3.0.cf.rhel7 from
> > http://curl.haxx.se/download.html but the problem still seems to exist.
> >
> > Thanks,
> > Barry
> > -------------------------------------------------------------------
> > List admin: http://cool.haxx.se/list/listinfo/curl-users
> > FAQ: http://curl.haxx.se/docs/faq.html
> > Etiquette: http://curl.haxx.se/mail/etiquette.html
>
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-users
> FAQ: http://curl.haxx.se/docs/faq.html
> Etiquette: http://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-08-29