RateLimiter blocks threads regardless of allowed message rate about secor HOT 9 CLOSED

How much does the synchronization delay the processing given relatively high cost of message parsing, disk IO, etc?

My concern about per-thread rate limiting is that it relies on even distribution of the load across threads which I don't think is a fair assumption. Ideally, it would be nice to have throttling at even higher level than process (e.g., a broker) but it's rather complicated to implement.

from secor.

How much does the synchronization delay the processing given relatively high cost of message parsing, disk IO, etc?

I would say it depends on number of threads and message rate among other things. According to my observation in a single secor process with 10 threads this particular lock was eating up as much as 70% of total execution time.

My concern about per-thread rate limiting is that it relies on even distribution of the load across threads which I don't think is a fair assumption. Ideally, it would be nice to have throttling at even higher level than process (e.g., a broker) but it's rather complicated to implement.

I agree. How about offering a thread-based limiting as an alternative to existing? Until a better solution comes up at least.

from secor.

I have to say that I'm shocked with this result. If it's indeed the case that most of the time is spent waiting for the lock, we should indeed consider alternatives such as per-thread locking or not locking at all if secor.messages.per.second is set to a negative value.

from secor.

I started implementing a NoRateLimiter that extended the RateLimiter class, but for some reason I couldn't really get it to work, probably due to my java-fu being a bit low nowadays. I'm gonna give it another go this weekend if anyone (besides me) is still interested in this. I also saw a lot of time being consumed by the rate limiting lock.

from secor.

I may be totally wrong but I still find it a bit hard to believe that locking in the rate limiter will have such a tremendous impact on the performance. Could the NoRateLimiter be 'implemented' simply by setting secor.messages.per.second to a ridiculously high value?

from secor.

Dunno. It was quite some weeks ago when I did performance tests, but I'll probably redo them this coming week without my previous changes, I'll report back the results.

from secor.

I ran a tiny bit of profiling last week and the rate limiting functionality didn't score high at all (though I'm fairly sure I've seen it hit higher numbers before..). The numbers were well below the time that is spent reloading the configuration file from disk, which tends to happen a lot, so I don't think the rate limiting is an issue (we set it waaaay high as we don't really want any rate limiting). Should mention that we're only running 2 threads per process, so it'll probably be different when running with ten threads.

from secor.

So from the benchmark tests I ran, the rate limiting was a big gating factor..I was able to circumvent it just by putting it to some really high number though. Didn't have to turn it off (both had almost the same effect).

from secor.

Thanks @mthssdrbrg for sharing findings from your test run.

@lefthandmagic it is expected that rate limiting will make your application slower while you are hitting the rate limit :-)

from secor.