Konkurrierende Requests - Linear steigende Laufzeit?

[mson]

Heyho,

ich habe gerade mal eine Verständnisfrage:

Ich habe einen etwas komplexeren Select-Query, der in etwa 1 Sekunde läuft. Ich habe mittels Apache Bench einen Test für konkurrierende Zugriffe gemacht und komme bei 10 Clients dabei auf eine Laufzeit von ca. 10 Sekunden. Bei 100 Clients auf ca. 100 Sekunden; das sieht also sehr linear aus (Engine ist InnoDB).

Ist das zu erwarten? Ich glaube ich hab soweit alles in Richtung "concurrent connections" optimiert und war dann etwas ernüchtert, dass es dann doch nur linear ist. Wirklich concurrent ist das ja nicht. Daher kommen mir leichte Zweifel auf, ob das alles so seine Richtigkeit hat.

Viele Grüße
Malte

[protestix]

Datenbanken haben eine Warteschlange. Wenn ein Request 1 Sekunde dauert, kann der nächste Request halt erst danach abgearbeitet werden. Wenn der auch 1 Sekunde braucht dann ist das eben linear ansteigend. Ist also korrekt.
Aber warum dauert das so lange, hast du Indexe gesetzt?

[mson]

Alles klar, danke für die Erklärung!

Jupp, Indexe sind gesetzt. Hängt hiermit zusammen: https://www.php.de/forum/webentwickl...tion-mit-mysql sind recht komplexe Berechnungen mit sehr großen Datensätzen (1.000.000 Bewertungsdaten).

Danke noch einmal, schönen Abend noch!

[akretschmer]

Jupp, Indexe sind gesetzt.

MySQL hat keine Indexe für KNN.

[mson]

Was für eine random Aussage, dafür dass du a) meine genaue Implementierung gar nicht kennst und b) die Query sich nicht auf den kNN-Algorithmus bezog ich hab schon im anderen Thread verstanden, dass du mir PostgreSQL aufzwingen willst, das hilft mir aber nicht weiter. Schon gar nicht im Kontext der Fragestellung dieses Threads.

[akretschmer]

Du, mal echt, mir ist es egal, was Du machst. Nur war Dein anderer Thread auf KNN bezogen und hier sagst Du, Du hättest passende Indexe. Das paßt halt im MySQL-Kontext nicht zusammen, die konkrete Query hattest Du ja hier nicht genannt. Btw.: MySQL kann je Query nur ein Core nutzen. Auch das kann PG besser und kann erheblich die Performance steigern.

[mson]

Ja, ich meine nur, du kennst die Umstände nicht (z.B., dass hier der Zusammenhang darin bestand, dass es um CF geht und nicht im den kNN-Algorithmus im Speziellen) und platzt trotzdem anhand deiner eigenen Annahmen immer mit random Aussagen in die Threads, um PostgreSQL zu pushen. Ich sag ja gar nichts gegen PostgreSQL, aber es hilft mir nun mal in meinem Fall nicht. Mich nervt es, dass Foren heutzutage zu 90% aus "Warum machst du das nicht so und so?" oder "Google halt" bestehen bzw. generell zusammengefasst aus "Besserwisser-Tourette".

[akretschmer]

Datenbanken haben eine Warteschlange. Wenn ein Request 1 Sekunde dauert, kann der nächste Request halt erst danach abgearbeitet werden.

Moderne CPU's haben mehrere Kerne. Welche Rolle spielen die für Dich?

[protestix]

Ich benutze für meine eigene Seite Postgre. Ansonsten habe ich mich darum noch nie gekümmert, wie viele Kerne der Hoster auf seinen Rechnern hat, da ich dort ja sowieso nicht alleine bin, sondern mir den Server mit anderen teilen muss.

[akretschmer]

Ok. Wenn Du N Kerne hast, kann es aber sinnvoll sein, diese auch zu nutzen. Mit nur einer Verbindung muß natürlich alles nacheinander da durchgeschoben werden, mit mehreren Verbindungen könnten Abfragen parallel ausgeführt werden.
Ob man sich den Server teilen muß oder nicht hängt natürlich auch vom Hoster ab.

[erc]

Ist das zu erwarten? Ich glaube ich hab soweit alles in Richtung "concurrent connections" optimiert und war dann etwas ernüchtert, dass es dann doch nur linear ist. Wirklich concurrent ist das ja nicht. Daher kommen mir leichte Zweifel auf, ob das alles so seine Richtigkeit hat.

Das ist das normale Verhalten wenn Ressourcen fehlen bzw. irgendwo ein Bottleneck sichtbar wird. Das kann auch schnell exponentiell werden und danach ist zick. Bei einem Query der 1 Sekunden braucht, sind die Ressourcen aber nicht das primäre Problem, sondern der Query selbst. Du musst schauen das du den Query in Ordnung bringst, wenn der ins Frontend soll.