[swift-server-dev] Next HTTP API meeting

Carl Brown1 Carl.Brown1 at ibm.com
Mon Mar 27 12:07:01 CDT 2017


Hi, Tanner,

When I'm writing SSS code for an iOS endpoint that talks to a back-end
service, I'll often dispatch an URLSession.dataTask() to go ask the
back-end for data, and then request/response handling occurs in the
completion handler when the dataTask comes back.

I find that to be a really common pattern when I'm working in an Enterprise
and I have some kind of legacy service I need to talk to.

-Carl



From:	Tanner Nelson via swift-server-dev <swift-server-dev at swift.org>
To:	Chris Bailey <BAILEYC at uk.ibm.com>
Cc:	swift-server-dev <swift-server-dev at swift.org>
Date:	03/27/2017 09:42 AM
Subject:	Re: [swift-server-dev] Next HTTP API meeting
Sent by:	swift-server-dev-bounces at swift.org



@chris in my experience there's been very little passing of
request/response between threads. Usually the server accepts, spins up a
new thread, and all HTTP parsing/serializing happens on that one thread.

Could you specify some examples where requests/responses are being passed
between threads?

That said, it should be fairly easy to implement threading to see what the
effects would be. I will look into that. :)

Tanner

Vapor
tanner at vapor.codes

      On Mar 27, 2017, at 3:37 PM, Chris Bailey <BAILEYC at uk.ibm.com> wrote:

      Nice work!

      Taking a quick look at the project and screenshot, am I right in
      saying that there is no concurrency in the test? ARC generally has a
      bigger impact in concurrent use cases because of the need to keep
      memory consistency across processors for the atomic
      increment/decrement.

      How hard would it be to add a dispatch queue in?

      Chris



      From:        Tanner Nelson via swift-server-dev <
      swift-server-dev at swift.org>
      To:        Michael Chiu <hatsuneyuji at icloud.com>
      Cc:        swift-server-dev <swift-server-dev at swift.org>
      Date:        27/03/2017 14:38
      Subject:        Re: [swift-server-dev] Next HTTP API meeting
      Sent by:        swift-server-dev-bounces at swift.org



      Re: performance,

      I did a quick test of inout struct vs. class performance. The code
      can be found here: https://github.com/tanner0101/request-types

      I found only a marginal increase in performance (~5%) in favor of
      inout value types.
      https://github.com/tanner0101/request-types/issues/1

      Additionally, non-inout value types were a lot slower. This is
      obvious to the seasoned Swift dev considering each middleware in the
      test modifies and thus must copy the request. But this is the exact
      type of performance issue you can expect developers to create when
      interacting with "non-obvious value types". HTTP request/response
      being non-obvious value types compared to something like an integer
      or a float. (I'd argue the majority of web developers would expect
      request/response to be a reference type and thus easily forget or not
      know to use `inout`)

      Please feel free to submit any prs/issues/comments about ways I could
      improve this test to make it more accurate.

      tl;dr: value types don't seem much faster than reference types
      (especially considering dangers of misuse) in a simulated web
      framework scenario

      inb4: people saying that the request/response models in my test are
      incomplete/not fully implemented/bad. this is _not_ a proposed api
      for request/response.

      Vapor
      tanner at vapor.codes

      On Mar 27, 2017, at 1:55 PM, Michael Chiu via swift-server-dev <
      swift-server-dev at swift.org> wrote:


      On Mar 27, 2017, at 5:13 AM, Logan Wright via swift-server-dev <
      swift-server-dev at swift.org> wrote:
      If people feel extremely strong that there needs to be a concrete
      type, then I'd like to push for reference type as much as possible.
      As far as reference vs value type, I haven't really heard an argument
      for value types beyond what feels like a reaction to value types
      being the hip new hotness. While yes, they're great in Swift, and
      there's tons of places that should absolutely be modeled with value
      semantics, a request/response interaction represents a single request
      and should definitely be a reference based interaction.

      I disagree with this one. First of all I think most of the framework
      pass the request and response as inout argument, if that is the case
      there shouldn’t be much copy overhead in the run loop. Second the
      problem of reference type is that everywhere the request and response
      exists could possibly mutate the res/req, and it affect globally. It
      is true that in normal use there shouldn’t be two place
      simultaneously operate on the same request but that could happen.
      (Therefore protocol is the best isn’t it)

      In practice, we went through several model iterations and the value
      type created very high levels of bugs and confusion for end users.
      The three biggest problems we had were as follows:

      - Greatly increased bug levels and confusion related to unexpected
      mutation
      - Unnecessary code requirements added to every single passive access
      (ie: middleware) increasing code bloat unnecessarily
      - Extreme performance loss due to massive copy overhead

      Each of these problems evaporated pretty instantaneously when moving
      to reference types; it made it significantly easier to reason about
      for end users.
      Just for curiosity, I’m very interested in the unexpected mutation of
      value semantic, I have always had an impression of value semantic are
      more free from unexpected mutation.

      Would like to remind again for those that skipped above reading that
      our goal is not to build a web framework here, but rather to build
      small tools that make building frameworks slightly easier for library
      maintainers and creators.
      That’s so true lol.

      Michael.

      _______________________________________________
      swift-server-dev mailing list
      swift-server-dev at swift.org
      https://lists.swift.org/mailman/listinfo/swift-server-dev
      _______________________________________________
      swift-server-dev mailing list
      swift-server-dev at swift.org
      https://lists.swift.org/mailman/listinfo/swift-server-dev



      Unless stated otherwise above:
      IBM United Kingdom Limited - Registered in England and Wales with
      number 741598.
      Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
      PO6 3AU
_______________________________________________
swift-server-dev mailing list
swift-server-dev at swift.org
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/20170327/c6e50c9d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170327/c6e50c9d/attachment.gif>


More information about the swift-server-dev mailing list