Return-Path: X-Original-To: apmail-jmeter-dev-archive@minotaur.apache.org Delivered-To: apmail-jmeter-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0C75711806 for ; Mon, 1 Sep 2014 19:25:57 +0000 (UTC) Received: (qmail 20308 invoked by uid 500); 1 Sep 2014 19:25:56 -0000 Delivered-To: apmail-jmeter-dev-archive@jmeter.apache.org Received: (qmail 20279 invoked by uid 500); 1 Sep 2014 19:25:56 -0000 Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jmeter.apache.org Delivered-To: mailing list dev@jmeter.apache.org Received: (qmail 20259 invoked by uid 99); 1 Sep 2014 19:25:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Sep 2014 19:25:56 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=AC_DIV_BONANZA,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of philippe.mouawad@gmail.com designates 209.85.213.179 as permitted sender) Received: from [209.85.213.179] (HELO mail-ig0-f179.google.com) (209.85.213.179) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 Sep 2014 19:25:51 +0000 Received: by mail-ig0-f179.google.com with SMTP id r2so6153851igi.12 for ; Mon, 01 Sep 2014 12:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=b+7sviyvFphdjsVqhffB3/OPIU3ivAIiq60yFkDLFSQ=; b=OHmT9ps8t+vaNElMRVHKtOnrUdsHkx8kBTQuWPpF9rI+eq/IAQdqDQB6rycSJwkr/p /naJFF5ni6BIl9ZbmMI9CYoqY21SvF69f69H3XFCtZF3Q9EkqA5+zZAxRRW+IUuCO85C I72ti9bF1BTUhce/TW6g0JSy4w/BsYs71d4WPUBLwcZbUB9oratmqmjQiCEVElTmQCaX j0NB0d350NI9Qm2enKcHVMcE4aix3FyBYzSYqNWkYmb1YdTbxEKRGexeKjGWjNfLRqNZ Uknwtt3C6NI6oUb0g/FzpjkaAwbpa6BBJiZsLD4RQBBR2wZInlC+80bAirZdOPDiXNtx 9O8g== MIME-Version: 1.0 X-Received: by 10.42.201.134 with SMTP id fa6mr3406045icb.73.1409599530457; Mon, 01 Sep 2014 12:25:30 -0700 (PDT) Received: by 10.42.50.141 with HTTP; Mon, 1 Sep 2014 12:25:30 -0700 (PDT) Date: Mon, 1 Sep 2014 21:25:30 +0200 Message-ID: Subject: About ThreadLocal / Threads / HttpClient in JMeter From: Philippe Mouawad To: "dev@jmeter.apache.org" Content-Type: multipart/alternative; boundary=90e6ba6e848849e2bc050205f7b0 X-Virus-Checked: Checked by ClamAV on apache.org --90e6ba6e848849e2bc050205f7b0 Content-Type: text/plain; charset=ISO-8859-1 Hello, Working on: - https://issues.apache.org/bugzilla/show_bug.cgi?id=52073 I am currently stucked. To recap the initial issue: - To download embedded resources we init and shutdown a ThreadPoolExecutor limiting the benefit of a Thread pool to the sole Sampler call. - As a side effect (see below) , as this will result in the init of a new HttpClient this will not perform fine due to SSLContext eager creation (see below) So I started working on a patch that: - Made the ThreadPoolExecutor static - Used a Blocking Queue to limit the number of downloads 1 Sampler can do See the attached patch. And this is were I hit a problem. Indeed we hold in ThreadLocal the HttpClient instance per Thread which each thread needs to cleanup at end. But with this design when thread ends it cleans up its state, this is a problem: - Currently an HttpClient will be reinitialized for each thread of the Pool, this init has a cost particularly due to eager init of SSL context , see http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/201405.mbox/%3C1400143180.23146.7.camel@ubuntu%3E - For the issue, this is a bigger problem, as I need to hold the list of HttpSamplerProxy to call threadFinished at end, but this cannot work as the list would grow huge accros the lifetime of a thread during a load test ending with OOM. It grows huge because each time we call AsyncSample#call we clone the HTTPSamplerBase and register it in the list. Furthermore we cannot call "threadFinished" at end of Callable call (AsynSample) Thinking about the fix I have the following ideas but they require some work: - First rework HC usage to only use 1 HttpClient for all threads - Rework ThreadLocal usage: * Currently we use ThreadLocal 47 times but the use is split among 2 Use case: 1) One is to improve performance, this one looks OK to me 2) One is in fact a way to associate User Data to Thread , the thread being in fact a User. I think we should rework those Thread Locals and move them to a singleton that would be keyed on userId (could be a simple increased number associated to thread). Doing so would allow us in the future to move from Threads to a ThreadPool. Thoughts ? Regards Philippe @philmdot --90e6ba6e848849e2bc050205f7b0--