Verständnis kurento.conf.json Dateiparameter

Question

Kann jemand bitte verschiedene Parameter erklären, die wir in kurento.conf.json Datei haben.

• Ressourcen Nutzungsbeschränkung für eine Ausnahme ausgelöst, wenn ein Objekt Erstellung versucht wird "exceptionLimit": "0.8" aber ich sehe diese Parameter in der Konfigurationsdatei kommentiert wird, gibt es keinen Grund, warum es kommentiert wird oder sollten wir es nicht verwenden ??

• Ressourcennutzungslimit für den Neustart des Servers, wenn keine Objekte aktiv sind "killLimit": "0.7" Selbst wenn dieser Parameter kommentiert ist, wird empfohlen, Änderungen vorzunehmen und diesen Parameter zu verwenden oder nicht?

• "garbageCollectorPeriod": 240, wird es irgendein Leistungsproblem geben, wenn wir diesen Wert von 240 zu 10-20 Sekunden ändern ??

• "threads": 10, nach meinem Verständnis sind diese Threads verantwortlich für die Behandlung der eingehenden Verbindung, ist es also ratsam, diese Thread-Anzahl auf einen höheren Wert zu erhöhen oder wird es eine ernsthafte CPU-Auslastung erstellen?

P. S: ich versucht habe, Fadenzahl und der Garbage Collection Zahl zwicken, aber ich habe viel Veränderung nicht Beobachter, kann es der Fall sein könnte, dass ich nicht in der Lage war Last auf KMS zu erzeugen.

Answer 1

In .conf.json Dateien werden einige params kommentiert sie dort nur um zu zeigen, und können verwendet werden, und andere sind es den Standardwert zu zeigen. Sie können die Kommentare auskommentieren, um sie zu aktivieren.

"exceptionLimit": Wenn die Serverlast 80% beträgt, löst der Medienserver eine Ausnahme aus.Diese Funktion ist standardmäßig aktiviert, und der Schlüssel dient zum Anzeigen des Standardwerts.

"killLimit": Es ist eine Sicherheitsfunktion, die die Last der Maschine überprüft, wenn keine Medienelemente am Leben sind. Wenn die Ressourcen über dem Grenzwert liegen und keine Objekte instanziiert sind, wird die Medienserverinstanz gestoppt. Dies wurde eingeführt, da es einige Situationen gab, in denen der Medienserver Ressourcen auffressen würde, wenn keine Objekte am Leben waren. Das wurde gelöst, aber das Feature wurde nur für den Fall gelassen. Es ist standardmäßig nicht aktiv.

"garbageCollectorPeriod": Die Anzahl der Sekunden, die Medienelemente am Leben bleiben, wenn die Websocket-Sitzung, an die sie gebunden sind, geschlossen ist. Dies ist der Fall, wenn Sie vergessen, Ihre Pipeline freizugeben, und der Websocket, der mit dem Medienserver verbunden ist, geschlossen ist. Wenn Sie sauber sind, werden Sie hier keinen großen Unterschied sehen.

"threads": Anzahl der Threads zur Teilnahme an Anfragen. Dies ist bei extremen Lastfällen wichtig, beispielsweise wenn viele Benutzer gleichzeitig einem Raum beitreten und alle gleichzeitig neue Endpunkte anfordern. Es ist unwahrscheinlich, dass sich hier eine große Wirkung zeigt.

Ich glaube nicht, dass Sie große Unterschiede sehen werden, wenn Sie irgendwelche davon ändern, aber in sehr spezifischen Szenarien.

Answer 2

• "exceptionLimit": Der Standardwert ist bereits 0.8 so kommentieren oder kommentieren Sie sie keinen Effekt hat, wenn Sie nicht den Wert ändern. Dieser Parameter konfiguriert die Menge der Ressourcen, die verwendet werden können, bevor eine Ausnahme ausgelöst wird, während ein neues Objekt erstellt wird. Die überprüften Ressourcen sind Speicher und Threads und verwenden die Grenzen, die die Anwendung hat.

• "killLimit": Dieser ist deaktiviert, wenn in der Konfiguration nicht vorhanden ist. Wenn es gesetzt ist, wird der Medienserver beendet, wenn alle Objekte zerstört sind, wenn die Ressourcen das Limit überschreiten. Dies ist nützlich, um sicherzustellen, dass der Server keinen Speicher oder Threads verliert.

• "garbageCollectorPeriod": Je niedriger die hier eingestellte Zeit, desto höher der CPU-Verbrauch. Kein enormer Anstieg der CPU-Auslastung, aber auch kritische Bereiche, die andere Aktionen verzögern könnten. Ich würde das niemals auf weniger als eine Minute einstellen.

• "threads": Dies sind die Threads, die RPCs behandeln. Medien werden auf eigenen Threads verarbeitet. Erhöhen Sie diese Zahl, wenn Sie nicht über eine große Menge an Anfragen verfügen, werden Sie nur einen Pool von Threads erhöhen, die auf Anfragen warten. Viele Threads in einem Prozess können die Leistung beeinträchtigen, da der Kontext wechselt. Darüber hinaus ist die Anzahl der Threads, die ein Prozess verwenden kann, begrenzt. Wenn Sie sie also für das Steuerelement ohne Bedarf ausgeben, kann der Medienteil aufgrund der Thread-Sortierung fehlschlagen.