Chris, were you able to make it work fast? On Mon, Feb 7, 2011 at 18:55, Chris Morgan <[email protected]> wrote:
> 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 > > >
