axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Afkham Azeez <afk...@gmail.com>
Subject Re: Framework for recording Axis2 latency statistics
Date Wed, 13 Jul 2011 13:24:40 GMT
On Wed, Jul 13, 2011 at 6:29 PM, Deepal Jayasinghe <deepalk@gmail.com>wrote:

> I partially agree with you for the out going path, but for the
> incoming path there is no streaming it just creates the Axiom object
> by pointing to input stream.
>
> Application server likes Tomcat handle this, I am not 100% sure how
> they do that, but it is useful to understand their approaches as well.
>

Tomcat has a RequestInfo object associated with each request, and calls a
statistics summarization method, after the response is created. This is tied
to the Tomcat request processor, and not part of the Connectors.



> If you really want to do with transport listeners then do it as a none
> abstract method, so that we will not break any existing user code.
>
>
+1


> Deepal
>
> On Wed, Jul 13, 2011 at 8:46 AM, Supun Kamburugamuva <supun06@gmail.com>
> wrote:
> > Actually doing this at the handler level is the easiest thing. But it
> > is not sufficient for a real production system where these parameters
> > are critical for figuring out the system performance.
> >
> > There are many things happen at the transports like streaming,
> > buffering etc. With a handler level implementation all these latencies
> > are lost. Also note that the initial SOAP building happens in the
> > transport as well. So by the time the handler is hit most of the bytes
> > are read in to the system. So calculating at the handler level doesn't
> > give a accurate number. We have done this at the transport level for
> > the synapse NHTTP transport and it served quite good for synapse so
> > far.
> >
> > Thanks,
> > Supun..
> >
> > On Wed, Jul 13, 2011 at 5:26 PM, Deepal jayasinghe <deepalk@gmail.com>
> wrote:
> >> I agree with Azeez, this has to be done with handler. I do not like the
> idea
> >> of keep changing the abstract transport listener (in fact I am -1 on
> that).
> >>
> >> This is a nice feature but you need to make sure that you do not break
> >> anything. So, implement this feature using handlers, we have done
> similar
> >> stuffs with handlers. And add your handler phasefirst of transport phase
> >> (in), and phaselast of transport out.
> >>
> >> Thanks,
> >> Deepal
> >>
> >> Why not introduce two handlers which will do this, and make those
> handlers
> >> sit right at the top of the in-flow, and right at the back of the
> outflow.
> >> That way, nothing has to be changed, and transports listeners/senders
> don't
> >> have to be changed, and you don't have to depend on the transport
> >> listener/sender authors to do the correct thing? Of course, there may be
> a
> >> very small microsecond range error since the execution times in the
> >> listeners/senders will not be included.
> >>
> >> On Wed, Jul 13, 2011 at 2:18 PM, Sadeep Jayasumana <
> gayansadeep@gmail.com>
> >> wrote:
> >>>
> >>> Hi,
> >>> On Wed, Jul 13, 2011 at 1:23 PM, Sagara Gunathunga
> >>> <sagara.gunathunga@gmail.com> wrote:
> >>>>
> >>>> +1
> >>>>
> >>>> Sadeep , I have few questions
> >>>>
> >>>> 1.) Is it possible to make your framework pluggable ? I mean users can
> >>>> enable and disable this feature.
> >>>
> >>> Yes, user can enable/disable this feature using axis2.xml
> >>>
> >>>>
> >>>> 2.) Can you explain bit of a implementation level details of your
> >>>> suggestion ? Whether you use Observer like pattern to collect those
> >>>> statistics ?
> >>>>
> >>>
> >>> Here is a summery of the implementation
> >>> 1. When axis2 server is starting up a LatencyRecorder (a newly
> introduced
> >>> class) instance is created and bound to the configuration context.
> >>> DeploymentLifeCycleListener is used for this purpose. LatencyRecorder
> >>> contains methods for transport listeners/senders to report message
> >>> arrival/departure.
> >>>
> >>> 2. A new method, getLatencyRecorder(), is introduced to
> >>> AbstractTransportListener and AbstractTransportSender classes, this
> method
> >>> basically returns the LatencyRecorder object bound to the configuration
> >>> context
> >>> 3. When a message is received, the corresponding transport listener
> >>> reports it to the above LatencyRecorder object with the message context
> and
> >>> message arrival time
> >>> 4. Message context properties are used to keep latency data related to
> >>> that message while it is inside Axis2 engine
> >>> 5. When a message is sent back to the client, the corresponding
> transport
> >>> sender reports it to the LatencyRecorder object with the message
> context and
> >>> message departure time
> >>> 6. A single threaded executor runs to average latency data reported and
> to
> >>> post them to the MBean
> >>> In addition to this basic flow, it is also possible to report times
> when
> >>> Axis2 server calls an external web service before sending response to
> it's
> >>> client (as done in Apache Syanpse).
> >>> Thanks,
> >>> Sadeep
> >>>
> >>>>
> >>>> Thanks !
> >>>>
> >>>> On Wed, Jul 13, 2011 at 11:32 AM, Sadeep Jayasumana
> >>>> <gayansadeep@gmail.com> wrote:
> >>>> > Hi Devs,
> >>>> > I'm planning to implement a framework for monitoring latency
> statistics
> >>>> > of
> >>>> > Axis2 server. The key purpose of this framework is to monitor
> average
> >>>> > time
> >>>> > messages spend inside Axis2 server. Here is the summery of my
> approach.
> >>>> > 1. Time t1 is recorded by the transport listener when a request
> message
> >>>> > is
> >>>> > received
> >>>> > 2. Time t2 is recorded by the transport sender when the response
> >>>> > message is
> >>>> > sent back to the client
> >>>> > 3. Latency is recorded as (t2 - t1)
> >>>> > 4. Average latencies are made available via JMX. Statistics will
be
> >>>> > available on short term basis(last 1 minute, last 5 minutes, etc.)
> and
> >>>> > long
> >>>> > term basis(last 1 hour, last 5 hours, etc).
> >>>> > To implement this, all the transport listeners and senders should
> >>>> > report
> >>>> > message arrival and departure to a central component that calculates
> >>>> > statistics and publishes them via JMX MBeans. Short term and long
> term
> >>>> > statistics will be available for in-transport name and out-transport
> >>>> > name
> >>>> > combinations. (statistics for http-in & http-out, statistics
for
> jms-in
> >>>> > &
> >>>> > jms-out, etc.)
> >>>> > Further, this framework will be extensible and able to record
> >>>> > meaningful
> >>>> > latencies when Axis2 is used in other projects such as Apache
> Synapse.
> >>>> > Any thoughts are welcome.
> >>>> > Thanks,
> >>>> > --
> >>>> > Sadeep Jayasumana
> >>>> > Software Engineer
> >>>> > WSO2 Inc.
> >>>> >
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Sagara Gunathunga
> >>>>
> >>>> Blog      - http://ssagara.blogspot.com
> >>>> Web      - http://people.apache.org/~sagara/
> >>>> LinkedIn - http://www.linkedin.com/in/ssagara
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >>>> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Sadeep
> >>
> >>
> >>
> >> --
> >> Afkham Azeez
> >> Director of Architecture; WSO2, Inc.; http://wso2.com,
> >> Member; Apache Software Foundation; http://www.apache.org/
> >>
> >> email: azeez@wso2.com cell: +94 77 3320919
> >> blog: http://blog.afkham.org
> >> twitter: http://twitter.com/afkham_azeez
> >> linked-in: http://lk.linkedin.com/in/afkhamazeez
> >>
> >> Lean . Enterprise . Middleware
> >>
> >>
> >>
> >
> >
> >
> > --
> > Supun Kamburugamuva
> > Technical Lead &  Product Manager, WSO2 Inc.; http://wso2.com
> > Member, Apache Software Foundation; http://www.apache.org
> > WSO2 Inc.;  http://wso2.org
> > E-mail: supun@wso2.com;  Mobile: +94 77 431 3585
> > Blog: http://supunk.blogspot.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> > For additional commands, e-mail: java-dev-help@axis.apache.org
> >
> >
>
>
>
> --
> http://blogs.deepal.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com,
*Member; Apache Software Foundation;
**http://www.apache.org/*<http://www.apache.org/>
*
*
*email: **azeez@wso2.com* <azeez@wso2.com>* cell: +94 77 3320919
blog: **http://blog.afkham.org* <http://blog.afkham.org>*
twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
*
*

Mime
View raw message