On 8/20/09 9:48 AM, "Ananth T. Sarathy" <[email protected]> wrote:
> ok.. i seems that's the case. that seems kind of selfdefeating though. > > Ananth T Sarathy Then something is wrong with S3. It may be misconfigured, or just poor performance. I have no experience with S3 but 20 seconds to connect (authenticate?) and open a file seems very slow for any file system. > > > On Thu, Aug 20, 2009 at 12:31 PM, Scott Carey <[email protected]>wrote: > >> If it always takes a very long time to start transferring data, get a few >> stack dumps (jstack or kill -e) during this period to see what it is doing >> during this time. >> >> Most likely, the client is doing nothing but waiting on the remote side. >> >> >> On 8/20/09 8:02 AM, "Ananth T. Sarathy" <[email protected]> >> wrote: >> >>> it's not really 1 mbps so much it takes 2 minutes to start doing the >>> reads..... >>> >>> Ananth T Sarathy >>> >>> >>> On Wed, Aug 19, 2009 at 4:30 PM, Scott Carey <[email protected] >>> wrote: >>> >>>> >>>> On 8/19/09 10:58 AM, "Raghu Angadi" <[email protected]> wrote: >>>> >>>>> Edward Capriolo wrote: >>>>>>> On Wed, Aug 19, 2009 at 11:11 AM, Edward Capriolo >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>>>> It would be as fast as underlying filesystem goes. >>>>>>>> I would not agree with that statement. There is overhead. >>>>> >>>>> You might be misinterpreting my comment. There is of course some over >>>>> head (at the least the procedure calls).. depending on you underlying >>>>> filesystem, there could be extra buffer copies and CRC overhead. But >>>>> none of that explains transfer as slow as 1 MBps (if my interpretation >>>>> of of results is correct). >>>>> >>>>> Raghu. >>>> >>>> >>>> Yes, there is nothing about distributing work for parallel execution >> that >>>> is >>>> going to make a single 20MB file transfer faster. That is very slow, >> and >>>> should be on the order of a second or so, not multiple minutes. >>>> Something else is wrong. >>>> >>>> >>>> >>> >> >> >
