Keep in mind that the way you used MINA is really very specific. I
don't have such performance simply because I never transfer such big
messages. If you consider that messages that will be exchanged never
exceed a few kilobytes, then performances are also excellent.
The way I used MINA is
Attached are the strace logs with the trace=network for the MINA
implementation and the simple NIO implementation. both ran for about 30
seconds.
As you can see the MINA implementation makes lots of getsockopt system calls
to get the receive buffer size (for each receive?).
In this link
The default is false...
I tried disabling Nagle by setting TcpNoDelay to true. As expected, this
didn't have any effect - the server doesn't send any data to the client,
only receives data.
On Tue, Nov 24, 2009 at 9:49 PM, Emmanuel Lecharny elecha...@apache.orgwrote:
Can you add this line in
Zvika Gart wrote:
The default is false...
I tried disabling Nagle by setting TcpNoDelay to true. As expected, this
didn't have any effect - the server doesn't send any data to the client,
only receives data.
Assuming that you are sending 8Kb buffers, anyway, it should not make
any
This is the code of my handler. It doesn't do anything. That's the point.
The server should just consume the data as fast as it can.
Strangely enough, Mina 2.0 performs even worse then 1.1.7
Is there some problem in using Java nio on Virtualized machines?
On Wed, Nov 25, 2009 at 11:00 AM,
Zvika Gart wrote:
This is the code of my handler. It doesn't do anything. That's the point.
The server should just consume the data as fast as it can.
Interesting. I have to test this code on my computer to see exactly what
can be the impact.
Can you add an executor in the filter cxhain to
The default threading model in 1.1.7 is to use the executor filter. I also
tried removing it. Both don't help.
I tested this scenario using two PCs at the office connected with a
crossover cable. The MINA server is reaching the 100 Mbps link speed limit.
Why running on Amazon's instances yields
Zvika Gart wrote:
The default threading model in 1.1.7 is to use the executor filter. I also
tried removing it. Both don't help.
Ok.
I tested this scenario using two PCs at the office connected with a
crossover cable. The MINA server is reaching the 100 Mbps link speed limit.
Why running on
Zvika Gart wrote:
- Check if there are some differences in the traffic (e.g. TCP ACK
patterns)
You didn't say anything about this yet.
- Check syscall patterns of the MINA version and try to see if something is
taking unreasonably long time (pure NIO implementation might be helpful
here)
Hello,
Please help, as this is too strange to be true...
I'm comparing two implementations of the most basic socket server - it
listens for a client, and after accepting it just starts reading data from
it.
The first implementation using Java's plain old ServerSocket:
ServerSocket srv =
Sorry, but Nagle doesn't have anything to do with this...
Nagle is relevant at the *client side* when sending small buffers over the
network.
My client is a simple C# program (not MINA, so SocketConnector is
irrelevant) that sends large buffers (100KB) at each call to Socket.Send()
If Nagle was to
Can you add this line in your server :
((SocketSessionConfig) acceptor.getSessionConfig()).setTcpNoDelay(false)
and see if it makes any difference ?
Zvika Gart wrote:
Sorry, but Nagle doesn't have anything to do with this...
Nagle is relevant at the *client side* when sending small buffers
12 matches
Mail list logo
