- web-devel - Haskell.org

WAI 2.0
by Kazu Yamamoto 03 Oct '13

03 Oct '13

Hi all, I created an issue to discuss WAI 2.0. If you are interested, please join: https://github.com/yesodweb/wai/issues/178 --Kazu

1 0

HTTP pipelining and constant space usage?
by Jeremy Shaw 18 Sep '13

18 Sep '13

It seems like HTTP pipelining and constant space usage are at odds with each other. A quick review of HTTP pipelining, http://en.wikipedia.org/wiki/HTTP_pipelining Handling persistent HTTP connections is no big deal, but HTTP pipelining is troublesome (which is why Opera is the only browser that has it enabled by default). The problem is that the client is allowed to send an unlimited number of Requests before it bothers to read any Responses. If your server uses the model of read a single Request and send the Response entirely before moving onto the next Request, then you could potentially deadlock because the client is still in the sending phase and you are blocked on a write(). So, we are basically forced to read all the Requests before sending a Response? But, then the client could perform a DoS by sending millions of requests.. Any thoughts on how best to handle this? Perhaps the only sane solution is to assume that any client that is going to using pipelining is going to be nice enough to actually read Responses even if it is still sending additional Requests (i.e., it has a writer thread and a reader thread)? In which case we can continue to read and respond to one request at a time[1]? I'm pretty sure this is what all the Haskell HTTP servers do at the moment and I have not heard any complaints... - jeremy [1] In theory, the server could processes multiple Requests in parallel as long as it returns the Responses in the correct order. Though it's not clear if this would actually help performance in most cases. Given the lack of pipelining support in clients anyway, it's nothing something I am especially interested in optimizing. :)

3 3

Sending a Response before the Request has been entirely consumed?
by Jeremy Shaw 18 Sep '13

18 Sep '13

Hello, Is it valid for a server to start sending an HTTP Response before the Request has been entirely consumed? Or to put it differently, is there any case where it would be valid for the Response message-body to be streaming the value from the Request message-body? Doing that seems like it would, in general, not be a good idea. For example, if you started sending a 200 OK response, and then you encountered a parse error in the Request message body, there is no way to go back and change to an error status code. One slight exception seems to be the use of 100 (Continue), section 8.2.3, http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html but even there, you are just looking at the Request headers, not trying to stream from the Request message body to the Response message body. In this section: http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6 It says, "After receiving and interpreting a request message, a server responds with an HTTP response message." Which could be interpreted to mean that the entire request message must be received and interpreted before the response can be sent. But, that could be reading too much into it. I'd rather see something like: "The server MUST read the entire request message before sending a response." Any thoughts? Is there any definitive statement? Are there any real world examples where you would want to stream the request message body into the response? For example, a service where you can PUT/POST a document, and it gets transformed on the fly and returned in the response? At this point I am inclined to design the server such that you must read the entire request message before you can begin sending the response. But, if that is a mistake, I'd love to hear about it now ;) - jeremy

4 5

yesod mysql
by Grant Weyburne 17 Sep '13

17 Sep '13

Hi all, I am trying to use Yesod with Mysql on Windows but cannot get the mysql package to build. I can see that there is an error report about this problem that hasn't been addressed for the past 11 months: https://github.com/bos/mysql/issues/3 At the moment this means that the only real database on Windows is Postgres, but I can only use mysql or mssql in this project. Since it doesn't look like this problem will be solved any time soon, can anyone think of reasonable alternatives? So far my only thought is using an Odbc interface with a subset of the persistent functionality. This could additonally open up access to MS Sql Server and Oracle. Anyway, I'd appreciate your thoughts about this. Thanks so much, Grant

3 4

oops
by Grant Weyburne 16 Sep '13

16 Sep '13

Sorry for the multiple posts, Grant

1 0

Next version of WAI: cleaning house
by Michael Snoyman 12 Aug '13

12 Aug '13

Some of you may have seen the brief interchange between Kazu and myself regarding ResourceT in WAI. Let me give a very brief synopsis of the situation: - In order to allow WAI applications to acquire scarce resources like file handles in an exception-safe way, WAI actions all live in a `ResourceT IO` monad, instead of just `IO`. - Kazu has mentioned to me in the past that, based on his profiling, monadic bind for ResourceT may currently be a bottleneck in WAI. - I made an experimental change to WAI so that, instead of actions living in `ResourceT IO`, the WAI Request value contains a ResourceT InternalState value, which can be used to accomplish the exact same thing as living in ResourceT (see [1]). - Kazu checked out the performance difference of this new branch, and it allows for some better optimizations. If this was purely a performance optimization, I would probably just optimize Warp and not bother changing WAI. However, I think that this change makes WAI itself better as well, and therefore am in favor of making this as a breaking change, releasing it as WAI 2.0[2]. Firstly, are there any objections to this move? So as long as we're making a breaking change, the question arises: what other changes should we be making to WAI? I know Kazu had mentioned adding fields to avoid the need for lookups, can you clarify that request a bit? Here are some other changes I can think of: - Remove the deprecated isSecure field from the Request data type. - Remove the misleading fields serverName and serverPort fields as well. - Possibly: hide the Request constructor so that new fields can be added without breaking backwards compatibility. If anyone else has some ideas, please bring them up. [1] http://haddocks.fpcomplete.com/fp/7.4.2/20130704-120/resourcet/Control-Mona… [2] For the Yesod community: the change is minor enough that Yesod 1.2 can have some conditional compilation to support both the current WAI 1.4 and WAI 2.0, so this shouldn't affect most Yesod users at all.

9 31

witty v0.0.0 has been release
by Kazu Yamamoto 01 Aug '13

01 Aug '13

Hi all, To demonstrate the bottlenecks of GHC, I have released "witty", a simple network server. If you specify command line options, "witty" uses ideas to overcome the bottlenecks. I hope we can use "witty" to convince ourselves of the problems and discuss how to fix them. You can install "witty" by % cabal update; cabal install witty For more information, please read: https://github.com/kazu-yamamoto/witty/blob/master/README.md --Kazu

1 0

Re: [web-devel] [Yesod] Next version of WAI: cleaning house
by Greg Weber 25 Jul '13

25 Jul '13

When a request hits a handler, it will already have gone through the middleware, so it only seems possible to alter how the response is handled at that point. If you want different middleware for different routes, that is something that must be handled at the routing level, so it seems out of the scope of WAI. But if you explain your use case on the Yesod mail list we can try and come up with a more convenient solution. I do have a WAI middleware that checks routes that might benefit from this. On Thu, Jul 25, 2013 at 10:20 AM, Robert Lee <robert.lee(a)chicago.vc> wrote: > Is it possible in the present design to change middleware modules at the > level of a handler? > > On Tue, 2013-07-23 at 13:04 +0300, Michael Snoyman wrote: > > Some of you may have seen the brief interchange between Kazu and > > myself regarding ResourceT in WAI. Let me give a very brief synopsis > > of the situation: > > * In order to allow WAI applications to acquire scarce resources > > like file handles in an exception-safe way, WAI actions all > > live > > > -- > You received this message because you are subscribed to the Google Groups > "Yesod Web Framework" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to yesodweb+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > >

1 0

Making throughput much better
by Kazu Yamamoto 23 Jul '13

23 Jul '13

Hi all, Cc: Simon Marlow I think I found a way to make the throughput of web servers much better. In short, put "Control.Concurrent.yield" after sending something. This enables good schedule shaping. Typical code for web servers is like this: loop = do keepAlive <- receiveRequest sendResponse when keepAlive loop With this code, a typical sequence of system calls is like this: recvfrom(13, ) -- thread A sendto(13, ) -- thread A recvfrom(13, ) = -1 EAGAIN -- thread A epoll_ctl(3, ) -- IO manager recvfrom(14, ) -- thread B sendto(14, ) -- thread B recvfrom(14, ) = -1 EAGAIN -- thread B epoll_ctl(3, ) -- IO manager Since each thread calls recvfrom() immediately after sendto(), the possibility that recvfrom() can receive a request is low. This involves the IO manager. To make the possibility higher, I put "yield" after sendResponse: loop = do keepAlive <- receiveRequest sendResponse yield when keepAlive loop Yield pushes its Haskell thread onto the end of thread queue. So, another thread can work. During the work of other threads, a request message would arrive. recvfrom(13, ) -- thread A sendto(13, ) -- thread A recvfrom(14, ) -- thread B sendto(14, ) -- thread B recvfrom(13, ) -- thread A sendto(13, ) -- thread A I tested this idea on SimpleServer and confirmed that its throughput is doubled: No yield: 58,152 req/s (https://gist.github.com/AndreasVoellmy/4184520#file-simpleserver-hs) Yield: 113,048 req/s (https://gist.github.com/kazu-yamamoto/6051118#file-simpleserver2-hs) Unfortunately, yield does not work for Warp as expected. It does not pass control to another thread and behaves as used to be. So, my question: why doesn't "yield" work in Warp? ResourceT is doing a special thing? My code change is here: https://github.com/yesodweb/wai/commit/4e9c6316ad59cd87be13000d15df8e6fd7c3… I'm using GHC head (with multicore IO manager). I'm sure that the following patch to fix the bug of yield is applied: https://github.com/ghc/ghc/commit/66839957a376dbe85608822c1820eb6c99210883 P.S. It would be appreciated if someone tries this idea on other web servers. --Kazu

3 4

Automatic error traces
by Alberto G. Corona 18 Jul '13

18 Jul '13

It is important to have execution traces in case of error. specially in server applications that run 24/7 such are web applications Thanks to the wonderful package monadloc by Pepe Iborra, now MFlow can generate a complete execution trace in case of error. The control-monad-exception uses monadLoc to generate stack traces, but MFlow makes use of his backtracking mechanism to generate a complete execution trace. Here I explain what and how: http://haskell-web.blogspot.com.es/2013/07/automatic-error-trace-generation… The MFlow version that implements this is in gitHub. Not in hackage yet. https://github.com/agocorona/MFlow I´m quite proud of it since it is one of the things closest to magic that I have done. Feedback? I do not want to keep MFlow as a single person development. I think that it has many unique and nice features not available in other languages and frameworks, and it can be raised to a serious exploitation level by the Haskell community. This will attract people working in Industrial Web development to Haskell thanks to the edge in expressiveness and safety necessary for creating industrial solutions that Haskell has over other languages. It uses most other Haskell web developments blaze, wai, hamlet etc and there are many other things to come. monadLoc : http://hackage.haskell.org/package/monadloc -- Alberto.

2 3