Switch to Cohttp

[vouillon]

No description provided.

[smorimoto]

Issue mirage/ocaml-cohttp#328 still remains in cohttp, and unless we fix this first, I think there is a problem as a framework used in enterprise applications. There is also httpaf as an alternative, but it still doesn't support SSL/TLS, so fixing cohttp seems easier and smarter.

[mseri]

Do you know what is the latency difference between the version pre and post port to cohttp? If you have time, can you check if tweaking the values below before creating the server improves the situation?

Conduit_lwt_unix.set_max_active 256;
Lwt_io.set_default_buffer_size 0x10000;

[smorimoto]

@mseri I will try it later. However, it's already confirmed that the problem can be reproduced with the latest cohttp, so the comparison between the patched version and the original version will be still meaningful.

[mseri]

it's already confirmed that the problem can be reproduced with the latest cohttp

Oh sure, my question was about comparing the current eliom, eliom with this port to cohttp, and eliom with this port to cohttp with the additional limits on max active connections (256 is quite low, probably 1024 is more realistic) and a different Lwt_io buffer size (the default is 0x1000, just 4k).

[mseri]

I will try it later.

Thanks a lot!

[smorimoto]

Oh, I see. Then it seems better to compare the old ocsigenserver and cohttp.

[jrochel]

@smorimoto According to @vouillon the performance issues as per mirage/ocaml-cohttp#328 are not a blocking issue, so I'm merging.

[smorimoto]

I see!