Return-Path: X-Original-To: apmail-cxf-users-archive@www.apache.org Delivered-To: apmail-cxf-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3433E1095B for ; Mon, 21 Oct 2013 16:39:24 +0000 (UTC) Received: (qmail 167 invoked by uid 500); 21 Oct 2013 16:39:22 -0000 Delivered-To: apmail-cxf-users-archive@cxf.apache.org Received: (qmail 99686 invoked by uid 500); 21 Oct 2013 16:39:21 -0000 Mailing-List: contact users-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cxf.apache.org Delivered-To: mailing list users@cxf.apache.org Received: (qmail 99677 invoked by uid 99); 21 Oct 2013 16:39:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Oct 2013 16:39:20 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bretthumphreys@google.com designates 209.85.215.50 as permitted sender) Received: from [209.85.215.50] (HELO mail-la0-f50.google.com) (209.85.215.50) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Oct 2013 16:39:15 +0000 Received: by mail-la0-f50.google.com with SMTP id ec20so2327464lab.37 for ; Mon, 21 Oct 2013 09:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=X0yXDzU/wpj8NR/dJb6wsjyE3M/Hk7ykUkC/cbgSoFQ=; b=Pci22XNS1Mq9CE0xn9vLJJq/V3qrp6+Md7f2CczLeSbRgrPY94FSHk+qWDGYfTOLG3 UkgQmeiPw5eiIuf1wFacnpTro4aGTekkm9vGaIrvrQfZepQF3LqbJAot9P4Bdl7XvhY/ no9kYXDX1CpbwfPrN4m18Y4zqHs02GZUvhEqeixokBqnp7QVF26XvKNT/T3EG5bS9jds du7RwlH+TD3+vhCP2cvsNUeTFJJYM1E5vKjKzImM1HcV5hBOl8Itj+ojPEl1lRv5P3Et 30TPoK5Lgx1kuWzmklSZyP2zLiSgZtlZuH9Qr1vMSh8PIwK5oqMtvVcwrOVW606hWtX8 VKTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=X0yXDzU/wpj8NR/dJb6wsjyE3M/Hk7ykUkC/cbgSoFQ=; b=eDXndj+0QdYoDGXyPZtwF5VgkrJAYcWzWikG0K6FYmM8rDgq2VuJg43FgNviPtJ0D1 aH5s0KiQlvLiFp5diNKzFJQt1sXBMwtLCmV4Yn5FEO/bEhVUrcFKTN0VDUOZpOfuM5BE INb6j9v16HelTn3kWkjB8CXDQNBUpjA5xf6Bcr4JLvIbXH2IILWpxQYYtMd9yux1guU/ RItQCOr0i4y+tadvTlmf+Iw83lKUr1OYind7ZkLkYNUuV65hZvndmwIUhItPGlkWby45 uBGrO2hmRdZPklAtdPvqqx0XrszDzu+YgRrd9QaLaMz8qdM5SuxtfU6rATaLkrIoUUoC ge5g== X-Gm-Message-State: ALoCoQmPdVcT6jSRVJRJ0Ktf9I2f7olhU7w7C8IPW57h6xvbWDpebwGzi4O0BIteTC8iSf+0bv3z+sVfGYg+ITfTlSC9Xly6iW7d632QqPe9uKp2D8HSFoDVXCEWYwNHr3nPprVyVIO7HUDCKVKKIsJFdzJ1fNUGho2kPRaFXielKJDwU0KpphuskmVOQ6sSA2dE886Xxuke MIME-Version: 1.0 X-Received: by 10.112.64.7 with SMTP id k7mr1839271lbs.43.1382373534025; Mon, 21 Oct 2013 09:38:54 -0700 (PDT) Received: by 10.114.62.72 with HTTP; Mon, 21 Oct 2013 09:38:53 -0700 (PDT) Date: Mon, 21 Oct 2013 10:38:53 -0600 Message-ID: Subject: Jetty SSL Performance From: Brett Humphreys To: users@cxf.apache.org Content-Type: multipart/alternative; boundary=001a11c3fba271670d04e942eba9 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c3fba271670d04e942eba9 Content-Type: text/plain; charset=ISO-8859-1 Hi all, This may be a bit off the wall, but I'm trying to squeeze out the most performance out of Jetty that I can. However I have some constraints that I can't change in the near term. Specifically: 1. I'm using a relatively ancient version of CXF (2.2.12) 2. I'm *not* using keep-alive What I'd like to reach is about 180 SOAP operations per second (OPS) on this jetty server, which is simulating a 3rd party server. It seems that it takes Jetty ~350ms to negotiate the SSL connection. So what I'm seeing is I get about 3 (technically 2.96 consistently) SOAP OPS with the Jetty instance. If I turn on keep-alives, then my performance goes through the roof (I see it take about ~20ms, but I think this is multithreaded) to about 150 SOAP OPS. So without any heroics, is there a way that I can push jetty to get better performance without setting keep-alives to true on my client? The reason for lack of keep alive connections is I'm trying to make sure that under load I can still negotiate the SSL connections. Since I talk to third parties through this interface I don't want to assume they'll have keep-alives turned on. FWIW, I also have client authentication turned on. Here's some relevant config about my server: ClientAuthentication clientAuth = new ClientAuthentication(); clientAuth.setRequired(true); clientAuth.setWant(true); I'm using very small keystores and truststores (1-2 entries each). And I have the TLS cipher suites limited to a dozen or so trusted cipher suites. Thanks! Brett Humphreys --001a11c3fba271670d04e942eba9--