Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Date: Tue, 30 Nov 2004 09:39:53 +0100 (CET)
From: Steve Hardy <steve@connectux.com>
To: Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
Subject: Re: Axis 1.3 bug
In-Reply-To: <170b01c4d564$1e572510$bcffff0a@LANKABOOK>
Message-ID: <Pine.LNX.4.10.10411300937100.16257-200000@griffin.sio2.nl>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
 BOUNDARY="-858469895-495524084-1101803993=:16257"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---858469895-495524084-1101803993=:16257
Content-Type: TEXT/PLAIN; charset=US-ASCII

Here is the patch for the axis2 transport.

In my setup (linux client, win32 server, both on 100mbit LAN, and around
1Ghz CPU's), this increases client-side performance from doing 5 requests
per second, to around 300 requests per second.

This is pretty good going for 2 lines of code ;)

The same patch could be applied to the axis transport, but I have not
tested this.

I will test it with the Keepalive option I read about in HEAD to see if
that further improver performance.

On Sun, 28 Nov 2004, Sanjiva Weerawarana wrote:

> Hi Steve,
> 
> Please submit the patch .. turning off Nagle had major impact
> on Axis/Java and Apache SOAP as well. This was esp. true when
> the client was a Win32 box ..
> 
> Sanjiva.
> 
> ----- Original Message ----- 
> From: "Steve Hardy" <steve@connectux.com>
> To: "Samisa Abeysinghe" <samisa_abeysinghe@yahoo.com>
> Cc: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
> Sent: Thursday, November 25, 2004 6:07 PM
> Subject: RE: Axis 1.3 bug
> 
> 
> > Hi Samisa,
> >
> > I have been experimenting some more and found that if I modify the
> > Calculator sample to do, say, 100 requests, it has a really bad
> > performance of only 5 requests per second... I have traced this to delays
> > caused by the Nagle algorithm in TCP, so I turned them off with
> > setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &one, sizeof(int)) in the
> > Channel.cpp files, which made the performance shoot up to 300 requests per
> > second on a single-threaded (win32) apache server (apache -X).
> >
> > Are you aware of this performance 'problem' and do you want a patch ? Or
> > was this a design decision ?
> >
> > Also, are there any plans for bumping up the performance by supporting
> > mutiple queries per HTTP connection? Experiments I have done with XMLRPC
> > show that you can get up to 3000 requests per second that way.
> >
> > by the way, apache2 seems to segfault in win32 when running
> > multi-threaded, but I'll look in to that later.
> >
> > On Thu, 25 Nov 2004, Samisa Abeysinghe wrote:
> >
> > > Hi Steve,
> > >     I have done the fixes in the CVS head. Please try with a freash
> ckeckout.
> > > Thanks,
> > > Samisa...
> > >
> > > --- Samisa Abeysinghe <SAbeysinghe@virtusa.com> wrote:
> > >
> > > >
> > > > Hi Steve,
> > > > Thank you for the valuable feedback.
> > > > I will look into these and fix them for 1.4 asap.
> > > > Regards,
> > > > Samisa...
> > > >
> > > > -----Original Message-----
> > > > From: Steve Hardy [mailto:steve@connectux.com]
> > > > Sent: Wednesday, November 24, 2004 6:52 PM
> > > > To: Samisa Abeysinghe
> > > > Subject: Re: Axis 1.3 bug
> > > >
> > > > And the same problem on line 230 with m_strServiceURI
> > > >
> > > > fixing these two problems (and using Xerces, expat didn't seem to
> work),
> > > > fixes the simpleserver on win32.
> > > >
> > > > On Wed, 24 Nov 2004, Steve Hardy wrote:
> > > >
> > > > > Hey there,
> > > > >
> > > > > I was looking at why axis doesn't want te run on my win32 platform,
> > > > and
> > > > > came across the following (bad) problem:
> > > > >
> > > > > SimpleAxisTransport.cpp, line 244:
> > > > >
> > > > > return m_strSOAPAction.substr(uiOpStart,
> > > > > m_strSOAPAction.length () -
> > > > > uiOpStart).c_str();
> > > > >
> > > > > This is a *bad thing* because you are returning a pointer with
> c_str()
> > > > to
> > > > > an unnamed string object (the one returned by substr) which is out
> of
> > > > > context when you return the function. This seems to work in linux,
> (as
> > > > > long as the stack isn't clobbered), but in windows this fails in
> debug
> > > > > mode for sure, and probably in release mode too (MSVC++ 6.0).
> > > > >
> > > > > I'd recommend recoding this to returning a string object or having a
> > > > > c_str() pointer from the m_strSOAPAction object as this doesn't go
> out
> > > > of
> > > > > context.
> > > > >
> > > > > Yours,
> > > > >   Steve Hardy
> > > > >
> > > > >
> > > >
> > > >
> > >
> > --------------------------- ----------------------------------------------
> -------------------
> > > > This message, including any attachments, contains confidential
> information intended for a
> > > > specific individual and purpose, and is intended for the addressee
> only. Any unauthorized
> > > > disclosure, use, dissemination, copying, or distribution of this
> message or any of its
> > > > attachments or the information contained in this e-mail, or the taking
> of any action based on
> > > > it, is strictly prohibited. If you are not the intended recipient,
> please notify the sender
> > > > immediately by return e-mail and delete this message.
> > > >
> > >
> > >
> > >
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Take Yahoo! Mail with you! Get it on your mobile phone.
> > > http://mobile.yahoo.com/maildemo
> > >
> >
> >
> 
> 

---858469895-495524084-1101803993=:16257
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="tcp-nodelay.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.10411300939530.16257@griffin.sio2.nl>
Content-Description: 
Content-Disposition: attachment; filename="tcp-nodelay.diff"

LS0tIGF4aXMtYy1zcmMtMS0zLWxpbnV4L3NyYy90cmFuc3BvcnQvYXhpczIv
Q2hhbm5lbC5jcHAJMjAwNC0xMC0yMiAxNDo1MDo0OS4wMDAwMDAwMDAgKzAy
MDANCisrKyBheGlzLWMtc3JjLTEtMy1saW51eC1ub2RlbGF5L3NyYy90cmFu
c3BvcnQvYXhpczIvQ2hhbm5lbC5jcHAJMjAwNC0xMS0zMCAwOTozMzo0NC40
NTE2MDQ4NTYgKzAxMDANCkBAIC0yMCw2ICsyMCw5IEBADQogICogQGF1dGhv
ciBTYW1pc2EgQWJleXNpbmdoZSAoc2FiZXlzaW5naGVAdmlydHVzYS5jb20p
DQogICovDQogDQorI2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KKyNpbmNsdWRl
IDxzeXMvc29ja2V0Lmg+DQorI2luY2x1ZGUgPG5ldGluZXQvdGNwLmg+DQog
I2luY2x1ZGUgIlBsYXRmb3JtLmgiDQogI2luY2x1ZGUgIkNoYW5uZWwuaCIN
CiAjaW5jbHVkZSA8aW9zdHJlYW0+DQpAQCAtMTIxLDYgKzEyNCwyMCBAQA0K
ICAgICAgICAgICAgIC8qQ2Fubm90IG9wZW4gYSBjaGFubmVsIHRvIHRoZSBy
ZW1vdGUgZW5kLCBzaHV0dGluZyBkb3duIHRoZSBjaGFubmVsKi8NCiAJICAg
IHRocm93IEF4aXNUcmFuc3BvcnRFeGNlcHRpb24oU0VSVkVSX1RSQU5TUE9S
VF9TT0NLRVRfQ09OTkVDVF9FUlJPUik7DQogCX0NCisNCisJLyogVHVybiBv
ZmYgdGhlIE5hZ2xlIGFsZ29yaXRobSAqLw0KKw0KKwkvKiBUaGlzIGlzIG5l
ZWRlZCwgYmVjYXVzZSBvdXIgVENQIHN0YWNrIHdvdWxkIG90aGVyd2lzZSB3
YWl0IGF0IG1vc3QNCisgICAgICAgICAqIDIwMCBtcyBiZWZvcmUgYWN0dWFs
bHkgc2VuZGluZyBkYXRhIHRvIHRoZSBzZXJ2ZXIgKHdoaWxlIHdhaXRpbmcg
Zm9yDQorCSAqIGEgZnVsbCBwYWNrZXQpLiBUaGlzIGxpbWl0cyBwZXJmb3Jt
YW5jZSB0byBhcm91bmQgNSByZXF1ZXN0cyBwZXINCisgICAgICAgICAqIHNl
Y29uZCwgd2hpY2ggaXMgbm90IGFjY2VwdGFibGUuIFR1cm5pbmcgb2ZmIHRo
ZSBOYWdsZSBhbGdvcml0aG0NCisJICogYWxsb3dzIGZvciBtdWNoIGZhc3Rl
ciB0cmFuc21pc3Npb24gb2Ygc21hbGwgcGFja2V0cywgYnV0IG1heQ0KKwkg
KiBkZWdyYWRlIGhpZ2gtYmFuZHdpZHRoIHRyYW5zbWlzc2lvbnMuDQorCSAq
Lw0KKw0KKwlpbnQgb25lID0gMTsNCisJc2V0c29ja29wdChtX1NvY2ssIElQ
UFJPVE9fVENQLCBUQ1BfTk9ERUxBWSwgKGNoYXIgKikmb25lLCBzaXplb2Yo
aW50KSk7DQorDQogICAgIH0NCiAgICAgZWxzZQ0KICAgICB7DQo=
---858469895-495524084-1101803993=:16257--