[erlang-questions] gen_tcp receving slow

[igwan]

Ok, here's a simple test case in attempt to isolate the problem :

--------------------------
-module(tcptest).

-compile(export_all).

listener(Port) ->
    {ok, ListenSocket} = gen_tcp:listen(Port, [{packet, raw}, {active, 
true}, binary]),
    {ok, Socket} = gen_tcp:accept(ListenSocket, 60000),
    io:format("Incoming connection accepted.\n"),
    receiver(Socket).

receiver(Socket) ->
    receiver(Socket, 0, []).

receiver(Socket, Count, TimeStamp) ->
    receive
        {tcp, Socket, Data} when Count =:= 0 ->
            receiver(Socket, Count + size(Data), now());
        {tcp, Socket, Data} ->
            receiver(Socket, Count + size(Data), TimeStamp);
        {tcp_closed, Socket} ->
            TimeDiff = timer:now_diff(now(), TimeStamp),
            io:format("Received ~p bytes in ~p ms.\n",[Count, 
TimeDiff/1000]),
            gen_tcp:close(Socket);
        _Other ->
            io:format("Unexpected message : ~p\n", [_Other]),
            gen_tcp:close(Socket)
    end.

--------------------------

I start my listener on an erlang node then start a netcat on another 
shell session to send a 20MB file :

igwan@REDACTED:~$ cat 20M.txt | nc -q 0 127.0.0.1 1234

13> tcptest:listener(1234).
Incoming connection accepted.
Received 20399370 bytes in 5803.51 ms.
ok

That's roughly 3,5 MB/s ... and here's top output during the transfer :

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23093 igwan      25   0 11532 7024 1868 R 97.9  0.7   1:01.39 beam
23151 igwan      18   0  3176  476  408 S  0.7  0.0   0:01.41 cat
23152 igwan      15   0  1736  624  524 S  0.7  0.1   0:01.22 nc


Thanks

igwan






igwan a écrit :
> I bypassed my parsing code, just to be sure, and tested on 
> Linux and Win32 with R11B-5, all this on the loopback interface. The 
> incoming data throughput doesn't get over 5 MB/s or so during the 
> transfer while my Intel 2Ghz Intel CPU is 100 % busy with "werl". On my 
> linux box, it's around 2,5MB/s on a 2Ghz Via CPU, again 100% busy.
>