[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dragonfly-users
Subject:    Re: Study of nginx-1.9.12 performance/latency on DragonFlyBSD-g67a73.
From:       Sepherosa Ziehau <sepherosa () gmail ! com>
Date:       2016-05-10 13:00:01
Message-ID: CAMOc5cxvDQ5g8P9pWfNw2281fYfKufANBCjkYFiR5d9_ogtPsg () mail ! gmail ! com
[Download RAW message or body]

On Tue, May 10, 2016 at 1:40 AM, Matthew Dillon <dillon@backplane.com> wrote:
> Very interesting results.  I'm not surprised that lowering the poll rate
> improves the results, that's an artifact of scheduling larger batches (as
> long as the ring buffer doesn't fill up completely).  It's true for process
> scheduling too but usually at the cost of losing interactive responsiveness
> which is why schedulers implement hybrid mechanics.
>
> I was surprised that the chipset-rate-limited interrupt mode was so bad
> compared to the polling.  I would have expected it to approach polling
> effectiveness at the same frequency.  But it clearly doesn't (at least not
> at ~7000-8000hz).  If you can program it, could you try a lower chipset
> interrupt rate at 1000hz and 4000hz?

Here is the new tables for interrupt and polling comparison at same frequency:

             Requests/s
           intr   |  poll
        ----------+----------
7000hz    116961  |  140580
4000hz    143505  |  142862
1000hz    143391  |  144807

           Average Latency
           intr   |  poll
        ----------+----------
7000hz    64.14ms |  54.25ms
4000hz    53.08ms |  52.87ms
1000hz    51.85ms |  51.20ms

           Latency Stdev
           intr   |  poll
        ----------+----------
7000hz   150.30ms |  21.68ms
4000hz    20.99ms |  19.16ms
1000hz    16.53ms |  13.96ms

Interrupt @4000hz and @1000hz have almost same performance and latency
as the polling(4).

Thanks,
sephe

-- 
Tomorrow Will Never Die
[prev in list] [next in list] [prev in thread] [next in thread]