if that is a all cached performance test, the compared data is a clearly regression.
Leif: can you reproduce your performance testing? 在 2013-8-11，上午12:09，Yongming Zhao <[email protected]> 写道： > > 在 2013-8-10，下午11:41，Reindl Harald <[email protected]> 写道： > >> >> Am 10.08.2013 17:32, schrieb Yongming Zhao: >>> if your requested URL is expires very often, then you may hit the >>> read-while-writer performance issue, we have fixed that read-while-writer >>> 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 >> > > we care of the performance, but your case is mixing with the feature of > read-while-writer, if you get to know that read-while-writer may affect your > performance result, that will help us compare the result, in the better > understanding. > > > >>> 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 > > I mean, how many requests you get from the origin side during your testing, > or hit ratio. > > >> >>> and you'd better try the compare without expire issue, to make sure we have >>> 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 > > if you want to enable read while writer, that means you care of the origin > side traffic, and you may need to pay for the performance drop in > speed(response time) on the proxy, when that url is getting fetched from the > origin. > > >> >>> 在 2013-8-10，下午11:14，Reindl Harald <[email protected]> 写道： >>> >>>> >>>> Am 10.08.2013 16:46, schrieb Leif Hedstrom: >>>>> On Aug 10, 2013, at 7:21 AM, Reindl Harald <[email protected]> wrote: >>>>> >>>>>> has anybody compared 3.2 / 3.3 in performance? >>>>>> >>>>>> ab -c 200 -n 100000 http://<url>/rte/upload/logo.gif while "logo.gif" is >>>>>> 643 bytes small and currently httpd without Trafficserver in front has >>>>>> nearly the same perfomrance with even lower CPU >>>>> >>>>> I haven't seen this behavior. Are you positive the 3.3.5 results are >>>>> cache hits ? And if so, that they become RAM cache hits? Just trying to >>>>> get some ideas here … :) >>>> >>>> i hope so, if not that would be a bug >>>> >>>> [root@testserver:~]$ curl --head >>>> http://rhsoft.testserver/rte/upload/logo.gif >>>> HTTP/1.1 200 OK >>>> Date: Sat, 10 Aug 2013 15:09:31 GMT >>>> Last-Modified: Tue, 11 Apr 2006 10:40:40 GMT >>>> ETag: "283-411255ab33a00" >>>> Accept-Ranges: bytes >>>> Content-Length: 643 >>>> Cache-Control: max-age=60 >>>> Expires: Sat, 10 Aug 2013 15:10:31 GMT >>>> X-Content-Type-Options: nosniff >>>> Connection: close >>>> Content-Type: image/gif >>>> >>>> on the origin mod_expires is in action to set 60 seconds >>>> cache for images because in our case we have 100% dynamic >>>> pages and the job of ATS is only hold back the image/css/js >>>> requests from the preforking apache and offer KeepAlive >>>> >>>> the 60 seconds are reflected in the curl-repsonse abvove >>>> which comes from the origin (127.0.0.1:80) >>>> >>>> <IfModule mod_expires.c> >>>> ExpiresActive On >>>> ExpiresByType image/jpeg A60 >>>> ExpiresByType image/jpg A60 >>>> ExpiresByType image/gif A60 >>>> ExpiresByType image/png A60 >>>> ExpiresByType text/css A60 >>>> ExpiresByType text/html A60 >>>> ExpiresByType text/javascript A60 >>>> ExpiresByType text/comma-separated-values A60 >>>> ExpiresByType text/tab-separated-values A60 >>>> ExpiresByType application/javascript A60 >>>> ExpiresByType application/x-javascript A60 >>>> ExpiresByType application/xhtml+xml A60 >>>> ExpiresByType application/xml A60 >>>> <IfModule/> >>>> >>>> >>>>> Reclaimable freelist would not have these sort of performance >>>>> discrepancies >>>> >>>> yes, and it should not matter in a (ok small) cache with only a handful of >>>> objects >> >
