Einige Leute würden sagen, dass zwei Fäden zu viele sind - ich gehöre nicht ganz dazu :-)
Hier ist mein Ratschlag: Messen Sie, raten Sie nicht. Ein Vorschlag wäre, den Wert konfigurierbar zu machen und ihn zunächst auf 100 zu setzen, dann die Software freizugeben und zu beobachten, was passiert.
Wenn Ihre Fadennutzung bei 3 liegt, dann sind 100 zu viel. Wenn sie den größten Teil des Tages bei 100 bleibt, erhöhen Sie sie auf 200 und sehen Sie, was passiert.
Vous かも Eigentlich könnte Ihr Code selbst die Nutzung überwachen und die Konfiguration für den nächsten Start anpassen, aber das ist wahrscheinlich übertrieben.
Zur Klarstellung und Ausarbeitung:
Ich plädiere nicht dafür, ein eigenes Thread-Pooling-Subsystem zu entwickeln, verwenden Sie auf jeden Fall das, das Sie haben. Aber da Sie nach einem guten Grenzwert für Threads gefragt haben, nehme ich an, dass Ihre Thread-Pool-Implementierung die Möglichkeit hat, die maximale Anzahl der erstellten Threads zu begrenzen (was eine gute Sache ist).
Ich habe Thread- und Datenbankverbindungs-Pooling-Code geschrieben, und sie haben die folgenden Eigenschaften (die meiner Meinung nach für die Leistung wesentlich sind):
- eine Mindestanzahl aktiver Threads.
- eine maximale Anzahl von Threads.
- die Schließung von Themen, die eine Zeit lang nicht benutzt wurden.
Die erste legt eine Mindestleistung für den Thread-Pool-Client fest (diese Anzahl von Threads steht immer zur Verfügung). Die zweite legt eine Beschränkung der Ressourcennutzung durch aktive Threads fest. Die dritte kehrt in ruhigen Zeiten zur Grundlinie zurück, um die Ressourcennutzung zu minimieren.
Sie müssen die Ressourcennutzung durch ungenutzte Threads (A) gegen die Ressourcennutzung durch nicht genügend Threads zur Erledigung der Arbeit (B) abwägen.
(A) ist im Allgemeinen die Speichernutzung (Stacks usw.), da ein Thread, der keine Arbeit verrichtet, nicht viel von der CPU in Anspruch nimmt. (B) ist in der Regel eine Verzögerung bei der Verarbeitung der eingehenden Anfragen, da Sie warten müssen, bis ein Thread verfügbar wird.
Das ist der Grund, warum man misst. Wie Sie bereits erwähnt haben, wird die überwiegende Mehrheit Ihrer Threads auf eine Antwort von der Datenbank warten, so dass sie nicht ausgeführt werden. Es gibt zwei Faktoren, die sich darauf auswirken, wie viele Threads Sie vorsehen sollten.
Die erste ist die Anzahl der verfügbaren DB-Verbindungen. Dies kann eine harte Grenze sein, es sei denn, Sie können sie am DBMS erhöhen - ich gehe davon aus, dass Ihr DBMS in diesem Fall eine unbegrenzte Anzahl von Verbindungen aufnehmen kann (obwohl Sie das idealerweise auch messen sollten).
Die Anzahl der Fäden, die Sie haben sollten, hängt dann von Ihrer bisherigen Nutzung ab. Das Minimum, das Sie laufen lassen sollten, ist die Mindestanzahl, die Sie jemals laufen ließen + A%, mit einem absoluten Minimum von (zum Beispiel, und machen Sie es konfigurierbar wie A) 5.
Die maximale Anzahl von Threads sollte Ihrem historischen Maximum + B% entsprechen.
Sie sollten auch auf Verhaltensänderungen achten. Wenn Ihre Nutzung aus irgendeinem Grund über einen längeren Zeitraum 100 % des verfügbaren Volumens erreicht (so dass die Leistung der Clients beeinträchtigt wird), sollten Sie die zulässige Höchstgrenze erhöhen, bis sie wieder um B % niedriger ist.
Als Antwort auf die Frage "Was genau soll ich messen?":
Was Sie speziell messen sollten, ist die maximale Anzahl von Threads, die unter Last gleichzeitig verwendet werden (z. B. auf die Rückkehr des DB-Aufrufs warten). Fügen Sie dann einen Sicherheitsfaktor von 10% für ejemplo (Hervorhebung, da andere Poster meine Beispiele als feste Empfehlungen aufzufassen scheinen).
Darüber hinaus sollte dies in der Produktionsumgebung für die Abstimmung durchgeführt werden. Es ist in Ordnung, vorher eine Schätzung zu erhalten, aber man weiß nie, was in der Produktion auf einen zukommt (deshalb sollten alle diese Dinge zur Laufzeit konfigurierbar sein). Dies dient dazu, eine Situation wie die unerwartete Verdopplung der eingehenden Client-Anrufe aufzufangen.
