StatsD protocol allows multiple metrics in a single datagram, as long as they are separated by \n. This is known as "buffering" in Datadog dogstatsd. Filtering logic now supports this by tokenizing the string up front, and filter out each metric independently.

https://github.com/askldjd/statsd-filter-proxy-rs/blob/6ba64dabc280b3e483a93f29df93688945b7f8fc/src/filter.rs#L4

If &buf isn't valid UTF-8, this results in undefined behaviour. Since filter is not marked as unsafe, it is currently possible to cause undefined behaviour by calling a safe function.

As far as I can tell, this buffer comes from a socket from outside the application, so it is in my opinion a better idea to use the safe str::from_utf8 with proper error handling instead.

This depends on #11 I guess (the PR branch is based on the PR branch from #11)

Please review carefully and also see the commit message of the last commit for a rationale.

Hi Alan,

I came over your blog post on optimizing away 700 CPUs with rust, it's a really good read and was fascinating to see since our team at Wayfair ran into exactly the same issue and came up with nearly the same solution :D.

I went through the benchmarks today and noticed you're selling yourself short, the node.js version did only half the logic that the rust version did (it ignored newlines) I twiddled something together to make them more the same on the logical front.

I also changed the benchmark script to emit some filtered metrics (to see the impact on that), I hope you approve of that change.

With the updated results I ran your benchmark through tremor and notices something interesting, your code is quicker for single-core use but not quite as fast when it comes to multi-core setups. (I'll put my local benchmark below ran with taskset -c 1 and taskset -c 1,2,3 for single and 3c respectively).

We donated tremor to the CNCF last year, so I'm curious if you're open to chatting, sharing some experiences, and possibly expanding the use case - neither your nor our employer is in the game of writing this kind of software as part of their core business so we're probably both very produced focused which seems to align well :). If you're interested I'll leave you a link to our community server.

| | nodejs | nodejs (3c) | rust_pxy | rust_pxy (3c) | tremor | tremor (3c) | |------------|--------|-------------|----------|---------------|--------|-------------| | Median(us) | 110 | 153 | 78 | 137 | 97 | 94 | | P95(us) | 125 | 183 | 103 | 150 | 112 | 137 |

PS: we found a bug in our stated decoder when trying this :D thank you!

I came here after reading the post of medium - https://medium.com/tenable-techblog/optimizing-700-cpus-away-with-rust-dc7a000dbdb2

Although I don't think JS is going beat Rust but I have few suggestions to improve the performance characteristics of the code.

1. Use latest version of NodeJS
2. extract error handling function outside which is registered to "client.send" method
3. Run >> node --expose-gc --inspect statsd-filter-proxy.js
4. The most import step is to do little experiment with socket.setRecvBufferSize(size) and socket.setSendBufferSize(size) can give you optimum size of buffer which can help in reducing the GC pressure on heap.
5. Consider receiving, storing and sending packets in batch rather than one by one
6. Explicitly set the heap size >> node --max-old-space-size=10240 statsd-filter-proxy.js. here the number for 10240 is just an example, not a concrete suggestion. First 5 steps will help you to come to actual number. Similarily set the value of min_semi_space_size, max_semi_space_size. more info here, https://deepu.tech/memory-management-in-v8/
7. use "taskset" linux command to pin nodejs process to particular CPU core instead of all the cores which the default, this ensures maximum yield

There are a few potential performance wins you can explore here I think.

1. Use a trie rather than a linear scan for the prefix matching.
2. You could allocate less in filter. For example, by directly building a Vec<u8> instead of a String. Currently there are two allocations, a Vec<&str> and String. With that approach you'd only have one and you could potentially allocate with too much capacity to prevent resizing the Vec.

EDIT: With the signature pub fn filter(block_list: &Vec<String>, buf: &mut [u8]) -> &mut [u8] and some index fiddlig you could probably entirely avoid allocations in filter.