Understandng kurento.conf.json file parameters

Question

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.

Answer 1

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.

Answer 2

• "exceptionLimit": the default value is already 0.8 so comment or uncomment it has no effect if you don't change the value. This parameter configures the amount of resources that can be in use before an exception is raised while a new object is being created. The resources checked are memory and threads, using the limits that the application has.

• "killLimit": This one is disabled if is is not present in the configuration. If it is set, it will kill the mediaserver when all the objects are destroyed if the resources are over the limit. This is useful for being sure that the server is not leaking memory or threads.

• "garbageCollectorPeriod": The lower the time you set here the higher the cpu consumtion. Not a huge increase on CPU consumption, but also getting critical regions that could delay other actions. I'd never set this to less than a minute.

• "threads": This are the threads that handle RPC's. Media is processed on its own threads. Increasing this number, if you don't have a huge amount of request, will not do nothing but increase a pool of threads that will be waiting for requests. Having a lot of threads on a process can affect its performance because the context switches. Additionally, the number of threads that a process can use is limited, so if you spend them on the control without need, then media part could fail because of thread sortage.