Loading ...
Sorry, an error occurred while loading the content.

Re: [soaplite] SOAP::Serializer::envelope

Expand Messages
  • Paul Kulchenko
    Hi, Douglas! Right observation and interesting solution. Seems like you took version prior 0.50, but idea is fully applicable to the current version also.
    Message 1 of 3 , Apr 30, 2001
    • 0 Attachment
      Hi, Douglas!

      Right observation and interesting solution. Seems like you took
      version prior 0.50, but idea is fully applicable to the current
      version also. Thanks a lot.

      I plan to address performance issues and even think about
      implementing option for parsing/creating messages with known
      structure with regexpes, without parsing/creating XML from scratch
      every time. For example you have a service that returns temperature.
      Why should you create the SAME message every time if only one value
      is different? Generate is once, save as a template and then update
      template with new value. I see the benefits, but it's not for all
      situations. The same thing is true about parsing. From the same
      client you are getting similar requests. Teach your implementation
      once and then parse it with regexpes instead of XML parsing. If
      template match something in your library, use it. If not, do it usual
      way and store result in the library. If done in the right way, should
      be transparent for server side, but quite benefitial (at least seems
      to be). I'll do some tests later this week. Thoughts?

      Best wishes, Paul.

      --- Douglas Bonar <Doug.Bonar@...> wrote:
      > Some use around here indicated that using SOAP-Lite just
      > as a way to construct SOAP messages for a non-Perl server
      > is slow. (This is cases where we have explicit message
      > templates we want to construct, rather than taking advantage
      > of SOAP-Lite's strength at automarshalling the arguments
      > and return values from Perl functions.) Looking at some
      > DProf results, it appeared that one of the main reasons
      > is that SOAP-Lite spends a fair chunk of time in parsing
      > some boilerplate Envelope/Header/Body parts of the message
      > structure.
      >
      > As a test example, I built a simple soap message three
      > different ways.
      >
      > The first way (labeled 'mine' below) was with a module I wrote
      > for the purpose. Basically it lets you specify your elements,
      > their values and attributes and their relationships. It then
      > translates that into XML and wraps it in a simple Envelope/Header/
      > Body construct. There is nothing automagic in the module. It is
      > only one step above putting the messages in here documents, but
      > is fairly fast.
      >
      > The second way ('freeform') was to use the above module to
      > build the body of the message and then passing that to SOAP-Lite
      > asking it to make a freeform message (of type 'xml') out of
      > that string. That way SOAP-Lite isn't doing any parsing of
      > my data, only its own.
      >
      > The final way was to build my data with SOAP::Data elements.
      > This is the way I would prefer to construct the messages. In
      > the resulting code, it looks about the same as using the special
      > purpose test module. Internally though this is more likely
      > to do the right thing is special cases.
      >
      >
      > 5 methods, 100 message builds of a fairly simple message.
      > The system time was about the same for all cases. There is
      > no transport or message parsing going on.
      >
      > Method User Time Relative Comments encode_object
      > ========================================================
      > mine 1.91 sec 100% reference 0/mes.
      >
      > freeform 4.64 sec 243% 10/mes.
      > method 5.65 sec 296% 14/mes.
      >
      > freeform' 3.30 sec 173% 29% savings 3/mes.
      > method' 4.38 sec 229% 22% savings 7/mes.
      >
      >
      > The 'correct' way is almost 3 times slower than the special
      > purpose building. And the number of calls to the
      > SOAP::Serializer::encode_object method per message created
      > is quite high. In fact, even if I provde the XML string with
      > all the real content there are still 10 calls to encode_object.
      >
      > Looking at SOAP::Serializer::envelope, it was clear that the
      > many of the calls are there because of the method builds the
      > message internally by calls to encode_object. The structure
      > of those calls is the same every time though, it is just
      > boilerplate.
      > "Unrolling" that code (see below) gave the primed results in
      > the table above. 20% savings on a small message (obviously
      > proportionally less on a large message). Given that many
      > SOAP messages probably are small, that's not too bad.
      >
      > I think the change doesn't interfer with anything else in
      > the module. The results from my test cases are identical
      > message with either the old or new code.
      >
      > Doug
      >
      >
      >
      > The change (in SOAP::Serializer::envelope):
      >
      > my ($encoded) = $self->encode_object(
      > SOAP::Data->name('~V:Envelope' => \SOAP::Data->value(
      > SOAP::Data->name('~V:Header' => \$header),
      > SOAP::Data->name('~V:Body' => \$body)
      > ))->attr($self->attr)
      > );
      >
      > became
      >
      > my $encoded;
      > if (0) {
      > ($encoded) = $self->encode_object(
      > SOAP::Data->name('~V:Envelope' => \SOAP::Data->value(
      > SOAP::Data->name('~V:Header' => \$header),
      > SOAP::Data->name('~V:Body' => \$body)
      > ))->attr($self->attr)
      > );
      > } else {
      > ($encoded) = (['~V:Envelope',
      > $self->attr,
      > [ [ '~V:Header',{}, [
      > $self->encode_object($header) ],
      > 0 ],
      > [ '~V:Body', {}, [ $self->encode_object($body)
      > ], 0
      > ]
      > ],
      > 0]);
      > }
      >
      > To unsubscribe from this group, send an email to:
      > soaplite-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      >
      >


      __________________________________________________
      Do You Yahoo!?
      Yahoo! Auctions - buy the things you want at great prices
      http://auctions.yahoo.com/
    • Douglas Bonar
      ... Yeah, 0.47 is the latest one installed here. I didn t realize there was a later version. I guess it s time to hit CPAN. ... I like the idea. In fact, I
      Message 2 of 3 , Apr 30, 2001
      • 0 Attachment
        Paul Kulchenko wrote:
        >
        > Hi, Douglas!
        >
        > Right observation and interesting solution. Seems like you took
        > version prior 0.50, but idea is fully applicable to the current
        > version also. Thanks a lot.

        Yeah, 0.47 is the latest one installed here. I didn't realize
        there was a later version. I guess it's time to hit CPAN.


        >
        > I plan to address performance issues and even think about
        > implementing option for parsing/creating messages with known
        > structure with regexpes, without parsing/creating XML from scratch
        > every time. For example you have a service that returns temperature.
        > Why should you create the SAME message every time if only one value
        > is different? Generate is once, save as a template and then update
        > template with new value. I see the benefits, but it's not for all
        > situations. The same thing is true about parsing. From the same
        > client you are getting similar requests. Teach your implementation
        > once and then parse it with regexpes instead of XML parsing. If
        > template match something in your library, use it. If not, do it usual
        > way and store result in the library. If done in the right way, should
        > be transparent for server side, but quite benefitial (at least seems
        > to be). I'll do some tests later this week. Thoughts?
        >
        > Best wishes, Paul.

        I like the idea. In fact, I thought about adding something
        like that to my simple module, but not for long because it wouldn't
        have made a good comparison. And it wouldn't have been worth putting
        in a throwaway module anyway. It would be especially nice if
        you could indicate (I don't know how) that a particular function
        being dispatched through SOAP-Lite had a fixed argument list and
        return structure. Then, potentially at least, the memorizing could
        be done for the function calls as well as cases where you construct
        your own message.

        Good luck,
        Doug


        >
        > --- Douglas Bonar <Doug.Bonar@...> wrote:
        > > Some use around here indicated that using SOAP-Lite just
        > > as a way to construct SOAP messages for a non-Perl server
        > > is slow. (This is cases where we have explicit message
        > > templates we want to construct, rather than taking advantage
        > > of SOAP-Lite's strength at automarshalling the arguments
        > > and return values from Perl functions.) Looking at some
        > > DProf results, it appeared that one of the main reasons
        > > is that SOAP-Lite spends a fair chunk of time in parsing
        > > some boilerplate Envelope/Header/Body parts of the message
        > > structure.
        > >
        > > As a test example, I built a simple soap message three
        > > different ways.
        > >
        > > The first way (labeled 'mine' below) was with a module I wrote
        > > for the purpose. Basically it lets you specify your elements,
        > > their values and attributes and their relationships. It then
        > > translates that into XML and wraps it in a simple Envelope/Header/
        > > Body construct. There is nothing automagic in the module. It is
        > > only one step above putting the messages in here documents, but
        > > is fairly fast.
        > >
        > > The second way ('freeform') was to use the above module to
        > > build the body of the message and then passing that to SOAP-Lite
        > > asking it to make a freeform message (of type 'xml') out of
        > > that string. That way SOAP-Lite isn't doing any parsing of
        > > my data, only its own.
        > >
        > > The final way was to build my data with SOAP::Data elements.
        > > This is the way I would prefer to construct the messages. In
        > > the resulting code, it looks about the same as using the special
        > > purpose test module. Internally though this is more likely
        > > to do the right thing is special cases.
        > >
        > >
        > > 5 methods, 100 message builds of a fairly simple message.
        > > The system time was about the same for all cases. There is
        > > no transport or message parsing going on.
        > >
        > > Method User Time Relative Comments encode_object
        > > ========================================================
        > > mine 1.91 sec 100% reference 0/mes.
        > >
        > > freeform 4.64 sec 243% 10/mes.
        > > method 5.65 sec 296% 14/mes.
        > >
        > > freeform' 3.30 sec 173% 29% savings 3/mes.
        > > method' 4.38 sec 229% 22% savings 7/mes.
        > >
        > >
        > > The 'correct' way is almost 3 times slower than the special
        > > purpose building. And the number of calls to the
        > > SOAP::Serializer::encode_object method per message created
        > > is quite high. In fact, even if I provde the XML string with
        > > all the real content there are still 10 calls to encode_object.
        > >
        > > Looking at SOAP::Serializer::envelope, it was clear that the
        > > many of the calls are there because of the method builds the
        > > message internally by calls to encode_object. The structure
        > > of those calls is the same every time though, it is just
        > > boilerplate.
        > > "Unrolling" that code (see below) gave the primed results in
        > > the table above. 20% savings on a small message (obviously
        > > proportionally less on a large message). Given that many
        > > SOAP messages probably are small, that's not too bad.
        > >
        > > I think the change doesn't interfer with anything else in
        > > the module. The results from my test cases are identical
        > > message with either the old or new code.
        > >
        > > Doug
        > >
        > >
        > >
        > > The change (in SOAP::Serializer::envelope):
        > >
        > > my ($encoded) = $self->encode_object(
        > > SOAP::Data->name('~V:Envelope' => \SOAP::Data->value(
        > > SOAP::Data->name('~V:Header' => \$header),
        > > SOAP::Data->name('~V:Body' => \$body)
        > > ))->attr($self->attr)
        > > );
        > >
        > > became
        > >
        > > my $encoded;
        > > if (0) {
        > > ($encoded) = $self->encode_object(
        > > SOAP::Data->name('~V:Envelope' => \SOAP::Data->value(
        > > SOAP::Data->name('~V:Header' => \$header),
        > > SOAP::Data->name('~V:Body' => \$body)
        > > ))->attr($self->attr)
        > > );
        > > } else {
        > > ($encoded) = (['~V:Envelope',
        > > $self->attr,
        > > [ [ '~V:Header',{}, [
        > > $self->encode_object($header) ],
        > > 0 ],
        > > [ '~V:Body', {}, [ $self->encode_object($body)
        > > ], 0
        > > ]
        > > ],
        > > 0]);
        > > }
        > >
        > > To unsubscribe from this group, send an email to:
        > > soaplite-unsubscribe@yahoogroups.com
        > >
        > >
        > >
        > > Your use of Yahoo! Groups is subject to
        > > http://docs.yahoo.com/info/terms/
        > >
        > >
        >
        > __________________________________________________
        > Do You Yahoo!?
        > Yahoo! Auctions - buy the things you want at great prices
        > http://auctions.yahoo.com/
        >
        > To unsubscribe from this group, send an email to:
        > soaplite-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      Your message has been successfully submitted and would be delivered to recipients shortly.