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

[Helge Heß]

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?

> 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).

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. ¯\_(ツ)_/¯

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20171102/c0e552fa/attachment.sig>