Return-Path: Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org Received: (qmail 9522 invoked from network); 3 Feb 2009 11:26:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Feb 2009 11:26:24 -0000 Received: (qmail 50151 invoked by uid 500); 3 Feb 2009 11:26:23 -0000 Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org Received: (qmail 49458 invoked by uid 500); 3 Feb 2009 11:26:20 -0000 Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: core-dev@hadoop.apache.org Delivered-To: mailing list core-dev@hadoop.apache.org Received: (qmail 49445 invoked by uid 99); 3 Feb 2009 11:26:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Feb 2009 03:26:20 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Feb 2009 11:26:19 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C078E234C48D for ; Tue, 3 Feb 2009 03:25:59 -0800 (PST) Message-ID: <856720453.1233660359774.JavaMail.jira@brutus> Date: Tue, 3 Feb 2009 03:25:59 -0800 (PST) From: "Jothi Padmanabhan (JIRA)" To: core-dev@hadoop.apache.org Subject: [jira] Updated: (HADOOP-1338) Improve the shuffle phase by using the "connection: keep-alive" and doing batch transfers of files MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HADOOP-1338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jothi Padmanabhan updated HADOOP-1338: -------------------------------------- Attachment: hadoop-1338-v1.patch Attached a patch that batches fetch of map outputs. The maximum size that needs to be pulled from a tasktracker per connection is configurable. The number of maps requested is adapted. For the first 1%, 1 map is requested per connection. Subsequently, upon learning the average size of maps, the number of maps to request is determined using the maximum size. The number of maps is still bounded by a limit imposed on the size of the HTTP request that the servlet can handle. > Improve the shuffle phase by using the "connection: keep-alive" and doing batch transfers of files > -------------------------------------------------------------------------------------------------- > > Key: HADOOP-1338 > URL: https://issues.apache.org/jira/browse/HADOOP-1338 > Project: Hadoop Core > Issue Type: Improvement > Components: mapred > Reporter: Devaraj Das > Assignee: Jothi Padmanabhan > Attachments: hadoop-1338-v1.patch > > > We should do transfers of map outputs at the granularity of *total-bytes-transferred* rather than the current way of transferring a single file and then closing the connection to the server. A single TaskTracker might have a couple of map output files for a given reduce, and we should transfer multiple of them (upto a certain total size) in a single connection to the TaskTracker. Using HTTP-1.1's keep-alive connection would help since it would keep the connection open for more than one file transfer. We should limit the transfers to a certain size so that we don't hold up a jetty thread indefinitely (and cause timeouts for other clients). > Overall, this should give us improved performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.