[
https://issues.apache.org/jira/browse/TS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-307:
-----------------------------
Fix Version/s: 2.3.0
> Possible performance problem: DNS lookup continuation is using first Network
> ethread for all operations
> -------------------------------------------------------------------------------------------------------
>
> Key: TS-307
> URL: https://issues.apache.org/jira/browse/TS-307
> Project: Traffic Server
> Issue Type: Improvement
> Reporter: Miles Libbey
> Priority: Minor
> Fix For: 2.3.0
>
>
> (from yahoo bug 989959)
> Original description
> by Vladimir Legalov 3 years ago at 2006-12-18 11:57
> All DNS lookup operations are executing on the first Network thread. Since
> each Network thread is already responsible
> for NetAccept & NetHandler continuation processing, DNS processing can cause
> extra CPU usage and additional delays
> for
> this particular thread. It make sense to extract DNS processing as absolutely
> independent thread (ethread) to avoid
> possible performance problem related to
> DNS lookups.
> Such performance problem can be visible only in "no caching" mode with very
> high rate of OS requests.
> Additional performance testing is required to clarify visibility of this
> problem.
> (It looks like htop is not an appropriate tool to catch precise CPU usage per
> thread.)
>
>
> Comment 1
> by Leif Hedstrom 3 years ago at 2006-12-26 13:41:10
> I think it's highly unlikely that DNS will ever become a bottleneck. Even
> under extreme cases, like say 300 Origin
> Servers all with a TTL of 5 minutes (we rarely have anything shorter), we're
> looking at one DNS lookup per second
> (assuming there are no cache hits, as pointed out already).
> I'm closing this bug until we have some real evidence that DNS lookups is
> ever going to be any sort of bottleneck.
>
> Comment 2
> by Vladimir Legalov 3 years ago at 2006-12-26 20:31:17
> I don't understand why we should not keep this RFE open. I would prefer to
> keep DNS lookup code as separate thread not
> because of a huge performance impact but because the DNS lookup continuation
> is activated every 11 milliseconds (just
> to verify the status of the 32 UDP sockets) even if we don't need to do
> perform a DNS lookup. One more thing - this
> continuation is impacting eThread scheduling for first NetHandler
> continuation.
> I am 100% sure that all NetHandler continuations must be symmetrical/equal
> and have similar scheduling. I would prefer
> to reopen this RFE.
>
>
> Comment 3
> by Ryan Troll 3 years ago at 2006-12-27 06:47:47
> Reopened, with *very low* priority.
> I'd recommend waiting until the bigger items are done before tackling this.
> Yes, we may be spending time in DNS in
> this thread when we don't need to; and maybe a single DNS thread is the right
> answer. Or maybe modifying the DNS code
> to not bother with DNS continuations unless there are outstanding DNS
> requests makes more sense.
> However, I'd wait on this until we have time to go back and tune it. It may
> squeeze a little more performance out of
> the stack, but I suspect there are bigger wins to be gained through
> enhancements that are being actively requested by
> properties; or through enhancements we've already identified.
> It makes sense to keep this open so we don't forget about it. Hopefully
> we'll get to it later this year.
>
> Comment 4
> by Leif Hedstrom 3 years ago at 2006-12-27 07:42:47
> The reason I closed this bug was that the bug report indicated that this
> would be a problem under heavy load, with no
> caching. I don't believe that to be the case. In best case DNS lookups will
> be of O(1) complexity, and worst case it'd
> be O(n), where n is the number of origin servers. In either of those case,
> performing the actualy DNS lookups will be
> negligible as far as CPU consumption is concerned.
> However, with the comment from Vlad, it seems the concern is about wasting
> time on the DNS continuation, which I agree
> might be worth investigating. But I'd also like to see some benchmarks on how
> much this does affect us today. I'm not
> sure exactly how to test this. Vlad, is it possible to increase the timer for
> the DNS continuation to get scheduled,
> e.g. have it run every 1 second? Then we could easily benchmark what effect
> that has on performance.
>
>
> Comment 5
> by Vladimir Legalov 3 years ago at 2006-12-27 19:09:23
> The existence of this RFE does not mean that it will be taken on our
> development table immediately. It is a reminder
> only.
> As I already mentioned in the initial comments for this RFE: "Additional
> performance testing is required to
> clarify visibility of this problem."
> We have plenty of similar RFE's by priority and severity, which are not in
> active development. I was sure that P4 is
> clear evidence of such 'dormant' status.
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
