Speeding things up!

Request throttling

When not modified, the framework throttles its requests to 4 / second at max.
This way, the bot will not get banned due to flooding limitations.

This limit can be disabled or modified using the bot.connection.reqdelay JVM option.
(E.g. -Dbot.connection.reqdelay=0 would disable the limit)
The option value is interpreted as a floating point number in "parts of a second" (so, the default is 0.25


Beware of the flooding prevention

Before lowering the delay, make sure to add the framework to the query_ip_whitelist.txt of the TeamSpeak server!
The framework will be temporarily banned due to flooding limits otherwise!

Cache refresh intervals

By default, the client cache is refreshed every ~60 seconds while the channel cache is refreshed every ~180 seconds.
These refresh intervals are configurable using the jeak.cache.clientRefresh and jeak.cache.channelRefresh JVM options. They can be set similar to the option above:
-Djeak.cache.clientRefresh=20, -Djeak.cache.channelRefresh=60 would tell the cache to refresh the client list every 20 seconds and the channel list every 60 seconds. (Which means, the values are integers in seconds)


Do not set these intervals too low

Lowering these intervals will increase request activity on the main connection which may cause requests to stay in queue more often. This could result in overall reaction time decreasing.

Permission ID lookups

On start-up, the framework will try to get all available TS3 permissions from the server in order to perform the required lookups internally when permissions are retrieved or manipulated. This speeds up the lookup process as no query command needs to be run and evaluated.
By default, the frameworks query client may not be permitted to list the TS3 permissions (TeamSpeak returns error id=2568 msg=insufficient\sclient\spermissions failed_permid=5).
To resolve this issue and utilize the performance improvement, please grant the permission b_serverinstance_permission_list to the client (via. server group or client permissions)

When a permission is not found in the internal cache, a lookup is performed synchronously which will allow the permission service to work as expected but is highly dependent on request performance and may be slow in comparison.

High performance event listeners

With a high number of plugins (thus, a high number of event listeners), administrators may experience the performance burden of Java reflective calls as event listeners are currently called using plain reflected Method instances. This is not noticeably slower for low numbers of plugins installed (listeners registered) as reflection calls are still done in milliseconds.

In the future, the framework will use dynamically generated Lambdas which only need to be constructed once per listener (instance independent) and run on nearly as fast as a standard call in Java.
The feature is currently going through implementation & testing and can be activated using the jeak.frw.enableLambdaEvents JVM option. (-Djeak.frw.enableLambdaEvents=true)
Eventually, it will be enabled by default.


Feature not usable (without CP-modification) at the moment!

Due to class loading issues in the constructed lambdas, we cannot recommend using this feature at the moment. However, if you wish to enable the feature, make sure to add your plugins to the classpath of the system ClassLoader: -cp "jeakbot-1.0.0-SNAPSHOT.jar:libraries/*:plugins/*"