On Wed, 10 Jan 2001, Mark Goodwin wrote:
> On Tue, 9 Jan 2001, Alan Bailey wrote:
>
> > Thanks, but no thanks. I barely know java, so it wouldn't be much help.
> > I will try writing a tool with multiple processes.
>
> Beware, libpcp is not thread safe (static globals in assorted
> important places). However, multiple threads could easily
> fork/exec pminfo or pmprobe in parallel as an easy way of
> implementing non-blocking (aka asynchronous) fetch. In general,
> you'll get better latency with pmprobe compared to pminfo, and
> the output is designed to be easier to parse.
I see. I didn't know about pmprobe. That is much easier to parse. :)
However, I don't like that I would have to call it twice to get both the
instance names and the values, like:
pmprobe -I kernel.all.load ; pmprobe -v kernel.all.load
Thanks for the tip, I'm just ignorant.
>
> Regarding the original question - yes we invested a lot of
> effort making the PCP protocols efficient. We tuned the
> client<->pmcd IPC layers with sockopts such as TCP_NODELAY,
> and profiled and tuned the critical paths thru the libpcp call
> stack, eliminated unnecessary system calls, etc. We also used a
> a binary protocol - more compact and efficient cmp'd to ascii.
I figured as much. That's awesome. I basically wanted this information
to give to my coworker to say "yes, PCP is extremely fast, we're just
using it slowly"
Alan
>
> -- Mark
>
>
--
Alan Bailey
|