Search code examples
kurento

Understandng kurento.conf.json file parameters

Can someone please explain various parameters which we have in kurento.conf.json file.

  • Resources usage limit for raising an exception when an object creation is attempted "exceptionLimit": "0.8" but i see this parameter is commented in the configuration file, is there any reason why it is commented or should we not use it ??

  • Resources usage limit for restarting the server when no objects are alive "killLimit": "0.7" even this parameter is commented, is it advised to make changes and use this parameter or not ?

  • "garbageCollectorPeriod": 240, will there be any performance issue if we change this value from 240 to 10-20 seconds ??

  • "threads": 10, as per my understanding these threads are responsible for handling incoming connection, so is it advised to increase this thread count to some higher value or will it create serious CPU usage ?

P.S: I have tried tweaking thread count and garbage collection count but I didn't observer much change, may be it might be the case that I was not able to generate load on KMS.

Solution

  • In .conf.json files, some params are commented just to show they are there and can be used, and others are there to show the default value. You can uncomment those to activate them.

    • "exceptionLimit": when the server load is at 80%, the media server will raise an exception. This feature is active by default, and teh key is here to show the default value.
    • "killLimit": it's a safety feature that checks the load of the machine when there are no media elements alive. If the resources are above the limit, and there are no objects instantiated, the media server instance is stopped. This was introduced as there were some situations in which the media server would eat up resources when there were no objects alive. That got solved, but the feature was left just in case. It is not active by default.
    • "garbageCollectorPeriod": Number of seconds media elements are kept alive, when the websocket session they are bound to is closed. This is in case you forget to release your pipeline, and the websocket that is connected to the media server is closed. If you are tidy, you won't see much difference here.
    • "threads": Number of threads to attend requests. This will matter in extreme load situations, like when many users join a room at the same time, and they all request new endpoints at the same time. Not likely to see a big impact here.

    I don't think you'll see huge differences by changing any of those, but in very specific scenarios.