You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: