axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Blecken" <cblec...@macrovision.com>
Subject RE: Analysis of Axis C++ client transport
Date Thu, 23 Sep 2004 16:54:12 GMT
Hi,

we are using axis c as a client against axis java running
on Jetty as a server. As soon as the request indicates 
HTTP 1.1 every reply from Jetty is chunked. 
This is just an answer to the question which server does
chunking.

I understand that chunking is a problem in order to get
to the highest performance but it happens at a loss of
generality (in this case compliance with RFC 2068).

On the keep-alive issue shouldn't be a model supported where
keep-alive and content length are supported, so that the
connection can be reused for another http soap request?

Thanks,

Carsten

-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
Sent: Thursday, September 23, 2004 9:24 AM
To: Apache AXIS C Developers List
Subject: Re: Analysis of Axis C++ client transport


I don't get why we're bothering with chunking .. can you tell
me which server-side does chunking right now? Axis/Java
certainly does not - it always sends one chunk!

Also, if we're not doing keep-alive, then you can forget
about computing content length and just stream the output thru
without bufferring. That gives you the memory benefit you get
from chunking at a loss of the keep-alive feature. As we
move forward in Web services in a more message-oriented model,
I don't see keep-alive being such a vital feature: its not
likely that apps will do series of very small and repeated
calls between the same client and server.

I suggest we forget chunking and add an option at least to turn
off bufferring and content-length computation. That will give
us even more speed!

Sanjiva.

----- Original Message ----- 
From: "John Hawkins" <HAWKINSJ@uk.ibm.com>
To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Sent: Thursday, September 23, 2004 4:17 PM
Subject: Re: Analysis of Axis C++ client transport


>
>
>
>
> Hi Samisa,
>
> Does the new transport have support for chunking  (and any other things
> that the old transport had)?
>
>
> John Hawkins
>
>
>
>
>
>              Samisa Abeysinghe
>              <samisa_abeysingh
>              e@yahoo.com>                                               To
>                                        Apache AXIS C Developers List
>              23/09/2004 04:20          <axis-c-dev@ws.apache.org>
>                                                                         cc
>
>              Please respond to                                     Subject
>               "Apache AXIS C           Re: Analysis of Axis C++ client
>              Developers List"          transport
>
>
>
>
>
>
>
>
>
>
> Hi All,
>     The new transport that I was talking about is in CVS
> (src/transport/axis2/)
>     This borrows many logic from the old one, however there are some
> considerable logic changes as
> well (but no magic ;-))
>
>     I strongly suggest that we try using this as the default transport
> considering the speed and
> the ability to send larger messages. This is also thread safe, after I
made
> the initialize_module
> possible outside the stub. But before we make this default, it has to be
> tested on Windows
> platform; I have so far tested only on Linux platform. Please help with
> testing on Windows.
>
>     I am now working to get LibWWW transport thread safe. This would take
> more effort as there
> need to be some lib level inits to be done. LibWWW is important,
> considering its rich set of
> features.
>
> Thanks,
> Samisa...
>
>
>
> --- John Hawkins <HAWKINSJ@uk.ibm.com> wrote:
>
> >
> >
> >
> >
> > Wow !!!
> >
> > The old code was really slow !
> > Your code is really fast :-)
> >
> > We do get other things with libwww though don't we?
> >
> >
> > If your code is better than the current code 9(and we can make it thread
> > safe and have the same function) then let's use it and ditch the
original
> > one?
> >
> >
> >
> > John Hawkins
> >
> >
> >
> >
> >
>
> >              Samisa Abeysinghe
>
> >              <samisa_abeysingh
>
> >              e@yahoo.com>
> To
> >                                        Apache AXIS C Developers List
>
> >              17/09/2004 09:39          <axis-c-dev@ws.apache.org>
>
> >
> cc
> >
>
> >              Please respond to
> Subject
> >               "Apache AXIS C           Analysis of Axis C++ client
>
> >              Developers List"          transport
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
> >
> >
> >
> > Hi All,
> >     Since I was under the impression that the current Axis transport lib
> > implementation is much
> > slower than LibWWW based implementation I did some measurers on the
speed
> > with echo string method
> > of base sample.
> >    The original Axis transport lib was much slower and hence I
> implemented
> > a new socket based Axis
> > transport lib with the logic similar to current Axis transport. The
> results
> > are interesting. The
> > original Axis transport implementation is too slow, and not only that,
it
> > cannot send messages
> > lager than 48800 (strage number), if I try to the client segfaults. The
> new
> > transport lib as well
> > as the LibWWW based transport can send much larger messages (I tested
> upto
> > 2621440 characters)
> >    The other interesting thing is that the new trasport that I
> implemented
> > are faster than LibWWW
> > based implementation.
> >     Please have a look at the attached HTML file for results.
> >
> >     At the moment, the Call class creates a new transport object for
each
> > and every invcation. I
> > made the code to reuse the same transport and the code became still
> faster.
> >
> >     However, testing for thread safety, both LibWWW and the new
transport
> > failed, only the old
> > trasport work with threads. I am doubtful of this, because in the new
> > transport I have very
> > similar logic to that of the old (but not the same) I doubt the old
> > transport pretends to be
> > thread safe as it is too slow. We have to remove the globle variables
> from
> > the code and see if
> > this thread safety problems would persist. We must look into thread
> safety
> > as an immediate high
> > priority issue.
> >
> >     As the code is frozen at the moment for 1.3 I did not commit the new
> > trasport. It works for
> > chunks as well, however it would have to be tested more to be used in
> > production envioronments.
> > Hence, even if I put it in cvs, I would like it to be seperate from the
> > original Axis transport
> > lib. I have removed all cyclic couplings in this new code and hence it
> > would be easier to
> > maintain.
> >
> >     I have given below the client code that I used for this testing
(with
> > base.wsdl generated
> > code)
> >
> > Thanks,
> > Samisa...
> >
> > #include <string>
> > #include <iostream>
> > #include <time.h>
> > #include <stdio.h>
> > #include <sys/types.h>
> > #include <sys/timeb.h>
> >
> > #ifdef WIN32
> > #else
> > #include <sys/times.h>
> > #include <unistd.h>
> > #endif
> >
> >
> > #include <axis/AxisGenException.h>
> > #include "./gen_src/InteropTestPortType.h"
> >
> > using namespace std;
> >
> > #define STRING_TO_SEND "HelloWorld"
> >
> > static void
> > usage (char *programName, char *defaultURL)
> > {
> >     cout << "\nUsage:\n"
> >              << programName << " [-? | service_url] " << endl
> >              << "    -?             Show this help.\n"
> >              << "    service_url    URL of the service.\n"
> >              << "    Default service URL is assumed to be " <<
defaultURL
> >              <<
> >              "\n    Could use http://localhost:8080/axis/services/echo
to
> > test with Axis Java."
> >              << endl;
> > }
> >
> >
> > int
> > main (int argc, char *argv[])
> > {
> >     int length = 10;
> >     char endpoint[256];
> >
> >     // Set default service URL
> >     sprintf (endpoint, "http://localhost/axis/base");
> >     // Could use http://localhost:8080/axis/services/echo to test with
> Axis
> > Java
> >
> >     try
> >     {
> >
> >              if (argc > 1)
> >              {
> >                  // Watch for special case help request
> >                  if (!strncmp (argv[1], "-", 1)) // Check for - only so
> > that it works for
> >                                             //-?, -h
or --help; -anything
> >                  {
> >                          usage (argv[0], endpoint);
> >                          return 2;
> >                  }
> >                  length = atoi(argv[1]);
> >              }
> >
> >         if (argc > 2)
> >             sprintf (endpoint, argv[2]);
> >
> >              cout << endl << " Using service at " << endpoint
<< endl <<
> > endl;
> >
> >              InteropTestPortType ws (endpoint);
> >
> >         ws.setTransportTimeout(2);
> >
> >         // Prepare the string to be sent
> >         char* buffer = new char[ length * strlen(STRING_TO_SEND) + 1];
> >         buffer[0] = '\0';
> >         for (int i = 0; i < length; i++ )
> >             strcat(buffer, STRING_TO_SEND);
> >
> >              // Time mesurement stuff
> >              time_t startTime;
> >         time_t endTime;
> >
> >              time( &startTime );
> >
> >         char* echoStringResult = ws.echoString(buffer);
> >
> >              time( &endTime );
> >         printf( "Time spent to invoke method ws.echoString(buffer); =
%lf
> > s\n", difftime( endTime,
> > startTime ) );
> >
> >              if (0 == strcmp(echoStringResult, buffer))
> >                  printf ("successful\n");
> >              else
> >                  printf ("failed\n");
> >
> >         // Clean memory
> >         if (echoStringResult)
> >             free(echoStringResult);
> >
> >         delete [] buffer;
> >
> >
> === message truncated ===
>
>
>
>
> _______________________________
> Do you Yahoo!?
> Declare Yourself - Register online to vote today!
> http://vote.yahoo.com
>
>
>


Mime
View raw message