-
Notifications
You must be signed in to change notification settings - Fork 10
v3.5 Concurrency Model
Usually Mongoose is used to measure the rates/timings with given concurrency limit value. By default Mongoose's concurrency is 1. But it may be very useful to allow Mongoose to work with unlimited (as high as possible) concurrency level (concurrent connections, open files). Unlimited here doesn't mean infinite, because there are OS limits and the internal number representation size limit (32-bit signed integer).
- Allow to disable the concurrency limit.
- Measure and report the actual concurrency level.
-
ulimit -n
system setting (usually set to 1024). The OS will not allow to use more simultaneous connections than count. Set that system setting value to higher value if a higher concurrency level is required. -
It's not possible to set
ulimit -n
value to more than 1048576 on the most Linux systems. So single process can't use higher count of the simultaneous connections even if theulimit -n
is set to maximum possible value (1048576). Use distributed mode if a higher concurrency level is required. -
32-bit signed integer limit. It's not possible to reach concurrency level more than 2,147,483,647. In practice, such high concurrency level is considered as unreachable and not useful for the performance measurement purposes (this will require also the distributed mode using at least 2048 separate storage drivers).
To disable the concurrency limit it's enough to set the corresponding configuration parameter to 0:
java -jar mongoose-<VER>/mongoose.jar --load-limit-concurrency=0
Also, it should be useful to limit the load rate:
java -jar mongoose-<VER>/mongoose.jar --load-limit-concurrency=0 --load-limit-rate=1000
The last example will show how many simultaneous clients/users/connections can handle the service/storage under the test.
TODO
Allows to avoid the thread blocking due to necessary synchronization.
Use Java's Lock.tryLock()
method to perform an effort to obtain the exclusive lock immediately.
Skip all the subsequent actions if this particular required lock is held by another thread.
The class OptLockArrayBuffer
is designed to support the optional locking.
Publishing the ArrayList.removeRange(from, to)
method allows to recycle the buffer after it
partially consumed w/o redundant instantiation. The interface OptLockBuffer
is designed to support the range removing method.
A service task is such Closeable
and Runnable
task which executes for some very short
time avoiding any blocks. It should be designed to be reentrant (similar to coroutines).
A service task may be run by the different threads at the different time so its fields should be
thread safe.
The service tasks are used by daemons. Daemons have shared/global service tasks registry which is implemented as a map where the particular daemon is a key and list of its service tasks is a value.
The common service tasks executors iterates the service tasks registry and executes the service tasks sequentially. As far as the service tasks executor is multithreaded the service tasks are executed concurrently also.
Used to get the completed I/O tasks from the selected storage driver and invoke the load monitor's processing method.
Designed to scatter the entities uniformly among the several wrapped outputs. Selects the output buffer on the put operation using round-robin approach. Performs the actual transfer from the buffers to the outputs. Supports batch put and transfer operations.
Uses the OptLockBuffer
- Get any pending child I/O tasks into the buffer if capacity is enough.
- Get any pending incoming I/O tasks into the buffer if capacity is enough.
- Try to submit as much as possible I/O tasks from the buffer.
- Leave the I/O tasks have not submitted in the buffer.
Uses the OptLockBuffer
The concurrent load generator. Recycles the shared OptLockBuffer
.
Service task performing the snapshots refreshing and periodic output.
- Overview
- Deployment
- User Guide
- Troubleshooting
- Reference