You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Paul Fremantle <pz...@gmail.com> on 2008/06/25 16:43:26 UTC
Improving performance even more :)
The recent performance testing we did on the WSO2 ESB applies exactly
to Synapse (http://wso2.org/library/3740), and looking at those
figures, it would be nice to improve the routing performance when
there is no CBR or XSLT.
The one thing that might do this would be to bypass Axiom/Stax
processing altogether in this scenario. The way that I think we could
do this is to ask Axiom directly for the bytestream and have Axiom
decide if it is has been modified. If it has, then the normal
behaviour happens, but if the bytestream hasn't been touched at the
Axiom level, then we can pull the bytestream directly. I think this is
similar to the way other people have coded OMBacked classes such as
the OMDataSource. I'm afraid I've never fully understood the Axiom
model for doing this, so we would need a bit of Axiom expertise, but I
believe its fully possible. In fact, there is similar to Senaka's
proposal to directly back an OM element from a Map object and avoid
processing if the Map is unmodified.
WDYT?
Paul
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Improving performance even more :)
Posted by Andreas Veithen <an...@skynet.be>.
I'll also give my thoughts:
(1) Some transports can easily reproduce the original message. This is
the case for VFS, JMS, Mail and UDP. We should leverage this by
letting them put a DataHandler or DataSource object into the
MessageContext so that the original content can be retrieved later.
(Actually we should also define an extended message builder interface
that allows the transport to pass the DataHandler/DataSource to the
message builder. This would allow to optimize BinaryBuilder.)
(2) For transports such as HTTP that can't reproduce the original
message easily, we can wrap the InputStream provided to the message
builder in such a way that all data read from it is also copied to a
buffer.
(3) We need a way to detect whether the message has been modified or
not. Since AXIOM is entirely defined by interfaces, we can create
proxies to intercept calls to methods in SOAPEnvelope, SOAPHeader,
etc. These proxies need to be instantiated recursively, e.g. when
getHeader is called on the proxy for SOAPEnvelope, it should create a
proxy for SOAPHeader, etc. Obviously we can't do that for the entire
SAOP infoset as this would more or less double the number of Java
objects created for each message. So we should stop creating proxies
when the body of the message is accessed.
(4) We need to identify the methods in SOAPEnvelope, SOAPHeader, etc.
that don't modify (and don't allow the caller to modify) the SOAP
infoset and implement the proxies in such a way that whenever an
"unsafe" method is called, the message is marked as "tainted". When
this happens, we should also stop creating proxies and also stop
copying the original message data into the buffer (see point 2).
(5) The transport senders or message builders (to be decided) can then
check whether the message is tainted or not and send out the original
message if appropriate. At this point we can do further optimization
if we allow the sender to read the original data destructively as
suggested in SYNAPSE-357. If this is enabled we can do streaming at
the byte stream level (instead of the StAX level).
This looks quite complicated (especially point 3), but I think this
level of sophistication is required to have a solution that is
transparent to Axis2 and Synapse while still supporting optimization
even if the SOAP headers are read.
Andreas
On 27 juin 08, at 10:03, Ruwan Linton wrote:
> Hi Indika,
>
> Please see my comments inline;
>
> On Fri, Jun 27, 2008 at 1:13 PM, indika kumara
> <in...@gmail.com> wrote:
> Hi All
>
> Some thought...
>
> Currently message building and serializing is in transport layer.
> According to the content type ,message is being built and we cannot
> control the building process. For example , if the content type is
> corresponding to the SOAP , then SOAP message is built and we cannot
> avoid it.
>
>
> No we can, just need to override the builder in the axis2.xml
> associated with the content type and in there depending on a
> parameter in the axis2.xml we can decide whether to build this
> message with what ever the builder. May be this parameter can go
> into the synapse.xml but not sure about the technical challenges of
> the implementation, so lets keep that decision to the implementation
> phase.
>
> This is fine only if we use or access SOAP message. But if we can
> dispatch to synapse,proxyservices,etc without touching SOAP message
>
>
> Well, with axis2 this is a little hard because you might need a SOAP
> info-set to come out passing the handler chain.
>
> and if we will not touch the SOAP message within synapse, then , we
> should not want a SOAP message. But , currently , we have not that
> control .
>
>
> I think we can get the control at the MessageBuilder level.
>
>
> If we can provide a option to transport to specify whether to build
> a message or not (build and set as SOAP envelope ) and also if can
> provide a way in synapse language to specify whether to build a
> message or not(Build mediator which builds message and sets as SOAP
> envelope – default behavior may use content-type, but we have to
> have options to override it.).
>
>
> This is exactly what I meant.
>
> One other possibility is , with in transport layer , the message
> always set as stream or OMDatasource (use BinaryBuilder )
> irrespective of content type and whenever try to access message on
> the first time (messagecontext.getSOAPEnvelope()) and if SOAP
> envelope has not been built yet, then builds it and sets as Envelope.
>
>
> Again this is hard to implement, because even if you use
> OMDataSource you will have to have a SOAPEnvelope and this
> OMDataSource will be attached as the DataHandler for the payload
> (most probably the payload will be a Text node with the DataSource
> as the DataHandler) in which case there is no distinction between a
> binary message like hessian messages and a SOAP message and will
> lead to conflicts on building the message. Otherwise the builder has
> to aware of each and every content-type and it has to embed the
> logic on how to proceed with these content types, which will affect
> the extensibility of the message formats supported by synapse.
>
> This will be completely avoid building message as a SOAP envelope ,
> if we have not any interest in it.
>
>
> I think there should be a parameter to specify whether to build the
> message or not, synapse should not be intelligent enough to take
> that decision.
>
>
>
> For serialization part , we can do the same thing.
>
> I don't know this is a good suggestion , but I believe , for
> scenarios, that we don't access SOPA message, we have to completely
> avoid building it.
>
>
> Completely agreed and +1 for this.
>
> Thanks,
> Ruwan
>
>
> Thanks
> Indika
>
>
>
>
> --
> Ruwan Linton
> http://wso2.org - "Oxygenating the Web Services Platform"
> http://ruwansblog.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Improving performance even more :)
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Indika,
Please see my comments inline;
On Fri, Jun 27, 2008 at 1:13 PM, indika kumara <in...@gmail.com>
wrote:
> Hi All
>
> Some thought...
>
> Currently message building and serializing is in transport layer. According
> to the content type ,message is being built and we cannot control the
> building process. For example , if the content type is corresponding to the
> SOAP , then SOAP message is built and we cannot avoid it.
>
No we can, just need to override the builder in the axis2.xml associated
with the content type and in there depending on a parameter in the axis2.xml
we can decide whether to build this message with what ever the builder. May
be this parameter can go into the synapse.xml but not sure about the
technical challenges of the implementation, so lets keep that decision to
the implementation phase.
> This is fine only if we use or access SOAP message. But if we can dispatch
> to synapse,proxyservices,etc without touching SOAP message
>
Well, with axis2 this is a little hard because you might need a SOAP
info-set to come out passing the handler chain.
> and if we will not touch the SOAP message within synapse, then , we should
> not want a SOAP message. But , currently , we have not that control .
>
I think we can get the control at the MessageBuilder level.
>
> If we can provide a option to transport to specify whether to build a
> message or not (build and set as SOAP envelope ) and also if can provide a
> way in synapse language to specify whether to build a message or not(Build
> mediator which builds message and sets as SOAP envelope – default behavior
> may use content-type, but we have to have options to override it.).
>
This is exactly what I meant.
> One other possibility is , with in transport layer , the message always set
> as stream or OMDatasource (use BinaryBuilder ) irrespective of content type
> and whenever try to access message on the first time
> (messagecontext.getSOAPEnvelope()) and if SOAP envelope has not been built
> yet, then builds it and sets as Envelope.
>
Again this is hard to implement, because even if you use OMDataSource you
will have to have a SOAPEnvelope and this OMDataSource will be attached as
the DataHandler for the payload (most probably the payload will be a Text
node with the DataSource as the DataHandler) in which case there is no
distinction between a binary message like hessian messages and a SOAP
message and will lead to conflicts on building the message. Otherwise the
builder has to aware of each and every content-type and it has to embed the
logic on how to proceed with these content types, which will affect the
extensibility of the message formats supported by synapse.
> This will be completely avoid building message as a SOAP envelope , if we
> have not any interest in it.
>
I think there should be a parameter to specify whether to build the message
or not, synapse should not be intelligent enough to take that decision.
>
> For serialization part , we can do the same thing.
>
> I don't know this is a good suggestion , but I believe , for scenarios,
> that we don't access SOPA message, we have to completely avoid building it.
>
Completely agreed and +1 for this.
Thanks,
Ruwan
>
> Thanks
> Indika
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
Re: Improving performance even more :)
Posted by indika kumara <in...@gmail.com>.
Hi All
Some thought...
Currently message building and serializing is in transport layer. According
to the content type ,message is being built and we cannot control the
building process. For example , if the content type is corresponding to the
SOAP , then SOAP message is built and we cannot avoid it. This is fine only
if we use or access SOAP message. But if we can dispatch to
synapse,proxyservices,etc without touching SOAP message and if we will not
touch the SOAP message within synapse, then , we should not want a SOAP
message. But , currently , we have not that control .
If we can provide a option to transport to specify whether to build a
message or not (build and set as SOAP envelope ) and also if can provide a
way in synapse language to specify whether to build a message or not(Build
mediator which builds message and sets as SOAP envelope – default behavior
may use content-type, but we have to have options to override it.). One
other possibility is , with in transport layer , the message always set as
stream or OMDatasource (use BinaryBuilder ) irrespective of content type and
whenever try to access message on the first time
(messagecontext.getSOAPEnvelope()) and if SOAP envelope has not been built
yet, then builds it and sets as Envelope. This will be completely avoid
building message as a SOAP envelope , if we have not any interest in it.
For serialization part , we can do the same thing.
I don't know this is a good suggestion , but I believe , for scenarios, that
we don't access SOPA message, we have to completely avoid building it.
Thanks
Indika
Re: Improving performance even more :)
Posted by Ruwan Linton <ru...@gmail.com>.
On Thu, Jun 26, 2008 at 8:11 PM, Paul Fremantle <pz...@gmail.com> wrote:
> > Cool, I think this would be interesting. So we need a mechanism to find
> > whether the AXIOM tree is modified or not when we send the message out.
>
> Ok so we can do this I guess by looking to see if the root has been
> built at all. If it hasn't been built then the message is still
> untouched. That would only work for pure routing or content-based
> routing using only HTTP headers.
>
> > I think this is possible, but I don't think we need an OMDataSource to do
> > this, we can get the stream from the parser directly right? in which case
> we
> > just need to override the MessageFormatter ....
>
> Cool.
>
>
> > I am sorry I don't get this point...
>
> We were talking earlier about using OMDataSource to create an
> OMElement "backed" by a Map message. That way, if the Map message is
> unmodified, then the Map can be accessed directly without having to
> ever transform it into XML. For example, we could use this with FIX -
> since FIX is basically a map of name-value pairs, we could create a
> MapMessage, and only create XML if we needed to.
Hhhhmmmm, sounds interesting.
Any ideas from others?
Thanks,
Ruwan
>
>
> Paul
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
Re: Improving performance even more :)
Posted by Paul Fremantle <pz...@gmail.com>.
> Cool, I think this would be interesting. So we need a mechanism to find
> whether the AXIOM tree is modified or not when we send the message out.
Ok so we can do this I guess by looking to see if the root has been
built at all. If it hasn't been built then the message is still
untouched. That would only work for pure routing or content-based
routing using only HTTP headers.
> I think this is possible, but I don't think we need an OMDataSource to do
> this, we can get the stream from the parser directly right? in which case we
> just need to override the MessageFormatter ....
Cool.
> I am sorry I don't get this point...
We were talking earlier about using OMDataSource to create an
OMElement "backed" by a Map message. That way, if the Map message is
unmodified, then the Map can be accessed directly without having to
ever transform it into XML. For example, we could use this with FIX -
since FIX is basically a map of name-value pairs, we could create a
MapMessage, and only create XML if we needed to.
Paul
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Improving performance even more :)
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Paul,
On Wed, Jun 25, 2008 at 8:13 PM, Paul Fremantle <pz...@gmail.com> wrote:
> The recent performance testing we did on the WSO2 ESB applies exactly
> to Synapse (http://wso2.org/library/3740), and looking at those
> figures, it would be nice to improve the routing performance when
> there is no CBR or XSLT.
Of course yes.
>
>
> The one thing that might do this would be to bypass Axiom/Stax
> processing altogether in this scenario. The way that I think we could
> do this is to ask Axiom directly for the bytestream and have Axiom
> decide if it is has been modified. If it has, then the normal
> behaviour happens, but if the bytestream hasn't been touched at the
> Axiom level, then we can pull the bytestream directly. I think this is
> similar to the way other people have coded OMBacked classes such as
> the OMDataSource.
Cool, I think this would be interesting. So we need a mechanism to find
whether the AXIOM tree is modified or not when we send the message out.
> I'm afraid I've never fully understood the Axiom
> model for doing this, so we would need a bit of Axiom expertise, but I
> believe its fully possible.
I think this is possible, but I don't think we need an OMDataSource to do
this, we can get the stream from the parser directly right? in which case we
just need to override the MessageFormatter ....
> In fact, there is similar to Senaka's
> proposal to directly back an OM element from a Map object and avoid
> processing if the Map is unmodified.
I am sorry I don't get this point...
Thanks,
Ruwan
>
>
> WDYT?
>
> Paul
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/