[swift-server-dev] HTTP API v0.1.0

[Carl Brown]

> On Nov 2, 2017, at 12:33 PM, Johannes Weiß <johannesweiss at apple.com> wrote:
> 
> Hi Carl,
> 
>> On 2 Nov 2017, at 9:15 am, Carl Brown via swift-server-dev <swift-server-dev at swift.org> wrote:
>> 
>> 
>>> On Nov 1, 2017, at 8:13 PM, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
>>> b) A complete ‘queue free’ model. I’m doing this in my current approach. It is kinda lock free, but has a lot of async dispatching. The base performance overhead is/should-be pretty high, but scalability is kinda like to optimal (theoretically making use of as many CPUs as possible).
>>> 
>>> Not sure how well this goes in Linux. Are DispatchQueue’s also cheap on Linux or does the current implementation create a new thread for each?
>> 
>> From what I've seen, they're pretty expensive on Linux.
>> 
>> I had a previous implementation (prior to https://github.com/carlbrown/HTTPSketch/commit/fd083cd30 ) that created a new `DispatchQueue` for every `accept()` (i.e. each new TCP connection), and it performed horribly on Linux.  It got much, much faster once I created a fixed pool of queues and reused/shared them between connections.
> 
> did you have anything that blocks on the queues? If yes, then that's probably why it performed badly (needed to spawn lots of threads).
> 
> The queues themselves should really be cheap but if there's fresh threads needed for lots of queues all the time, then performance will be bad. And probably terrible on Linux.

They shouldn't have been blocked in the "waiting around with nothing to do" sense, but they should all have been really busy (my high load test suite uses 60-80 simultaneous curl processes hitting an 8-core server).  There were lots of threads spawned, according to `top`.  When I constrained the number of queues to be roughly the same as the number of cores, performance got much better.

I should say that this was with Swift 3.1.X. I haven't re-run that test since Swift 4.0 shipped.  I don't know if there were any changes that would make for a different result now.

-Carl


> 
> -- Johannes
> 
> 
>> 
>> -Carl
>> 
>> _______________________________________________
>> swift-server-dev mailing list
>> swift-server-dev at swift.org <mailto:swift-server-dev at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-server-dev <https://lists.swift.org/mailman/listinfo/swift-server-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20171102/ebf604de/attachment.html>