In article <mailman.244.1267114628.4577.python-l...@python.org>, "D'Arcy J.M. Cain" <da...@druid.net> wrote:
> The problem had to do with the way TCP/IP works, especially closer to > the core. Our provider was collecting data and sending it only after > filling a buffer or after a timeout. The timeout was short so it > wouldn't normally be noticed and in most cases (web pages e.g.) the > connection is opened, data is pushed and the connection is closed so > the buffer is flushed immediately. Our patterns were different so we > were hitting the timeout on every single transaction and there was no > way we would have been able to keep up. > > Our first crack at fixing this was to simply add garbage to the packet > we were sending. Making the packets an order of magnitude bigger sped > up the proccessing dramatically. That wasn't a very clean solution > though so we looked for a better way. Interesting, the system I'm working with now has a similar problem. We've got a request/ack protocol over TCP which often sends lots of small packets and can have all sorts of performance issues because of this. In fact, we break completely on Solaris-10 with TCP Fusion enabled. We've gone back and forth with Sun on this (they claim what we're doing is broken, we claim TCP Fusion is broken). In the end, we just tell all of our Solaris-10 customers to disable TCP Fusion. -- http://mail.python.org/mailman/listinfo/python-list
