See my comments below: On Wed, Aug 29, 2012 at 4:06 PM, Robert G. Jakabosky <[email protected]>wrote:
> On Wednesday 29, Julie Anderson wrote: > > So questions remain: > > > > 1) What does ZeroMQ do under the rood that justifies so many extra clock > > cycles? (I am really curious to know) > > ZeroMQ is using background IO threads to do the sending/receiving. So the > extra latency is do to passing the messages between the application thread > and > the IO thread. > > This kind of thread architecture sucks for latency sensitive applications. That's why non-blocking I/O exists. That's my humble opinion and the numbers support it. > > > 2) Do people agree that 11 microseconds are just too much? > > No. A simple IO event loop using epoll is fine for a IO (network) bound > application, but if you need to do complex work (cpu bound) mixed with non- > blocking IO, then ZeroMQ can make it easy to scale. > Totally agree, but that has nothing to do with a financial application. Financial applications do not need to do complex CPU bound analysis like a image processing application would need. Financial application only cares about LATENCY and network I/O. > > Also try comparing the latency of Java NIO using TCP/UDP against ZeroMQ > using > the inproc transport using two threads in the same JVM instance. > What is the problem with inproc? Just use a method call in the same JVM or shared memory for different JVMs. If you want inter-thread communication there are blazing-fast solutions in Java for that too. For example, I would be surprised if ZeroMQ can come close to Disruptor for inter-thread communication. > > With ZeroMQ it is easy to do thread to thread, process to process, and/or > server to server communication all at the same time using the same > interface. > This generic API is cool, but it is solving a problem financial systems do not have and creating a bigger problem by adding latency. > > Basically ZeroMQ has different use-case then a simple IO event loop. > I thought ZeroMQ flagship customers were financial institutions. Then maybe I was wrong. > > -- > Robert G. Jakabosky > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
