>>>>> Philipp Marek writes:
>>> * I'm not sure if I understood correct, so I doublecheck: both your
>>> colleagues Java and Erlang programs use the same Java server as you
>>> do? (So we know the problem is at the lisp side.)
>> Yes, they all use the same server.
>> It seems that this is not simply an SBCL problem, as I originally
>> thought. I ran roughly the same code in ACL and SBCL, and saw the
>> same slowdown of socket traffic versus reading from a file.
>> Some format conversion might well be the issue. Digging deeper in
>> this code, which was supposed to be an optimization of an
>> interchange format that was originally ASCII, shows that the socket
>> streams are (a) bidirectional (the client sends a message to the
>> server to say "I'm done.") and (b) bivalent (the client's message is
>> the string "DONE"). This meant that the socket stream does not
>> provide any useful information to CL about the information it is
PM> Perhaps the problem is Nagle?
PM> If the Lisp side waits for some time before sending the (small)
PM> ACKs, it might explain the bad throughput.
+1. OP can also try to pass :nodelay t to usocket:socket-connect if one
is in use...
PM> Can you use the sb-posix:setsockopt() function to set TCP_NODELAY
PM> (http://linux.die.net/man/7/tcp) and sb-posix:write() for putting
PM> the ACK on the line?