Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@trafficserver.apache.org
Received-SPF: pass (nike.apache.org: domain of h.reindl@thelounge.net
 designates 91.118.73.15 as permitted sender)
Message-ID: <5206672D.6080603@thelounge.net>
Date: Sat, 10 Aug 2013 18:15:41 +0200
From: Reindl Harald <h.reindl@thelounge.net>
Organization: the lounge interactive design
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: users@trafficserver.apache.org
Subject: Re: 3.3.5: performance regression?
References: <52063E61.8090201@thelounge.net>
 <153920A9-F441-4991-8034-A2D9DAB46FF0@apache.org>
 <520658DF.7010402@thelounge.net>
 <C54EC748-D01D-48A1-9BB8-DFC39CCA9DD0@gmail.com>
 <52065F3B.4050109@thelounge.net>
 <D8D6E346-80E3-44C7-A9CD-42D6AC643E04@gmail.com>
In-Reply-To: <D8D6E346-80E3-44C7-A9CD-42D6AC643E04@gmail.com>
OpenPGP: id=7F780279;
	url=http://arrakis.thelounge.net/gpg/h.reindl_thelounge.net.pub.txt
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="Cqc14N8CWPlcBpIOESNW12E0dNm7RuOCi"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Cqc14N8CWPlcBpIOESNW12E0dNm7RuOCi
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable


Am 10.08.2013 18:09, schrieb Yongming Zhao:
>=20
> =D4=DA 2013-8-10=A3=AC=CF=C2=CE=E711:41=A3=ACReindl Harald <h.reindl@th=
elounge.net> =D0=B4=B5=C0=A3=BA
>=20
>>
>> Am 10.08.2013 17:32, schrieb Yongming Zhao:
>>> if your requested URL is expires very often, then you may hit the=20
>>> read-while-writer performance issue, we have fixed that read-while-wr=
iter
>>> in V3.3 that will make it really work.
>>
>> but every 60 seconds is not that often in case of a apache-benchmark
>> it's a simple calculation how many cache-hits you can have within
>> this 60 seconds by 200 parallel requests of the same URL
>>
>=20
> we care of the performance, but your case is mixing with the feature=20
> of read-while-writer, if you get to know that read-while-writer may=20
> affect your performance result, that will help us compare the result,=20
> in the better understanding.

CONFIG proxy.config.cache.enable_read_while_writer INT 0
does not change anything

>>> please compare the Origin Side traffic during the test
>>
>> the origin is 127.0.0.1:80 but 6 prefork-processes
>> while "ab -c 200" is running indicates pretty clear
>> that all the work is ATS
>>
>> [root@testserver:~]$ ps aux | grep httpd | wc -l
>> 6
>=20
> I mean, how many requests you get from the origin side during your test=
ing, or hit ratio

*none* which is pretty clear in case of a preforking-httpd

StartServers             3
MinSpareServers          3
MaxSpareServers          5

so the 6 httpd-processes are the master-process and 5 idle workers

>>> and you'd better try the compare without expire issue, to make sure w=
e have=20
>>> not make critical regression there.
>>
>> no - if this is a problem now *it is* a critical regression
>>
>> the only reason trafficserver exists in our infrastructure
>> is to buffer high-traffic sites with a lot of images and
>> hold back the image-count multiplied with users requests
>> from teh preforking-apache
>=20
> if you want to enable read while writer, that means you care of the ori=
gin side traffic,=20
> and you may need to pay for the performance drop in speed(response time=
) on the proxy,=20
> when that url is getting fetched from the origin

please stop to insist in "read while writer"

* disable it does not change anything
* 100000 requests with 200 parallel are done within the 60 seconds expire=

* hence we speak about *one* single URL, only *one* object requested and =
cached


--Cqc14N8CWPlcBpIOESNW12E0dNm7RuOCi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIGZy0ACgkQhmBjz394AnknRACcDPjyc7N21LL8EQUAzNTbPIxe
ILcAn2IBTgIDXJ7zxQ4WYol/xRYkv+bD
=hDxq
-----END PGP SIGNATURE-----

--Cqc14N8CWPlcBpIOESNW12E0dNm7RuOCi--