From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9940 invoked by alias); 23 Dec 2019 01:39:09 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 9928 invoked by uid 89); 23 Dec 2019 01:39:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=HTo:U*mark, seriously, hosts, busy X-Spam-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (207.211.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Dec 2019 01:39:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1577065145; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=K+7UlzftYcnc1HRWoSXAfr8ghaBGdomWrfjhWK2h9b0=; b=SJuaaBCG80wQrqTbBn15x1V7Zz5/e6vW3ig2G7bW6zHzcklYx30Kwg04JvQUjgeJpE/xOZ Cg2qIXU9sg1xVKWnBeOW721zvy/uW7JTMf7jImZRfgRxj1pWSSC/K5WLmaYBL6zGoBHpx6 2w7Ck2QPAvqnKzvFSochIuhGeg5FNZM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-269-jB6E13WLPkaymeYmxRdUBQ-1; Sun, 22 Dec 2019 20:39:02 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AA38A800D4C; Mon, 23 Dec 2019 01:39:01 +0000 (UTC) Received: from redhat.com (ovpn-116-36.phx2.redhat.com [10.3.116.36]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 87FE45C21A; Mon, 23 Dec 2019 01:39:01 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.92) (envelope-from ) id 1ijCgV-0005gD-PD; Sun, 22 Dec 2019 20:38:59 -0500 Date: Mon, 23 Dec 2019 01:39:00 -0000 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: elfutils-devel@sourceware.org Subject: Re: rfc/patch: debuginfod client $DEBUGINFOD_PROGRESS env var Message-ID: <20191223013859.GA21653@redhat.com> References: <20191204211050.GA11981@redhat.com> <34b18e36d5a94512a27d8e1f65c9230e4803dc7d.camel@klomp.org> <20191212171850.GE13089@redhat.com> <20191213165707.GF13089@redhat.com> <20191219004737.GB30730@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-MC-Unique: jB6E13WLPkaymeYmxRdUBQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2019-q4/txt/msg00283.txt.bz2 Hi - > There is of course some i/o delay involved. But the majority of the > time is cpu bound because the file needs to be decompressed. > Not that it would help us now, but I wonder if it would be worth it to > look at parallel compression/decompression to speed things up. Yeah, maybe. > picking 90 seconds because that seems twice the worse case time to > decompress and that gives it about 45 seconds to provide ~10K/sec. But > if you are seeing 60 seconds as worse case we could pick something like > 120 seconds or something. That's a possibility. > But it should probably be a separate timeout from the connection > timeout, and maybe from the total timeout (or maybe replace > it?). What do you think? Yeah, a connection timeout per se is probably not really worth having. A URL having unreasolvable hosts will fail immediately. A reachable http server that is fairly busy will connect, just take time. The only common cases a connection timeout would catch is a running http server that is so overloaded that it can't even service its accept(4) backlog, or a nonexistent one that has been tarpit/firewalled. A minimal progress timeout can subsume cases too. OTOH, it's worth noting that these requests only take this kind of time if they are being seriously serviced, i.e., "they are worth it". Error cases fail relatively quickly. It's the success cases - and these huge vmlinux files - that take time. And once the data starts flowing - at all - the rest will follow as rapidly as the network allows. That suggests one timeout could be sufficient - the progress timeout you the one you found - just not too short and not too fast. - FChE