Return-Path: Delivered-To: apmail-xml-security-dev-archive@www.apache.org Received: (qmail 89310 invoked from network); 29 Oct 2007 15:02:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Oct 2007 15:02:43 -0000 Received: (qmail 51163 invoked by uid 500); 29 Oct 2007 15:00:52 -0000 Delivered-To: apmail-xml-security-dev-archive@xml.apache.org Received: (qmail 51148 invoked by uid 500); 29 Oct 2007 15:00:52 -0000 Mailing-List: contact security-dev-help@xml.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: Reply-To: security-dev@xml.apache.org List-Id: Delivered-To: mailing list security-dev@xml.apache.org Received: (qmail 51133 invoked by uid 99); 29 Oct 2007 15:00:52 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Oct 2007 08:00:52 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of raul.benito.garcia@gmail.com designates 209.85.134.184 as permitted sender) Received: from [209.85.134.184] (HELO mu-out-0910.google.com) (209.85.134.184) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Oct 2007 15:00:55 +0000 Received: by mu-out-0910.google.com with SMTP id g7so2121037muf for ; Mon, 29 Oct 2007 08:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=UmUjBJtNGMU2gTC/JHkZRi50WLdbnzeo7+qI4PO8PzU=; b=RXgt4i2SrT8FXn5vi7oLGPnfmFkzNqQ5vBxSn3APu7th1WVHt70bxofVo4qVCdRqo7hQYliMWwx8r302PLnM/n4kbCOwnzXcsfQmvYYsl4OpLhJExd9tNlh3ww3Ul/8YHI8wPPKy5XoqjLbtDaaPeMEHhzrPmIZy30A02MZcOPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=eBHV+A3km3zpPdi6IxieG4L2Yi9jRZcNhpcxLXslA5M2v4PUWHxlHLQ792btbI7MQN7A7CRLTRaaTQrlKaNylYfkeXbUF3zVa0x4pXoPcEE1BSu1PXHZgjPYFOhX+5uJPN3wxjaGMyU0w0FWKtA79mkNNwg4vu8OFC7h5MIp1aY= Received: by 10.82.146.14 with SMTP id t14mr10800604bud.1193670033827; Mon, 29 Oct 2007 08:00:33 -0700 (PDT) Received: by 10.82.106.13 with HTTP; Mon, 29 Oct 2007 08:00:33 -0700 (PDT) Message-ID: <949ac9410710290800p61f63318tdc2ed378814a56b7@mail.gmail.com> Date: Mon, 29 Oct 2007 08:00:33 -0700 From: "Raul Benito" Sender: raul.benito.garcia@gmail.com To: security-dev@xml.apache.org Subject: Re: Is there a difference in memory usage between Apache-Java-XmlSecurity and Apache-C++-XmlSecurity? In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3025_13581014.1193670033808" References: X-Google-Sender-Auth: 289cd550c2e21042 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_3025_13581014.1193670033808 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Andre, Your memory problems are DOM realated the XML-SEC library only needs 10MB t= o verify any document. So in order to improve it you must look using the expermiental STAX implementation or the SAX one. Regards, Raul p.s. I haven't take a deep look to the encrypt/decrypting part so perahps we have some problems there. On 10/29/07, Andr=E9 wrote: > > Hallo. > > We use apache-xml-security java-implementation for signature and > encryption on > the client and validation and decryption on the server. > > On both sides we have "problems" with the hunger for memory of the java- > implementation. We use version 1.3, but I already tried version 1.4 and > have > found no difference! > > But this time I'm interrested in the server-side: > For example an signed and encrypted xml-doc of 50MB will need MORE than > 600MB > to decrypt. With about 1000MB memory it works fine (factor: 20!). > In our scenario there can be many parallel requests for decryption. > Less memory needed would be fine! > > Is the C++-implementation less memory-hungry? > > Has anybody tried it out and can give me a kind of comparison result? > Thank's! > > Bye, Andr=E9 > > > --=20 http://r-bg.com ------=_Part_3025_13581014.1193670033808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Andre,
Your memory problems are DOM realated the XML-SEC library only= needs 10MB to verify any document.
So in order to improve it you must l= ook using the expermiental STAX implementation or the SAX one.

Regar= ds,

Raul


p.s. I haven't take a deep look to the encrypt/= decrypting part  so perahps we have some problems there.

<= span class=3D"gmail_quote">On 10/29/07, Andr= =E9 < Andre.Stoyke@bdr.de> wrote:
Hallo.
We use apache-xml-security java-implementation for signature and encryption= on
the client and validation and decryption on the server.

On bo= th sides we have "problems" with the hunger for memory of the jav= a-
implementation. We use version 1.3, but I already tried version 1.4 and= have
found no difference!

But this time I'm interrested in t= he server-side:
For example an signed and encrypted xml-doc of 50MB will= need MORE than 600MB
to decrypt. With about 1000MB memory it works fine (factor: 20!).
In= our scenario there can be many parallel requests for decryption.
Less m= emory needed would be fine!

Is the C++-implementation less memory-hu= ngry?

Has anybody tried it out and can give me a kind of comparison resul= t?
Thank's!

Bye, Andr=E9




--
http://r-bg.com ------=_Part_3025_13581014.1193670033808--