wow. I am going to work on this myself when time allows, very interesting.
On Thursday, November 3, 2011, daniel williams <[email protected]> wrote: > Oddly enough that is how I'm doing it. Initially I thought that the > problem was with the Hammock library and began digging through the code and > noticed that they were creating the HttpWebRequest via the > WebRequest.Create. In noticing this I thought there could be some > additional caching overhead in the Hammock library. Pulling out exactly as > you have suggested produced the tcpdump I provided. It is the Windows 64 > bit / .NET 4.0 platform. I ran the same tcpdump with Hammock and it has > produced the same results. When I wrote the raw HTTP stream to a socket I > was able to do 4000 PUTs in 40s to a single instance of couchdb with the > 100-continue expect in line. > > I may simply rewrite GetById and Save to use a Socket instead of WebRequest > for the time being unless someone on this list knows of a better strategy. > > Thanks. > > dan > > On Thu, Nov 3, 2011 at 6:34 AM, Dennis Redfield < > [email protected]> wrote: > >> I am running on Windows XP 32 bit and am making my own calls to couchdb >> using Framework 4.0 and they are very fast. Nothing as slow as the number >> you are reporting. I am thinking it problem is with the library not the >> underlying system - Why not write your own calls like: >> >> HttpWebRequest myRequest =( HttpWebRequest ) WebRequest.Create( requestURL >> ); >> myRequest.MaximumAutomaticRedirections = _MaxRedirect; >> myRequest.MaximumResponseHeadersLength = _MaxHeadersLen; >> response = ( HttpWebResponse ) myRequest.GetResponse( ); >> Stream receiveStream=response.GetResponseStream( ); >> StreamReader readStream = new StreamReader( receiveStream, >> Encoding.UTF8 );//we shall see if this is right >> return readStream.ReadToEnd( ); >> >> Hope this helps. >> >> On Wednesday, November 2, 2011, daniel williams < [email protected] >> > >> wrote: >> > Hi, >> > >> > I posted an question the other day in regard to latency leveraging the >> > Redbranch Hammock library on windows. The codebase leverage the .NET 4.0 >> > HttpWebRequest class which seems to have some serious issues in it's >> > communication with CouchDB. I've noticed in a tcpdump on Mac with code >> > compiled in mono that a PUT/Save takes roughly 1~4ms total. The same >> code >> > run on Mono or .NET takes about 200 ms and in analyzing the tcpdump on >> > windows (through mono or .NET making the execution) that after the Http >> > Continue 100 is received the .NET/Mono code on Windows 64 bit will wait >> > 200ms roughly before sending the ACK to receive the response payload. >> See >> > below, I've changed the machine names: >> > >> > 10:03:04.552113 IP machine > server:5984: P 1:190(189) ack 1 win 256 >> > [email protected]....`.eQ.Ug.bP...7\..PUT >> > /test/TestEntity-8cdddd58-1860-429e-90 >> > 10:03:04.554113 IP server:5984 > machine: P 1:26(25) ack 190 win 65346 >> > [email protected].`..Ug.b.eR.P..B....HTTP/1.1 100 Continue >> > >> > >> > 10:03:04.554220 IP machine > server:5984: P 190:602(412) ack 26 win 256 >> > E...X.@ >> > >> .......oX..o....`.eR.Ug.{P...8;..{"Foo1":"foo","Foo2":"foo","Foo3":"foo","F >> > 10:03:04.558000 IP server:5984 > machine: P 26:351(325) ack 602 win 64934 >> > [email protected].`..Ug.{.eTDP.......HTTP/1.1 201 Created >> > Server: CouchDB/1.1. >> > 10:03:04.751642 IP machine > server:5984: . ack 351 win 255 >> > E..([email protected]....`.eTDUg..P...6... >> > 10:03:04.752131 IP server:5984 > machine: P 351:461(110) ack 602 win >> 64934 >> > E...I.@ >> > >> ...y...o...oX.`..Ug...eTDP....Y..{"ok":true,"id":"TestEntity-8cdddd58-1860- >> > >> > In doing a test in isolation on Windows 64 bit and .NET 4.0 I wrote a >> > TcpClient implementation that meets HTTP standards and I was able to PUT >> > 4000 records successfully in less than 40 secs. Does anyone out there >> know >> > of a more efficient library that can be used to communicate with the >> > CouchDB API on Windows 64 bit servers running .NET 4.0? Looking at the >> > results of my tests run it would seem the most efficient to do straight >> > socket communication. >> > >> > Thanks. >> > >> > dan >> > >> >> -- >> Trust No One >> > > > > -- > -dan > -- Trust No One
