From users-return-7840-archive-asf-public=cust-asf.ponee.io@trafficserver.apache.org Wed Jul 31 06:03:20 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 B14F418062B for ; Wed, 31 Jul 2019 08:03:19 +0200 (CEST) Received: (qmail 62768 invoked by uid 500); 31 Jul 2019 06:03:18 -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 62758 invoked by uid 99); 31 Jul 2019 06:03:18 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Jul 2019 06:03:18 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id CE017C2DE9 for ; Wed, 31 Jul 2019 06:03:17 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-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: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 5eFYimPpo58v for ; Wed, 31 Jul 2019 06:03:15 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.219.173; helo=mail-yb1-f173.google.com; envelope-from=vishwaskn@gmail.com; receiver= Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id AA660BC7B3 for ; Wed, 31 Jul 2019 06:03:15 +0000 (UTC) Received: by mail-yb1-f173.google.com with SMTP id x188so1877986yba.8 for ; Tue, 30 Jul 2019 23:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pRVRDVjqgowUPRlNQf6Kq4JvjRPfc4451o/V48ZpvGI=; b=ojHyO08Hk9J1YQz2tOPgRVWHlYiN7LNVg+olvQCp9zebyjC2WZ7SmqvBQAYYfj6b29 Jg764QKdAnjiMKJVXfORCZat8t3Cy5YaknTfisYCKVbEJ7CAyfRYaZ/Lo1yN22NhETsb lGIIAXEMg8/Q1jMqNmktJkOGi2kO4FMLp0FdbWrd9gP+TuEJaDjHIbOsNV8kz6VeWIWt 7ErZ0PNkWvl3MtTt9Mq9/bMXur2i2wSY/4ZsnmlImQdTXFfnrlRrUD3XIu/RfxniXQgJ 5QTBqYVGrvS1azDXdxmQkixOH4r7nZysGJvi5Br//Y5ZrhU0LP5n3zup+rIw4TQgFq2u 03QA== 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=pRVRDVjqgowUPRlNQf6Kq4JvjRPfc4451o/V48ZpvGI=; b=RigY8pqoo9iS2AgdnNQ+gsRCDJCcFFFOfQYbHINU2//Ur5+1tEpRtjiUsSb+J0X1Z+ 4JlGwVk2SIIn3jQHxCIgM9iZz0kFCyBCD1zpxKZDd13ZQDDXQg+90PhMnJc8od6Wiyr0 JVoGpJ7h73e5mXFpk6PDd4YQVrP4+2jg6fhzc24ti5hccoULd66ZT9FL/X7JHBrqfo0M bHfPWkSrquKABjy1Bx6qlO3H+wcGw0vto5pF5QTm20LiHDadPWWCbCiEOStGQcDKoMXZ slh0pSp4OK4vOlcZC2Jzn+qHm3wIAlnIVTs6dwM+tPCxggnqRmS5A3dN1E64ynn+si1j yeoQ== X-Gm-Message-State: APjAAAXGXKioLPQPvTgx0fqh/qLQTWHWSfsc+OyNB3wd454bICEwSD4P HS56/s++suIDe0SDleA2a1Axj9uUoF3wAuXc+J0ILkBn X-Google-Smtp-Source: APXvYqxTNdTXigMhtFlycknwn+fk8fzCXjK8uBOhlCigJ3GzfFdzXDQHdY6V+jxIgx4wXk75tEwgW87xGs4zqDE3sjA= X-Received: by 2002:a25:d252:: with SMTP id j79mr79872999ybg.236.1564552988920; Tue, 30 Jul 2019 23:03:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "vishwas k.n." Date: Wed, 31 Jul 2019 11:32:57 +0530 Message-ID: Subject: Re: Few Questions To: users@trafficserver.apache.org Content-Type: multipart/alternative; boundary="000000000000231367058ef3e1d1" --000000000000231367058ef3e1d1 Content-Type: text/plain; charset="UTF-8" thank you Alan for your quick response. Let me reiterate the tests with the suggested changes. regards, -vishwas. On Tue, Jul 30, 2019 at 12:18 AM Alan Carroll < solidwallofcode@verizonmedia.com> wrote: > 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. >> > --000000000000231367058ef3e1d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
thank you Alan for your quick response. Let me reiterate t= he tests with the suggested changes.

regards,
= -vishwas.

On Tue, Jul 30, 2019 at 12:18 AM Alan Carroll <solidwallofcode@verizonmedia.c= om> wrote:
1) It's a bit more subtle than that. It depends on t= he size of the object. ATS stores objects in "fragments" and if t= he 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 tha= t is what get rewritten, not the entire object.

2) No. T= he performance hit is very high from that and it's actually quite diffi= cult 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 l= imit is the network bandwidth, not ATS.

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

I am new to = ATS and had a few questions after having installed it and played around wit= h it a bit.
I am primarily interested in the reverse-proxy config= mode of operation of ATS.

1. When an origin serve= r 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. Th= is 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 w= ay a whole chunk of write could be avoided.=C2=A0

= 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 ?
<= div>
3. There are a few threads on the list discussing perfor= mance, however I havent been able to zero in on any which discuss performan= ce in detail.
We are trying to derive ATS performance benchmark u= sing wrk as a client.
The initial tests suggest the below results= :

I= teration 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.
--000000000000231367058ef3e1d1--