add gRPC-haskell benchmark

[4eUeP]

Summary of changes

Bench gRPC-haskell

BTW: This Haskell implement server may have some memory leaks.

Tested on my local machine: AMD 5900X, 64G RAM, with the following options:

GRPC_BENCHMARK_DURATION=120s
GRPC_BENCHMARK_WARMUP=30s
GRPC_CLIENT_CONNECTIONS=50
GRPC_CLIENT_CONCURRENCY=1000
GRPC_CLIENT_QPS=0
GRPC_CLIENT_CPUS=9
GRPC_REQUEST_SCENARIO=complex_proto
GRPC_SERVER_RAM=1g
GRPC_SERVER_CPUS=1

It requires GRPC_SERVER_RAM to be at least 1g. If I run with the default GRPC_SERVER_RAM (which is 512m), the container will be killed because of running out of memory.

[LesnyRumcajs]

@4eUeP thanks for the PR! In general, a memory leak doesn't sound good. There is already a Haskell implementation that was disabled because (as far as I remember) of some dependency issues. Maybe you could look at it and try to re-enable it? I think it didn't have any leaks. What do you think?

[4eUeP]

@LesnyRumcajs Hi, AFAIK the mu-haskell (which is already in this repo but currently disabled) is a bit slower than grpc-haskell. Anyway, re-enable it sounds useful. I'll try to look at it :)

[4eUeP]

Unfortunately, there are more than "dependency issues" in the mu-haskell library. The simple string scenario compiles but the complex scenario does not. I opened a related issue: higherkindness/mu-haskell#336 for this.

[LesnyRumcajs]

@4eUeP makes sense. I'm not a Haskell expert, can we somehow get rid of the leak? In general, the implementations here should serve as an example, it'd be bad if someone copies them and gets into trouble with memory leaks.

[4eUeP]

@LesnyRumcajs Hi, I think the leak is from the library itself, so we can't get rid of it here easily. However, I'll open an issue (or pr) to the upstream grpc-haskell repo and try to fix it if I have time.

[LesnyRumcajs]

@LesnyRumcajs Hi, I think the leak is from the library itself, so we can't get rid of it here easily. However, I'll open an issue (or pr) to the upstream grpc-haskell repo and try to fix it if I have time.

Sounds good to me, thanks! That'd really help the Haskell ecosystem in this field. In general, if a library has leaks on a rather simplistic RPC call then it's not really benchmark nor production ready.

[LesnyRumcajs]

@4eUeP Do you plan to play with this some more, or should I close this PR for now?

[4eUeP]

@LesnyRumcajs Sorry for the delay. Since the fix PR(awakesecurity/gRPC-haskell#140) hasn't been merged, let's go ahead and close this now.

[LesnyRumcajs]

@4eUeP Thanks. Something seems to be moving in the blocking issue, so hopefully, it will get resolved eventually.