Limited read buffer size in Async backend to 32K.

[artemkin]

There was unlimited buffer allocation in Async backend. It affected uploading of big files a lot. It was at least 10 times slower than downloading the same file. After the fix, uploading and downloading speeds seem to be on par.

Anyway, it is still not that good as new buffer is allocated for every single chunk. The buffer should be reused for all chunks for better performance.

[rgrinberg]

Yes the buffer allocation is very much not ideal. There's no "easy" way to fix it either. The whole IO layer should be reworked to stop allocating stuff with more efficient buffer management reimplemented on top of that.

Your fix is good however as we really should have a limit on the buffer size that we allocate. I'm merging this in.

Thanks.

[artemkin]

Yes, I see. Maybe add it to #198 or report a separate issue? Performance is a feature for production systems. It seems people (including myself) wish to use cohttp for real world tasks (see #328).

I would contribute more, but the biggest problem for me is actually reading the codebase. A lot of functors + module openings just blow my mind. Any tips how to read that?

[rgrinberg]

#198 only talks about interface breaking changes. I would hope that sane buffer management is not going to break people's code (but I've been wrong about this before).

I'll try and write something up on how to contribute/understand cohttp a little more. We do end up with a lot of complexity for trying to support multiple backends. But there's method to this madness.

[avsm]

@artemkin I feel your pain. One good way is to work from the lib/ directory into async/ and then into lwt/. The Merlin IDE tool helps unwrap the types. Documentation would most definitely help though.

[trevorsummerssmith]

@avsm Getting off topic now but I think the high level design you wrote in this thread: http://lists.xenproject.org/archives/html/mirageos-devel/2015-03/msg00137.html would be very helpful to drop into the codebase basically verbatim.

[artemkin]

@rgrinberg @avsm Could you release v0.17.1 with this fix? It is critical defect, and it is not convenient to use pinned repo. Guys who admin the server wish to build it locally, and they're not OCaml-ers yet)

[avsm]

Yes; can do this afternoon.

[avsm]

See #332 and DESIGN.md skeleton committed, @trevorsummerssmith

[trevorsummerssmith]

Thanks I think that will be a great help to new contributors!

[artemkin]

Great! Thank you

[vbmithr]

Please revert this. The semantics of read / read_exactly is not conserved anymore and this introduce bugs (Like #357).