Paralle DB-Queries verschiedener Sessions möglich?

Hallo,

mich beschäftigt zur Zeit ein großes Problem: Ich habe eine PHP-Anwendung bei einem Kunden laufen mit bis zu 500 gleichzeitigen Nutzern. Mein Problem ist nun, dass die Datenbank-Queries nur sequentiell und nicht parallel abgearbeitet werden. Das heisst, dass bei einem aufwändigerem Select alle anderen Nutzer (bzw. deren Zugriff) warten müssen, was sich dann in extreme Wartezeiten bemerkbar macht.
Ich habe schon verschiedene PHP-Versionen (4+5) und Apache-Versionen (1+2) ausprobiert, aber überall das selbe Problem. Kann es sein, dass das Problem an Windows liegt, da hier ja nur ein Child-Prozess läuft (im Gegensatz zu Linux)? Allerdings werden ausreichend viele Verbindungen zur Datenbank aufgebaut, jedoch immer nur eine gleichzeitig genutzt.
Ob ich permanente, temporäre und grundsätzlich neue Verbindungen nutze, macht übrigens keinen Unterschied...

Hat jemand einen Tipp für mich?

Meine Umgebung:
Datenbank: Oracle 8.1.7, zugriff über oci8.dll
PHP 5.1.1
Apache 2
Windows 2003 Server

Danke und Gruß
haieman

[Forumsgast]

naja, der zugriff auf eine datenbank erfolgt immer benutzer-basiert... und du verwendest wohl für alle php-skripte den selben datenbank-benutzer / die selben datenbank-zugangsdaten ... richte einfach mehrere datenbank-user mit identischen schreib-lese-rechten ein und vergib die datenbank-zugangsdaten entweder zufällig oder per ring-liste.

Danke für die Antwort, aber das stimmt so nicht. Die Ausführung einzelner Statements hat nichts mit der Anmeldung zu tun. Ich kann mich 100 mal mit dem selber User in 100 verschiedenen Sessions anmelden, die Abfragen behindern sich in der Regel nicht gegenseitig (ausser bei gelockten Tabellen, dead-locks, etc.). Und gerade das verwundert mich so...

Sonst noch ne Idee?

[Forumsgast]

doch, das stimmt genau so.
alle queries des datenbank-users 'foo' werden serialisiert und hintereinander ausgeführt. erst wenn user 'foo' und 'bar' überhaupt an der datenbank eingeloggt sind, geht's mit parallelbetrieb los.
solange du in den php-skripten den selben dsn verwendest, wird die datenbank also nur einen einzigen user sehen. mysql, postgres, db2, oracle - überall das selbe.

grüße
axo

[Forumsgast]

Unter Windows ist es normal, dass nur ein Child-Prozess läuft, da Windows die Threads anders handhabt wie Unix. Bei Unix sind Threads immer auch eine Abart von eigenständigen Prozessen, unter Windows grundsätzlich nicht. Daran liegts wohl eher nicht.

Bei JDBC würde ich die Connection-Optionen auf uncommited read setzen. Inwieweit das der Oracle-Treiber von PHP auch unterstützt weiss ich nicht. Aber ich denke, es liegt bei dir wohl daran, dass die Selects aufgrund eines falschen Zugriffsmodus die Tabellen partiell sperren....
DB/2 kann man mittels "SELECT irgendwas.... WITH UR;" dazu bringen, grundsätzlich bei den Selects jegliche Parallelen Zugriffe zuzulassen. Vielleicht kann Orcale auch sowas.
Achja: uncommited read kann in dem Moment, wo Daten verändert werden, eventuell komische Effekte haben.

Zu guter letzt kannst du das Problem eventuell sogar dadurch beeinflussen, dass du mit der gleichen DB-Verbindung davor Updates gemacht hast oder Transaktionen aufgemacht hast o.ä.

Du bist dir grundsätzlich sicher, dass es wirklich die DB-Abfrage ist und nicht dass das Script woanders hängt?

Alternativ könnt ich noch vorschlagen, die Selects in mehrere Queries aufzuteilen. Damit verlagerst du die Last vom Oracle etwas auf den Webserver, auch wenn das ev. insgesamt sicherlich langsamer werden kann, ist das in manchen Situationen hilfreich.


Viele Ideen, hoffe, irgendeine war hilfreich.

[Forumsgast]

doch, das stimmt genau so.
alle queries des datenbank-users 'foo' werden serialisiert und hintereinander ausgeführt. erst wenn user 'foo' und 'bar' überhaupt an der datenbank eingeloggt sind, geht's mit parallelbetrieb los.
solange du in den php-skripten den selben dsn verwendest, wird die datenbank also nur einen einzigen user sehen. mysql, postgres, db2, oracle - überall das selbe.

grüße
axo

Sachlich falsch. Ich weiss zwar nicht, wie der Oracle-Treiber arbeitet, aber im Falle von MySQL und IBM DB/2 ist das definitiv sachlich falsch. Mit welchem User eine Verbindung aufgebaut wird, hat hier keinerlei Einfluss auf die Arbeitsweise von MySQL oder IBM DB/2. Und auch die PHP-Treiber für MySQL und IBM DB/2 furwerken da meines Wissens nach nicht derart dran rum.

Sobald du mehrere Verbindungen parallel unterhälst (was durch mehrfaches Starten des Scriptes gegeben ist), ist ein Parallel Betrieb unter normalen Umständen möglich.

[Forumsgast]

Schonmal daran gedacht vlt. die Queries zu cachen? Ich kenn dein Skript nicht aber wenn anscheinend so viele Daten abgerufen werden müssen kann ich mir gut vorstellen dass die Daten oft gleich sind.

Daher würde sich ein cachen vlt. anbieten.

SQL Queries cachen

Hallo zusammen,

danke für Eure Bemühungen, aber ich habe das Problem gefunden:
Ich hatte PHP 5.0.5 im Einsatz. Nach dem Wechsel auf PHP 5.1.1 läuft es reibungslos, da gab es wohl scheinbar noch einen Bug in der php_oci.dll.

Gruß
H.M.

[Forumsgast]

php_oci ist buggy ohne ende.

schau dir mal http://www.zend.com/de/products/zend...ore_for_oracle an.


Der Beitrag wurde verschoben, wegen...
... Postings im falschen Forum. Bitte beim nächsten Mal darauf achten..

Bemerkung:
Die gestellte Frage entspricht nicht dem Wissensstand eines Profis. Dazu: http://www.phpfriend.de/forum/viewtopic.php?t=21431
Bei Einspruch oder weiteren Fragen bitte an mich wenden.

moved to PHP - Fortgeschrittene