[swift-server-dev] HTTP Parser

Samuel Kallner KALLNER at il.ibm.com
Fri Nov 4 03:50:22 CDT 2016 

I agree with Paulo. One of Swift's strong points is its ability to bind 
with all sorts of existing "system" C based APIs. Especially C APIs that 
are extremely well tested and maintained. We should all remember that 
while many of us may have taken the http_parser from Node, Node itself 
took it from Nginx. This code comes with great pedigree.

Why should we spend time developing an HTTP parser in Swift when we should 
be spending our collective time higher up the Web Server Framework 
toolchain? Alfredo Delli Bovi quoted the work that was done Dave Sperling 
to port the HTTP Parser Kitura was using to Swift. While he ported the 
code, he did not write the complete Unit Test Suite needed for that code. 
His own estimate was that writing the tests would be approximately two to 
three times the effort of the original port. I also seem to remember that 
the performance hit for that particular code was more than 33%.

Another point, which is especially true on current Swift drivers, is that 
any code that is going to parse something like HTTP requests and responses 
is probably going to have to work at the byte level and not that String 
level. This is due to performance issues. At the byte level its actually a 
lot easier to write C code, than Swift code. This may change in the 
future, but lets wait until this kind of thing gets more performant in 
Swift.

Some have said that readability is more important than performance. I for 
one, who have read the http_parser code from time to time, find rather 
readable for a tightly written finite state machine. Here I also beg to 
disagree that performance isn't important. In a server one wants to spend 
cycles doing real work for the requestor, not figuring out what he wants 
you to do. To scale one needs to be performant.

Shmuel Kallner
STSM Smart Client Platforms group
Tel: +972-4829-6430
e-mail: kallner at il.ibm.com




From:   Paulo Faria via swift-server-dev <swift-server-dev at swift.org>
To:     Logan Wright <logan at qutheory.io>
Cc:     Swift Server Dev <swift-server-dev at swift.org>
Date:   04/11/2016 00:15
Subject:        Re: [swift-server-dev] HTTP Parser
Sent by:        swift-server-dev-bounces at swift.org



I think wrapping a battle-tested C library is the way to go. Using a C 
library is not the same as writing one. In our case we?ll have to deal 
with C APIs anyway (POSIX), so the experience won?t be something we?re not 
used to already. Pragmatically here are the pros and cons:

Pros
- Faster to wrap a C lib than to write everything in Swift
- Safer to use a battle-tested C lib
- Better performance when handling strings (major current bottleneck for 
Swift)

Cons
- We need the OK from Chris Lattner
- If a bug is found we have to either:
  - fix it ourselves and push back upstream
  - if it?s something we don?t know how to fix we report and wait for the 
fix

I?ve been using http_parser on Zewo for over an year and I haven?t found a 
single bug yet. That?s *very* unlikely to happen if we write a Swift 
parser ourselves.

About the binary data discussion. I think something so important like that 
should reside in the standard library. I don?t think a protocol is a good 
idea because it promotes the creation of even more binary abstractions 
which is no good. I know the proposal of a new ?data? type on the standard 
library falls on what I just said, *but* in a perfect world Foundation 
would lose NSData in favor of the standard library Data pretty much like 
it did for NSString/String. Eventually all other frameworks would be using 
standard library?s Data too.

The feeling I got from Ted Kremenek is that we should picture the best 
scenario and then see where our work might land. This is the perfect case 
for that.


On Nov 3, 2016, at 6:49 PM, Logan Wright via swift-server-dev <
swift-server-dev at swift.org> wrote:

Following up with what Tanner and Chris said. I think HTTP 2 is 
particularly difficult, and you're right chris, bringing in a c library, 
even if just temporarily will help expedite the process in an efficient 
way.

I am however pretty ardently against porting C code to Swift as opposed to 
rethinking things for a Swift paradigm. If that's the case, I'd prefer to 
either link to the c code, or bring it into the Swift compiler. The end 
result would appear to be the same.

 - Logan

On Thu, Nov 3, 2016 at 4:46 PM Tanner Nelson via swift-server-dev <
swift-server-dev at swift.org> wrote:

Tanner Nelson
Vapor 
+1 (435) 773-2831

On Nov 3, 2016, at 4:34 PM, Helge Heß via swift-server-dev <
swift-server-dev at swift.org> wrote:

On 3 Nov 2016, at 19:41, Alfredo Delli Bovi <alfredo.dellibovi at gmail.com> 
wrote:
There has been some discussions about this in Kitura already (
https://github.com/IBM-Swift/Kitura-net/issues/52) and I think we can use 
what they found out at the moment.
In my opinion, if we are not able to give the same (or better) performance 
we should go for a wrapper of a more performant lib, such as http_parser.

They claim that their port is just ~1/3 slower, that seems perfectly 
reasonable to me. I?m all for using it.

As far as I can tell, the package in question here is a carbon copy of the 
C parser (UnsafePointers, asserts, global funcs). The only difference is 
it's 1/3 slower. 

A big performance hit like that is not worth it unless we're getting 
improved readability or safety out of the code. 


I also agree with the overall sentiment that a ?pure? Swift solution 
should be preferred.

Of course it?s also matter of the workload that have, we could always 
start with a wrapper, so we are able to define the APIs layer and ship a 
version with it and later on changing the implementation with a pure 
Swift.

Yes, the API should sit on top of this and be essentially parser agnostic.

hh

_______________________________________________
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
_______________________________________________
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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161104/d58d8b69/attachment.html>

More information about the swift-server-dev mailing list