On 16 January 2014 16:35, Boxer, Aaron <aaron.bo...@uhn.ca> wrote: > Thanks, Oleg. I am not trying to criticize the project in any way; > just wondering if anyone has insight into why, on Windows, Java NIO is so > much slower than stream IO.
If it is only slower for DVD copies, that seems more like an issue with DVD caching. Are you sure that the synch and asynch tests both started from exactly the same environment? What do you mean by environment? Both tests read the same DVD, after flushing the Windows OS file cache. But, the clients are, of course, set up differently. Would you like me to post how I am configuring the clients? > Perhaps it has to do with buffer size, thread count, ..... ? > > -----Original Message----- > From: Oleg Kalnichevski [mailto:ol...@apache.org] > Sent: Thursday, January 16, 2014 11:15 AM > To: HttpClient User Discussion > Subject: Re: ZeroCopyPut mystery > > On Thu, 2014-01-16 at 04:33 +0000, Boxer, Aaron wrote: >> Hello, >> >> When I use ZeroCopyPut with hard drive (spinning disk ) disk files, I get a >> network transfer rate of about 250 MBPS for first time read of files; 850 >> MBPS if the files are already in the Windows OS file cache. Synchronous put >> gives me about 30 MBPS. >> >> But, when I am dealing with files on DVD, I get a network transfer rate of 5 >> MBPS for first time read of files, and 850 MBPS if files are in the OS file >> cache. >> Synchronous put gives me about 30 MBPS. >> >> So, in the case of first read of DVD files, synchronous client is superior. >> Synchronous should be faster, because it can read and send at the same time. >> >> Does this make sense? It seems a little strange to me. >> > > Aaron, > > Zero copy data transfer is very platform specific. Java merely provides a > common APIs, which however can have radically different implementations on > different platforms and therefore can have different performance > characteristics. > > I guess these numbers have more to do with Windows than with HttpAsyncClient. > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > This e-mail may contain confidential and/or privileged information for the > sole use of the intended recipient. > Any review or distribution by anyone other than the person for whom it was > originally intended is strictly prohibited. > If you have received this e-mail in error, please contact the sender and > delete all copies. > Opinions, conclusions or other information contained in this e-mail may not > be that of the organization. --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org This e-mail may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this e-mail may not be that of the organization. --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
