Without the garbage collection this still is not realistic but helps in being able to judge the impact of certain choices which is what I have been doing a lot of over the last couple of days.
What performance benchmark do you think needs to be met in order for the system as a whole to work? Since you have excluded the time-out code for the moment and we've tweaked a number of issues, there isn't a whole lot of "meat" left on these bones!
I don't see any super easy miraculous 10x (order of magnitude) solution. Even writing this thing in C is maybe just another 2-3x. From "reading between the lines", it sounds like you would like to do even more processing than the code that we've been benchmarking?
Backing up a bit about the requirements... how does the output from your hundreds of servers
come to be merged into a single pipe? Is there some way to distribute the load further
"upstream" into multiple "fire hoses" instead of just a single one?
Is it ok if Server123's data is on a separate machine from Server789's? It sounds to me
like a server process model is more appropriate than threads because this is sounding like
you will wind up needing multiple machines. That kind of approach can yield a 10x type of
performance increase and be scalable.
Of course of interest is what is driving your requirements to begin with? What is the "user end product" result? I mean so we have collected all the lines for a single node/time/event into a single line, so what? Why is that a requirement and why is that helpful? Maybe there is a way to do the processing of whatever "end result" you desire without this very high performance program? I don't know, but this is an obvious question.
Update: Another thought about your benchmark,
$ time cat audit.log|./auditd-linux-orig.pl >/dev/null
This running of cat and piping into auditd-linux-orig.pl and re-directing shell output could potentially have some performance impact. Out of curiosity, is there any difference if auditd-linux-orig.pl opens a file handle for read from audit.log and a file handle for write to /dev/null? Instead of using the shell re-direction? Of course there is also a small difference included in your benchmark for Perl to load and compile. I am currently using Windows and I'm not sure if any measurement that I made would be applicable to your system.
In reply to Re^3: Multi-CPU when reading STDIN and small tasks
by Marshall
in thread Multi-CPU when reading STDIN and small tasks
by bspencer
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |