From users-return-7838-archive-asf-public=cust-asf.ponee.io@trafficserver.apache.org Mon Jul 29 18:48:24 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 7460B18063F for ; Mon, 29 Jul 2019 20:48:24 +0200 (CEST) Received: (qmail 57574 invoked by uid 500); 29 Jul 2019 18:48:23 -0000 Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@trafficserver.apache.org Delivered-To: mailing list users@trafficserver.apache.org Received: (qmail 57564 invoked by uid 99); 29 Jul 2019 18:48:23 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Jul 2019 18:48:23 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id DF74AC0E9E for ; Mon, 29 Jul 2019 18:48:22 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=verizonmedia.com Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id KtpyPloDI0tf for ; Mon, 29 Jul 2019 18:48:20 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::72c; helo=mail-qk1-x72c.google.com; envelope-from=solidwallofcode@verizonmedia.com; receiver= Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id DC6BB7DC06 for ; Mon, 29 Jul 2019 18:48:19 +0000 (UTC) Received: by mail-qk1-x72c.google.com with SMTP id m14so19118106qka.10 for ; Mon, 29 Jul 2019 11:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizonmedia.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yFBPdUgQzWY8rPLvX1Xmbv9YlbXxGTBfnifwcDB1k0o=; b=GMnvEeOwyJHeI+9G3GEH9CO8gxtdY7umSaIH6piECD7nryBUIoEL14t1iBJEtwbr7L gEBljyhDp8lurEF6gMjrMyIQaivthJfMH4zw10Kg2rhPmk7yAWvbMW7MeKLXdM7VR2nK h3BfM0/RtpYzI8vKElNgoXh+kVdmT30Ug4+qCio6R1YQ7cit4LB2pBJ0juJgbxMfxxIx wR/lOI54sHi3T3oYSN9xuVGBk3WZc4svl4HkHOiGtVK56dmGrE8lnJgXH08xdHUuOP53 YlOMdktPTXUi4LYNYclCT5Xp1chURj+cDA1WQVREB8DQGykIjkJF80UDt8XDW9hQSgd2 Ss9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yFBPdUgQzWY8rPLvX1Xmbv9YlbXxGTBfnifwcDB1k0o=; b=T7lPeCLlEBMW40q3gR0l0chclGobwDfloES5wMBVglxu6bU+HSFGSjfree1YWhCCuF VwzLMDM1LlltQ52VLBq3/agcsuZ8SHZhf7pH2kiwORroBAFYBSCVHUoDfVDRIP6QaWNc lZArJAdGmBTxj0PSFIMY/zVXiV+nlMn17PbnhrAu7zB4qRVTliojuvHniRQvXbo3Zlnp w/QWXX0FtFOlNqkfJsboh7uPEfyZOh/mkzEIpakyl3SQ83NDsppbsEvw4CqyfngU8EVF QykeFuZXvyxXCMp5m/zRTlqn3BXQoe84hE1qnMgSmZIr/oohzZnHo3533ipuwBwGqoTm KyAA== X-Gm-Message-State: APjAAAXqkV12/mImMVyDyphBkK+qySv0BaYnETe8yrORCDqh/kvpd5Z9 h2JUE7dHPykVGIPchIpZaXW8i0djs8Zk8VL7DBdtDIDS X-Google-Smtp-Source: APXvYqyTPMVQja7vEhxMJ7aElh/4hdPP+f3Xn7j6tgfFChXdtPRIR9dTcYb9xKixdKaNAHRuWqYnFFyFum5oOqqVpjQ= X-Received: by 2002:ae9:f80b:: with SMTP id x11mr73616860qkh.479.1564426092613; Mon, 29 Jul 2019 11:48:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alan Carroll Date: Mon, 29 Jul 2019 13:48:01 -0500 Message-ID: Subject: Re: Few Questions To: users@trafficserver.apache.org Content-Type: multipart/alternative; boundary="000000000000875aea058ed65519" --000000000000875aea058ed65519 Content-Type: text/plain; charset="UTF-8" 1) It's a bit more subtle than that. It depends on the size of the object. ATS stores objects in "fragments" and if the object fits in a single fragment, it's all written together. Objects larger than a fragment keep just the headers in the first fragment and that is what get rewritten, not the entire object. 2) No. The performance hit is very high from that and it's actually quite difficult at the cache writing point to do this for a single object, as multiple smaller writes get aggregated. 3) I'm not one of the performance guys, but it looks like the change in throughput may be due to TCP kernel socket buffer size or possibly ICW size. If so, you'd see higher aggregate bandwidth with parallel requests, which is expected usage. We have ATS doing 40+G/s in productionn for large files, where the limit is the network bandwidth, not ATS. On Sun, Jul 28, 2019 at 1:40 AM vishwas k.n. wrote: > Hello, > > I am new to ATS and had a few questions after having installed it and > played around with it a bit. > I am primarily interested in the reverse-proxy config mode of operation of > ATS. > > 1. When an origin server responds with a 304 to a request from ATS, then > ATS goes on to write the entire content and not just the headers into a new > location on the disk. This seems to be a "general space management > technique". In case of large files, wouldn't it make sense for the > directory to point to the earlier location on the disk and just update the > response headers ?. That way a whole chunk of write could be avoided. > > 2. Is there a configuration to enable the AIO sync/write to the disk > happen immediately after the response is received from the origin server ? > > 3. There are a few threads on the list discussing performance, however I > havent been able to zero in on any which discuss performance in detail. > We are trying to derive ATS performance benchmark using wrk as a client. > The initial tests suggest the below results: > > *Iteration * *Connections/Threads (wrk)* *File Size* *Duration Of Test* > *ATS* > 1 1/1 2MB 5min 8.83 Gbps > 2 1/1 3MB 5min 8.27 Gbps > 3 1/1 4MB 5min 3.81 Gbps > 4 1/1 10MB 5min 3.80 Gbps > 5 1/1 1MB 5min 8.58 Gbps > > The ATS configuration is used more or less the defaults available once the > ATS is installed. > The ATS version being used is 7.1.4 > Is there a cheatsheet which indicates the tunable parameters to get better > performance with ATS ? > NOTE: I am using file cache. > > thanks, > -vishwas. > --000000000000875aea058ed65519 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1) It's a bit more subtle than that. It depends on the= size of the object. ATS stores objects in "fragments" and if the= object fits in a single fragment, it's all written together. Objects l= arger than a fragment keep just the headers in the first fragment and that = is what get rewritten, not the entire object.

2) No. The= performance hit is very high from that and it's actually quite difficu= lt at the cache writing point to do this for a single object, as multiple s= maller writes get aggregated.

3) I'm not one o= f the performance guys, but it looks like the change in throughput may be d= ue to TCP kernel socket buffer size or possibly ICW size. If so, you'd = see higher aggregate bandwidth with parallel requests, which is expected us= age. We have ATS doing 40+G/s in productionn for large files, where the lim= it is the network bandwidth, not ATS.

On Sun, Jul 28, 2019 at 1:40 AM = vishwas k.n. <vishwaskn@gmail.com= > wrote:
=
Hello,

I am new to ATS and had a few qu= estions after having installed it and played around with it a bit.
I am primarily interested in the reverse-proxy config mode of operation o= f ATS.

1. When an origin server responds with a 30= 4 to a request from ATS, then ATS goes on to write the entire content and n= ot just the headers into a new location on the disk. This seems to be a &qu= ot;general space management technique". In case of large files, wouldn= 't it make sense for the directory to point to the earlier location on = the disk and just update the response headers ?. That way a whole chunk of = write could be avoided.=C2=A0

2. Is there a config= uration to enable the AIO sync/write to the disk happen immediately after t= he response is received from the origin server ?

3= . There are a few threads on the list discussing performance, however I hav= ent been able to zero in on any which discuss performance in detail.
<= div>We are trying to derive ATS performance benchmark using wrk as a client= .
The initial tests suggest the below results:

= <= tr>
Iteration = Connections/Threads (wrk) File Size Duration Of Test ATS
1 1/1 2MB 5min 8.83 Gbps
2 1/1 3MB 5min 8.27 Gbps
3 1/1 4MB 5min 3.81 Gbps
4 1/1 10MB 5min 3.80 Gbps
5 1/1 1MB 5min 8.58 Gbps

The = ATS configuration is used more or less the defaults available once the ATS = is installed.
The ATS version being used is 7.1.4
Is th= ere a cheatsheet which indicates the tunable parameters to get better perfo= rmance with ATS ?
NOTE: I am using file cache.

thanks,
-vishwas.
--000000000000875aea058ed65519--