[Oslc-pm] OSLC-PM and Web Applications
John Arwe
johnarwe at us.ibm.com
Tue Jan 8 12:01:45 EST 2013
I see nothing in the archives to suggest this was ever responded to. Was
it handled on a call?
The Avg/Min/Max/StdDev pattern being repeated makes me wonder out loud if
this is in reality some form of qualification of the value. Perf Mon to
date I don't think considered that to be in scope. It is easy enough to
do via extensions, or you can convince (try to) the WG to either
add/modify in-scope scenarios to require these.
"hits" semantics are unclear to me, so cannot comment on whether they are
new/map to existing.
Any questions around CRTV needs to be answered by the owners of that
vocabulary, the Reconciliation working group [1]. Perf Mon uses that only
as an example of how one could "attach" metrics to types already defined
elsewhere.
[1] http://open-services.net/wiki/reconciliation/
Best Regards, John
Voice US 845-435-9470 BluePages
Tivoli OSLC Lead - Show me the Scenario
"Oslc-Pm" <oslc-pm-bounces at open-services.net> wrote on 12/11/2012 01:26:55
PM:
> From: Boris Kuschel <kuschel at ca.ibm.com>
> To: oslc-pm at open-services.net
> Date: 12/11/2012 01:27 PM
> Subject: Re: [Oslc-pm] OSLC-PM and Web Applicaitions
> Sent by: "Oslc-Pm" <oslc-pm-bounces at open-services.net>
>
> I am currently using the EMS, CRTV and PERFMON specs but I have
> identified the following caps especially around the web application
area.
>
> *= new
>
> RequestMetrics
> -> AvgResponseTime*
> -> MaxResponseTime*
> -> MinResponseTime*
> -> StandardDeviation*
> -> AvgPayloadSize*
> -> MaxPayloadSize*
> -> MinPayloadSize*
> -> AvgRequestFailures
> -> Hits*
> -> CpuUsed
>
> RequestFailures
> -> AvgResponseTime*
> -> MaxResponseTime*
> -> MinResponseTime*
> -> StandardDeviation*
> -> Hits*
> -> CpuUsed
>
> There is a need for a light weight service (J2EE, OSGi). I have seen
> the CRTV ServiceInstance predicate but the documentation seems to
> indicate that this a customer related servicing offering.
>
> ServiceMetrics*
> ->AvgResponseTime*
> -> MaxResponseTime*
> -> MinResponseTime*
> -> StandardDeviation*
> -> AvgRequestFailures*
> -> Hits*
> -> CpuUsed
> -> parent (count be request or service, crtv?)*
>
> SQLStatementMetrics*
> -> AvgResponseTime*
> -> MaxResponseTime*
> -> MinResponseTime*
> -> StandardDeviation*
> -> parent (count be request or service, crtv?)*
>
> Is it small enough? I have other data that deals more with
> performance of active instances of services and requests as well but
> including the above would be a great first step.
>
> Boris Kuschel
> Software Architect
> Smarter Server - IBM Software, Rational
> Phone: +1-514-964-1290
> Email: kuschel at ca.ibm.com
> My Blog: http://blog.boriskuschel.com/
>
> [image removed] John Arwe ---12/07/2012 01:20:55 PM---This use
> certainly sounds compatible on the surface. With respect to specific
> metrics, I don't know
>
> From: John Arwe <johnarwe at us.ibm.com>
> To: oslc-pm at open-services.net,
> Date: 12/07/2012 01:20 PM
> Subject: Re: [Oslc-pm] OSLC-PM and Web Applicaitions
> Sent by: "Oslc-Pm" <oslc-pm-bounces at open-services.net>
>
>
>
> This use certainly sounds compatible on the surface.
> With respect to specific metrics, I don't know of any specific
> scenarios in-scope for this spec version. Have you done a gap
> analysis, e.g. tried to lay out that data using the current draft to
> see what does not fit obviously? If the gap is considered "small
> enough", the WG might conceivably elect to add scenario(s) in this
> version and cover them. If it's not, there's always the next spec
> version as a catcher for the scenarios, assuming they get
> prioritized highly enough by the WG.
> It might be that terms from other vocabularies are needed (you might
> look at CRTV under the Reconciliation WG), but that's standard
> procedure not an impediment of any kind.
> Best Regards, John
>
> Voice US 845-435-9470 BluePages
> Tivoli OSLC Lead - Show me the Scenario
>
>
>
>
> From: Boris Kuschel <kuschel at ca.ibm.com>
> To: oslc-pm at open-services.net
> Date: 11/30/2012 04:18 PM
> Subject: [Oslc-pm] OSLC-PM and Web Applicaitions
> Sent by: "Oslc-Pm" <oslc-pm-bounces at open-services.net>
>
>
>
> HI,
>
> We are intending to using the OSLC-PM (and associated specs) to
> provide performance data for a OSGi-based web application (the same
> concepts apply to J2EE). I notice that there is a lot of metrics
> relating to OS, a few about JVM (more around the specifics of the GC
> would be nice, nursery, perm space,etc.) but there is general lack
> of metric details regarding web requests. There are a few tempting
> predicates (Process, ServiceInstance) that almost hit the mark but not
quite.
>
> Consider the following scenario: I have a system running a web
> application for which I wish to understand health status. There is a
> general slow down in the system and I expect to be able to
> understand where the slowdown is occurring. I would like to be able
> to pull down metrics information and see the following:
>
> Active/Most consuming requests (or some amount):
> ->User Session, user, age, language, agent
> -->HTTP Request: type, time spent, cpu cycles consumed, bytes sent,
> bytes received
> ---> Service Invoked: time spent, cpu cycles consumed
> -----> Activities (SQL, triple store, external service, etc.):
> description, time spent, cpu cycles consumed
> ------> Services Invoked... etc.
>
> Is there consideration to make this information as part of the OSLC-
> PM vocabulary?
>
> Thanks,
>
> Boris Kuschel
> Software Architect
> Smarter Server - IBM Software, Rational
> _______________________________________________
> Oslc-Pm mailing list
> Oslc-Pm at open-services.net
> http://open-services.net/mailman/listinfo/oslc-pm_open-services.net
> _______________________________________________
> Oslc-Pm mailing list
> Oslc-Pm at open-services.net
> http://open-services.net/mailman/listinfo/oslc-pm_open-services.net
> _______________________________________________
> Oslc-Pm mailing list
> Oslc-Pm at open-services.net
> http://open-services.net/mailman/listinfo/oslc-pm_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-pm_open-services.net/attachments/20130108/0670d1e8/attachment-0003.html>
More information about the Oslc-Pm
mailing list