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

[Johannes Weiß]

Hi,

> On 2 Nov 2017, at 9:54 am, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> On 2. Nov 2017, at 17:15, Carl Brown <carl.brown.swift at linuxswift.com> 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.
> 
> Do we know why? Is that a transient issue that is going to be fixed in the future? Do they actually create a new thread per queue?

good point. I reckon it's what I described (delay in spawning threads on Linux). But instead of guessing we should really have a minimal reproduction that shows the issue. No HTTP server but really only a thing that imitates the queue spawning behaviour. We could then analyse why it's slow and what to fix.


>> 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.
> 
> This is what I wondered about. Yes, I also went with a DispatchQueue per connection first but a pool would be possible too. (though this really sounds kinda wrong and counter to the GCD idea).

I don't think a pool of queues will help as I think they only get a thread spawned if there's work on them and the existing threads are all blocked. But again, we need a minimal benchmark/repro. The queue target hierarchy is very important to get the best performance out of GCD. This video has the latest information, can highly recommend: https://developer.apple.com/videos/play/wwdc2017/706/


-- Johannes


> In my a) and c) scenarios, you would just share one or a few top-level ‘global’ queues, so that would be different too. Much less synchronisation overhead, but for c) you need to give the handler a way to dispatch back to the right queue.
> 
> 
> If we get concurrency in Swift 5, and get actors, I would assume that the mailbox of an actor is a queue. If those don't scale on Linux … ;->
> 
> hh
> 
> P.S.: I think GCD may be fine for this project, I’m not yet convinced it is the right choice for like a bigger deployment. ¯\_(ツ)_/¯
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev