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

SOAP::Serializer::envelope

Expand Messages
  • Douglas Bonar
    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
    Message 1 of 3 , Apr 30, 2001
    • 0 Attachment
      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]);
      }
    • 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 2 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 3 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.