Hi Jonathan. I see two issues:
1. How is ANYONE going to know that they will get 1000x the performance with c#/mono(maybe even under ms .net) if they use TFramedTransport vs. TServerSocket? 2. If the right thing is to use TFramedTransport then why not remove TCP_NODELAY from java, cpp and whatever other platforms that set it? 3. If people want to keep TCP_NODELAY on for java and cpp then why not enable it for c# to make it the same as the rest? Chris On Mon, Feb 7, 2011 at 4:51 PM, Jonathan Ellis <[email protected]> wrote: > You're right, it doesn't set nodelay. Alexey's analysis was that "If > TFramedTransport used just one write() call per frame, there is no > need for setNoTcpDelay." > > I don't know if he was right or not but it was a deliberate choice and > not an oversight. > > On Mon, Feb 7, 2011 at 3:08 PM, Chris Morgan <[email protected]> wrote: >> Hi Bryan. >> >> Actually haven't heard this before. Just started using thrift a few >> days ago. I'll gladly try that for additional performance. >> >> I'd also like to resolve the issue for future users that may consider >> using thrift with mono and abandon the idea when they get 30 messages >> /sec. >> >> Shouldn't the c# TServerSocket work like the cpp and java ones do in >> terms of disabling nagle? >> >> Chris >> >> >> >> On Mon, Feb 7, 2011 at 4:05 PM, Bryan Duxbury <[email protected]> wrote: >>> You're probably tired of hearing this already, but please, please use >>> buffered or framed transport. It will make your servers and clients >>> noticeably faster in a lot of cases. >>> >>> On Mon, Feb 7, 2011 at 12:48 PM, Chris Morgan <[email protected]> wrote: >>> >>>> Hi Jonathan. >>>> >>>> If it were committed wouldn't it be present in svn trunk? I'm using >>>> svn trunk because I was hoping it had been fixed since the last >>>> release. >>>> >>>> I looked at the commit, c1063966, and I don't see any mention of >>>> disabling nodelay and the changes are modifying >>>> src/Transport/TFramedTransport.cs >>>> >>>> My server code looks like: >>>> >>>> var ourProcessor = new OurProcessor(); >>>> var processor = new TheProcessor.Processor(ourProcessor); >>>> TServerTransport serverTransport = new TServerSocket(9090); >>>> TServer server = new TSimpleServer(processor, >>>> serverTransport); >>>> >>>> So I'm not sure how the changes made to TFramedTransport would be >>>> affecting TServerSocket since they don't seem connected. >>>> >>>> Chris >>>> >>>> >>>> On Mon, Feb 7, 2011 at 3:36 PM, Jonathan Ellis <[email protected]> wrote: >>>> > Read the ticket you got the patch from -- it's been committed for the >>>> > next release. >>>> > >>>> > On Mon, Feb 7, 2011 at 2:32 PM, Chris Morgan <[email protected]> wrote: >>>> >> On Mon, Feb 7, 2011 at 3:30 PM, Chris Morgan <[email protected]> >>>> wrote: >>>> >>> I just tested it out and setting NoDelay on the socket brought the >>>> >>> rate up from 30msg/sec up to ~12k msg/sec which is fine for me for >>>> >>> now. >>>> >>> >>>> >>> What now? It looks like the guy that fixed the issue reported by >>>> >>> Jonathan says the solution is to used a frame transport? It still >>>> >>> looks like this is an issue with whatever the default transport is, >>>> >>> TServerSocket I guess? >>>> >>> >>>> >>> Chris >>>> >>> >>>> >> >>>> >> In addition the cpp TSocket.cpp sets TCP_NODELAY. Why shouldn't c# do >>>> >> what cpp and java do? >>>> >> >>>> >> Chris >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > Jonathan Ellis >>>> > Project Chair, Apache Cassandra >>>> > co-founder of DataStax, the source for professional Cassandra support >>>> > http://www.datastax.com >>>> > >>>> >>> >> > > > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder of DataStax, the source for professional Cassandra support > http://www.datastax.com >
