You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2004/09/17 21:02:16 UTC
multi-threading or performance and easy to work with code ? [Re:
Analysis of Axis C++ client transport
hi,
i am not sure by what you mean when you talk about multi-thread
transport and performance. it is much more efficient to avoid
synchronization required for multiple threads and simply attach
transport state to stub/skeleton. the only multi-thread re-use i would
worry is for sockets when doing HTTP keep-alive. otherwise performance
decreases, code complexity increases, and you have host of lovely bugs
typical in concurrent programming emerge ...
so i would aim for good design, ease of understanding, simplicity, and
performance in this order - multi-threading adds so much complexity that
it must be really really required to go this route and anyway i think
most of XML parsers are not multi-thread safe and that is where are
typical SOAP stack bottlenecks (CPU bound) not in network (IO bound) ...
just my .02PLN
alek
Samisa Abeysinghe wrote:
>Hi John,
> I believe that if we could get rid of the static globles then this new transport as well as the
>LibWWW transport would be thread safe. (However it is a *belief*, we have to practically try and
>see)
> If we could get LibWWW working with threads, then that is the best, as it supports many
>transports - not only HTTP - and we do not have to bother about transport specific stuff such as
>chunking etc.
>
> I would try and see if we could get rid of static globles and if that would free us from
>threading problems.
>
>Reagrds,
>Samisa...
>
>--- John Hawkins <HA...@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 <ax...@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
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: multi-threading or performance and easy to work with code ? [Re: Analysis of Axis C++ client transport
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi Alec,
What I meant by multi threads here is that if the users want to use the subs in a threaded
envioronment, then Axis c++ lib should support that.
I do not want the transport (or any other part of Axis C++) to use threads. However, for those
who wish to use the multiple stubs in threads, we have to make sure that Axis C++ lib is thread
safe.
I am *totally* in sync with you regarding the trouble that we bring into the code if we try to
make Axis C++ code multithreaded.
However we could refrain from using static globles etc..
Thansk,
Samisa...
--- Aleksander Slominski <as...@cs.indiana.edu> wrote:
> hi,
>
> i am not sure by what you mean when you talk about multi-thread
> transport and performance. it is much more efficient to avoid
> synchronization required for multiple threads and simply attach
> transport state to stub/skeleton. the only multi-thread re-use i would
> worry is for sockets when doing HTTP keep-alive. otherwise performance
> decreases, code complexity increases, and you have host of lovely bugs
> typical in concurrent programming emerge ...
>
> so i would aim for good design, ease of understanding, simplicity, and
> performance in this order - multi-threading adds so much complexity that
> it must be really really required to go this route and anyway i think
> most of XML parsers are not multi-thread safe and that is where are
> typical SOAP stack bottlenecks (CPU bound) not in network (IO bound) ...
>
> just my .02PLN
>
> alek
>
> Samisa Abeysinghe wrote:
>
> >Hi John,
> > I believe that if we could get rid of the static globles then this new transport as well as
> the
> >LibWWW transport would be thread safe. (However it is a *belief*, we have to practically try
> and
> >see)
> > If we could get LibWWW working with threads, then that is the best, as it supports many
> >transports - not only HTTP - and we do not have to bother about transport specific stuff such
> as
> >chunking etc.
> >
> > I would try and see if we could get rid of static globles and if that would free us from
> >threading problems.
> >
> >Reagrds,
> >Samisa...
> >
> >--- John Hawkins <HA...@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 <ax...@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]);
> >> }
>
=== message truncated ===
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail