Re^2: Redirecting stdout/stderr to pipe

Okay, thanks for that! I would like however like to be enlightened more: ;)

1. I'd rather not use a solution using external modules, since the collector will have to run on MANY hosts as painlessly and non-intrusively as possible. Is there a high performance approach without external modules?
2. I am unsure as to how much data should be read from the pipe at a time in order to optimise throughput as much as possible...

-0xbeef

Comment on Re^2: Redirecting stdout/stderr to pipe

Replies are listed 'Best First'.
Re^3: Redirecting stdout/stderr to pipe by graff (Chancellor) on Sep 22, 2005 at 02:13 UTC
1. I'd rather not use a solution using external modules, since the collector will have to run on MANY hosts as painlessly and non-intrusively as possible. Is there a high performance approach without external modules? The modules cited in the code that Thelonius posted (IPC::Open3, IO::Select, Symbol) are not "external", in the sense that they are all included in the standard Perl "core" distribution. That is, wherever a reasonably current version of Perl is installed, these modules are also installed by default. (If these many hosts you speak of have non-standard or hopelessly outdated perl installations, that's going to be a problem anyway.) As for buffer size, the 1024 bytes suggested by Thelonius is fine for handling text that must ultimately be treated in a line-oriented fashion; if you're dealing with really high data rates, an 8k buffer should be about optimal.	[reply]

Replies are listed 'Best First'.

Re^3: Redirecting stdout/stderr to pipe
by graff (Chancellor) on Sep 22, 2005 at 02:13 UTC

1. I'd rather not use a solution using external modules, since the collector will have to run on MANY hosts as painlessly and non-intrusively as possible. Is there a high performance approach without external modules?

Thelonius

(If these many hosts you speak of have non-standard or hopelessly outdated perl installations, that's going to be a problem anyway.)

As for buffer size, the 1024 bytes suggested by Thelonius is fine for handling text that must ultimately be treated in a line-oriented fashion; if you're dealing with really high data rates, an 8k buffer should be about optimal.

[reply]