Slick verwirrt über numThreads und best practice für eine gute Leistung

Ich bin mit dem PlayFrameWork mit Slick und verwenden es in einem system, das alle I/O-Datenbank schwer. In meinem application.conf - Datei habe ich diese Einstellung:

play {
  akka {
    akka.loggers = ["akka.event.slf4j.Slf4jLogger"]
    loglevel = WARNING
    actor {
      default-dispatcher = {
        fork-join-executor {
          parallelism-factor = 20.0
        }
      }
    }
  }
}

Dies gibt mir 20 threads pro Kern für das Spiel-Anwendung und wie ich es verstehe Slick schafft es, die eigenen threadpool, ist die NumThreads Feld in Glatten bedeutet, dass die Gesamtzahl der threads, oder ist es (NumThreads x CPU ' s),? Und gibt es eine best practice für die beste Leistung? Momentan habe ich meine Einstellungen so konfiguriert, wie:

database {
  dataSourceClass = "org.postgresql.ds.PGSimpleDataSource"
  properties = {
    databaseName = "dbname"
    user = "postgres"
    password = "password"
  }
  numThreads = 10
}

InformationsquelleAutor user1591668 | 2016-05-28

33

numThreads ist einfach die Anzahl der Threads im Thread-pool. Slick verwenden Sie diese thread-pool zur Ausführung von Abfragen.

Die folgenden config-Schlüssel werden unterstützt, für alle Verbindungs-pools, die beide eingebauten und third-party:
- numThreads (Int, optional, default: 20): Die Anzahl der gleichzeitigen threads im thread-pool für die asynchrone Ausführung
  Datenbank-Aktionen. Finden Sie die HikariCP wiki für mehr imformation über
  Größe des thread-pool korrekt. Beachten Sie, dass für asynchrone
  Ausführung in Glatt sollten Sie optimieren die thread-pool-Größe (in diesem
  parameter) entsprechend anstelle der maximalen Verbindungs-pool-Größe.
- queueSize (Int, optional, default: 1000): Die Größe der Warteschlange für Datenbank-Aktionen, die nicht sofort ausgeführt werden, wenn alle
  threads ausgelastet sind. Jenseits dieser Grenze neue Aktionen sofort fehl.
  Auf 0 setzen für keine Warteschlange (direkte hand-off) oder " -1 " für eine unbegrenzte
  queue-Größe (nicht empfohlen).
Den pool abgestimmt ist für die asynchrone Ausführung standardmäßig. Abgesehen von der Verbindung Parameter sollten Sie nur festlegen, numThreads und queueSize in den meisten Fällen. In diesem Szenario gibt es Streit über den thread pool (über der Warteschlange), nicht über die Anschlüsse, so können Sie haben eine ziemlich große Grenze auf die maximale Anzahl von verbindungen (basierend auf dem, was der Datenbank-server noch umgehen kann, nicht das, was am effizientesten ist). Slick wird mehr verbindungen, als es gibt threads in den pool, wenn die Sequenzierung von nicht-Datenbank-Aktionen innerhalb einer Transaktion.

Der folgenden config-Schlüssel werden unterstützt, für HikariCP:
- url (String, notwendig): JDBC-URL
- Treiber oder driverClassName (String, optional): JDBC-Treiber-Klasse laden Benutzer (String, optional)*: User name
- Passwort (String, optional): Passwort
- isolation (String, optional): Transaction isolation level für neue verbindungen. Zulässige Werte sind: NONE, READ_COMMITTED,
  READ_UNCOMMITTED, REPEATABLE_READ, SERIALIZABLE.
- Katalog (String, optional): Standard Katalog für neue verbindungen.
- readOnly (Boolean, optional): Nur-Lese-flag für neue verbindungen.
- Eigenschaften (Karte optional): Eigenschaften zu passieren, um den Fahrer oder DataSource.
- dataSourceClass (String, optional): der name Der DataSource-Klasse zur Verfügung gestellt, die von den JDBC-Treiber. Dies ist vorgezogen
  - Treiber. Beachten Sie, dass die url wird ignoriert, wenn dieser Schlüssel gesetzt ist (Sie müssen
  verwenden Sie die Eigenschaften zum konfigurieren der Datenbank-Verbindung statt).
- maxConnections (Int, optional, default: numThreads * 5): Die maximale Anzahl von verbindungen im pool.
- minConnections (Int, optional, default: gleiche wie numThreads): Die minimale Anzahl von verbindungen zu halten, um in den pool.
- connectionTimeout (Dauer, optional, default: 1s): Die maximale Zeit zu warten, bevor ein Aufruf von getConnection Zeitüberschreitung. Wenn diese
  Zeit überschritten wird, ohne eine Verbindung immer verfügbar ist, eine
  SQLException geworfen wird. 1000ms ist der minimale Wert.
- validationTimeout (Dauer, optional, default: 1s): Die maximale Zeit, die eine Verbindung getestet werden, die für Lebendigkeit. 1000ms
  ist der minimale Wert.
- idleTimeout (Dauer, optional, Standard: 10 min): Die maximale Zeit, die eine Verbindung erlaubt ist zu sitzen Leerlauf in den pool.
  Ein Wert von 0 bedeutet, dass die verbindungen im Leerlauf werden nicht entfernt von der
  pool.
- maxLifetime (Dauer, optional, default: 30min): Die maximale
  die Lebensdauer einer Verbindung in den pool. Wenn eine Verbindung im Leerlauf erreicht
  dieser timeout, auch wenn Sie vor kurzem verwendet, wird in den Ruhestand versetzt
  pool. Ein Wert von 0 bedeutet keine maximale Lebensdauer.
- connectionInitSql (String, optional): Eine SQL-Anweisung, die ausgeführt werden, nach jeder neuen Verbindung die Schöpfung vor dem hinzufügen der
  pool. Wenn diese SQL nicht gültig ist oder eine Ausnahme wirft, es werden
  behandelt werden als ein Ausfall der Verbindung und die standard-retry-Logik wird
  gefolgt.
- initializationFailFast (Boolean, optional, default: false):
  Steuert, ob der pool wird "fail fast", wenn der pool nicht
  entkernt, mit ersten verbindungen erfolgreich. Wenn Anschlüsse nicht
  erstellt am pool-Startzeit, wird eine RuntimeException geworfen.
  Diese Eigenschaft hat keine Wirkung, wenn minConnections ist 0.
- leakDetectionThreshold (Dauer, optional, default: 0): Die Zeitspanne, die eine Verbindung aus dem pool, bevor Sie eine Nachricht
  protokolliert, was auf eine mögliche Verbindung undicht. Ein Wert von 0 bedeutet Leck
  die Erkennung ist deaktiviert. Niedrigste zulässige Wert für die Aktivierung Leck
  die Erkennung ist 10s.
- connectionTestQuery (String, optional): Eine Aussage
  der ausgeführt wird, unmittelbar bevor eine Verbindung ist, erhalten aus der
  pool, zu überprüfen, dass die Verbindung zur Datenbank ist noch am Leben.
  Es ist Datenbank abhängig und sollte eine Abfrage dauert sehr wenig
  die Verarbeitung von der Datenbank (z.B. "WERTE 1"). Wenn nicht gesetzt, wird die JDBC4
  Connection.isValid() Methode stattdessen verwendet wird (die in der Regel
  vorzuziehen).
- registerMbeans (Boolean, optional, default: false): ob oder Ob nicht der JMX-Management-Beans ("MBeans") registriert sind.
Slick haben eine sehr transparente Einstellung.Best practice für gute Leistung gibt Es keine Daumenregel. Es hängt von der Datenbank ab(wie viele parallel-Anschluss bietet) und Ihrer Anwendung. Es ist alles über die Stimmung zwischen den Datenbank - & application.
- Vielen Dank für die ausführliche Erklärung hat mir sehr geholfen.
InformationsquelleAutor Sky

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.