Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VegasLimit for batch processing #159

Open
ericzhifengchen opened this issue Jul 4, 2020 · 0 comments
Open

VegasLimit for batch processing #159

ericzhifengchen opened this issue Jul 4, 2020 · 0 comments

Comments

@ericzhifengchen
Copy link

ericzhifengchen commented Jul 4, 2020

One limitation of current VegasLimit is it doesn't work well with batch processing system.

Different from a real-time processing system, a batch processing system has a buffer, requests first put into buffer, and being processed in batch. Definition of rtt is time elapsed between request put into buffer and request being processed.

The problem of VegasLimit is, rtt > rtt_noload indicates queue is building up. however in batch processing system, it's not true. For example, there is a virtual cargo shipping system, at terminal, shipping containers are being shipped at fixed interval. (for convenience, shipping container has unlimited capacity.) Packages arrived at the terminal will be shipped by next pending send shipping container.

In this model, a package arrived at terminal just before next shipping event should have smallest rtt aka rtt_noload, then right after container shipped, next arrived package should have largest rtt (rtt_noload + interval). current VegasLimit could incorrect treat this system as saturated, because of interval, rtt could be significantly larger than noload_rtt. however, this virtual shipping system is not saturated at all.

Kafka message producing is a concrete example of batch processing, Our goal is to use VegasLimit to detect saturation of message producing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant