Frage zum QueuedTracking Plugin (Performance)

Hallo zusammen,

ich teste derzeit das QueuedTracking Plugin, um Engpässe in meinen aktiven Zählungen zu beheben.

Dazu habe ich das Plugin, den redis-server und die PHP Extension phpredis installiert und die Konfiguration des Redis Servers auf default belassen.
Das funktioniert soweit, alle Requests werden in der/den Queue(s) gespeichert und mein Cronjob arbeitet im Hintergrund regelmäßig die Queue(s) ab (path/to/piwik/console queuedtracking:process).

Mit den Settings eine Queue (bzw. 1 Worker) und 50 oder 100 Requests komme ich derzeit auf ca. 210 Requests / Sekunde, die aus der Queue geholt und die DB geschrieben werden.
Diesen Wert möchte ich weiter tunen.

Ich habe bereits mit 2, 4, 8, 16 Worker getestet, die Anzahl der abgearbeiteten Requests / Sekunde wird jedoch NICHT höher.
Wenn ich mit bspw. 2 Worker teste, schafft jeder ca. 100 RQ/s, das ergibt summiert wieder nur ca. 200 RQ/s. Das sollte doch aber mit mehr Worker schneller gehen oder ??
Ich teste immer mit derselben Anzahl an Requests und unterschiedlicher Anzahl Worker, das Bearbeiten der Queues dauert insgesamt immer gleich lang.

Wo liegt hier das Problem ?
Warum arbeiten mehrere Prozesse genauso lang und sind nicht schneller ?

Ich hoffe, mir kann hier jemand helfen.
Das Problem ist einfach nicht zu finden.

Vielen Dank inzwischen !
LG

Das Limit ist sehr wahrscheinlich die Datenbank. Übrigen ist QueuedTracking nicht für schnellere Performance entwickelt sondern um Peaks abzufangen wenn über kurze Zeit sehr sehr viele requests rein kommen. Die Performance an sich kann unter Umständen ohne Queued Tracking genauso schnell sein.

Danke für die Antwort !

Kannst du dir evtl. vorstellen, was das Richtung DB auslösen könnte ?
Also Connection Limits werden definitiv nicht erreicht…

Das Abfangen von Peaks ist auch der Grund, warum ich das derzeit teste. Es kommen viele Requests rein, die ich unabhängig abarbeiten will und möglichst einen schnellen Response zum Client generieren will.
Ich wundere mich prinzipiell nur, warum eben das Aufteilen auf mehrere Worker nicht schneller ist, so genauso lang dauert wie ein einzelner.

Das kommt immer darauf an und müsste man sich genauer anschauen wie die Auslastung von DB / PHP etc. ist. Es kann sein dass dort “locks” sich gegenseitig blockieren in der DB (zum Beispiel falls transaktionen verwendet werden etc). Ich hab vor langer Zeit mal tests gemacht und in unserem Falle stieg die Performance bis zu 8 oder 16 worker immer mehr aber es hängt vom Server ab und wie viele Daten bereits in der DB sind, etc. Es ist wichtig viele Cores (z.b 8 cores mit 8 worker) um an Performance etwas zu gewinnen etc.

Die Auslastung der DB ist äußerst gering, bis maximal 0.80 läuft der Server.
Das sollte kein Problem darstellen.

Transaktionen werden natürlich für den Import der RQs aus der Queue verwendet (InnoDB). Hier sieht man, dass die Innodb_row_lock_waits beim Import steigen, was aber der Normalfall bei mehreren Prozessen sein sollte.

Bei einem gestrigen Test mit PHP 7 (derzeit verwende ich PHP 5.6) hat das bessere Performance gebracht. Ich teste derzeit immer mit ~4000 RQs insgesamt und konnte mit dieser Version 6-8 Sek. einsparen. Das ist mal nicht schlecht.

In der Doku steht: "With fast CPUs you can achive up to 250req/s with 1 worker, 400req/s with 2 workers and 1500req/s with 8 workers (tested on a AWS c3.x2large instance)."
Mit 1 bzw. 2 Worker (210 req/s und 320 req/s) bin ich ziemlich in der Nähe dieser Testwerte. Mehr als 4 Worker sind dagegen nur noch minimal schneller (4: 380 req/s, 8: 400 req/s, 16: 450 req/s).

Hier ein Output nach dem Import von 4000 RQs mit 4 Worker:
This worker finished queue processing with 81.63req/s (500 requests in 6.13 seconds)
This worker finished queue processing with 92.93req/s (1150 requests in 12.37 seconds)
This worker finished queue processing with 99.07req/s (1350 requests in 13.63 seconds)
This worker finished queue processing with 101.56req/s (1400 requests in 13.78 seconds)

Ein Import mit 8 Worker und 4000 RQs schaut ca. so aus:
This worker finished queue processing with 39.68req/s (900 requests in 22.68 seconds)
This worker finished queue processing with 40.8req/s (1450 requests in 35.54 seconds)
This worker finished queue processing with 41.72req/s (1650 requests in 39.55 seconds)
This worker finished queue processing with 45.42req/s (2150 requests in 47.33 seconds)
This worker finished queue processing with 48.32req/s (2550 requests in 52.77 seconds)
This worker finished queue processing with 56.07req/s (3425 requests in 61.08 seconds)
This worker finished queue processing with 58.3req/s (3650 requests in 62.61 seconds)
This worker finished queue processing with 68.89req/s (4500 requests in 65.32 seconds)

Was sagst du zu diesem Output (req/s und Dauer) ?

Cores sind auf dem Server genug vorhanden, aber die Frage ist, ob sich die Aufteilung auf mehr als 4 Queues überhaupt lohnt bei diesen Werten.

Es ist wirklich schwer hier viel dazu zu sagen ohne alle genauen Umstände zu kennen. Die Tests mit 400 - 1500 req/s wurden meine ich auf einer Datenbank mit nicht all zu vielen Besuchen gemacht und auf einem ziemlich starken Server mit einer dedicated Datenbank etc. 70req/s hört sich für mich an als könnte dort mehr potential sein aber man müsste das genau anschauen wo derzeit das Bottleneck ist.

Danke für deine Antwort !

Habe die Queue vor kurzem in Echtbetrieb genommen und habe hier deutliche Performance-Steigerungen. Derzeit sind durchaus ca 700 req/s mit 8 Worker drin. Das ist für mich ok, da es auch zeitweise weiter nach oben geht.

Das Thema ist abgeschlossen, Schuld war hier doch nur meine Testumgebung.
Nochmals Danke !!