Ok, viel Erfolg. Wenn du das geschickt mit einer WHERE-Klausel in ein einzelnes Query packen kannst, denke ich sollte es schon schnell genug gehen.
Ich fürchte, das wird nichts. Der Code ist an dieser Stelle bereits nicht sonderlich komplex. Letztlich bekommt aber jeder Benutzer für jedes Forum seine individuelle Einstellung verpasst. Jeder Benutzer muss individuell behandelt werden, weil seine weiteren Gruppenmitgliedschaften berücksichtigt werden, um ggf. die Foren mehrerer Gruppen sichtbar zu schalten. Und die Schleife über alle Foren ist sehr kurz, dort werden keine Daten im Programmspeicher gesammelt. Das ganze ist halt einfach eine arbeitsintensive Aufgabe, da soll sich der Server mal dran gewöhnen. Es gibt Anwendungen, die rechnen ne halbe Stunde an irgendwas mit der Datenbank rum, die geben ja auch nicht nach 30 Sekunden auf oder legen alles lahm.
Der einzige Workaround, der mir programmseitig jetzt einfällt, ist die Menge der Benutzer zu partitionieren und in n Durchläufen alle Benutzer mit einer ID mod n[sub]max[/sub] = (n - 1) zu behandeln.
Naja, das Problem ist wohl weniger, dass die Datenbank nen großen Job verpasst bekommt, sondern dass dieser innerhalb eines PHP-Skripts abgewickelt wird 
Mal sehen, was wir da tun können…
denke auch, dass eher die ausfuehrzeit des phpskripts entscheidender faktor ist
Falls es weiterhilft: ich hab grad nochmal in den Code reingeschaut. Das Ändern der Forum-Flags für einen Benutzer läuft in 2 Schritten ab. Zuerst wird der aktuelle Wert gelesen und danach der neue Wert geschrieben falls er sich geändert hat. (Das Lesen ist notwendig, weil in diesem DB-Feld mehrere Bits kodiert sind und ja nur eins geändert werden soll…) Wenn der Prozess also abbricht, könnte es irgendwann zum Erfolg führen, wenn man ihn einfach wiederholt, weil er dann jedes Mal weniger schreiben muss, sondern nur noch liest.
Dann ist das aber ein Problem des Datenbankschemas.
Anders angeordnet muesste das auch in einem einzigen Query erledigt sein, wenn ich das richtig verstanden habe.
hust stored procedure hust
Hallo,
bitweise Operationen werden doch auch von SQL unterstützt. Vielleicht kannst du die Performance erheblich steigern, wenn du dir die zu ändernden Bits in PHP vorbereitest, und diese dann nur in einem Query der Datenbank schickst, anstelle jedes einzeln zu ändern. Das Lesen ist dann auch hinfällig.
Stored procedures helfen leider nur, die Datenübertragung zwischen Client und Server einzudämmen.
cu
Ford Prefect
Stored Procedures dürfen in MySQL AFAIK nur von einem DB-Administrator eingerichtet werden. Bringt hier auch nicht allzu viel.
Die Bit-Operationen von MySQL sind mit dem verwendeten DB-Abstraktionsmodell leider nicht nutzbar. Das ForumVis-Plugin müsste, um sie trotzdem nutzen zu können, ein Loch dadurch bohren und (unter Nichtnutzung sämtlicher Sicherheits- und Konfigurationsfeatures) direkte SQL-Abfragen formulieren, die ausschließlich mit MySQL funktionieren würden.
Wo ist denn nun überhaupt das Problem? Geht PHP der Speicher aus? Dauert PHP der Vorgang einfach nur zu lange? Gibt MySQL zwischendrin auf? Das steht doch alles im Log, woran es wirklich liegt. Wir stochern hier nur im Dunklen herum.
AFAIK ja.
Da wildgewordene Scripts bei FastCGI schnell boese werden koennen wenn sie nicht zeitnah gekillt werden, liegt der Timeout bei 15 Sekunden (frueher mal 10, aber irgendwo war das wirklich zu wenig).
Schnell böse? Hast du da auch was konkreteres? Sonst könnte man im Plugin-Code ja einfach an passender Stelle ein [m]set_time_limit(120)[/m] einfügen.
nur Interesse halber: in dem DB-Schema hat jeder Benutzer ein Attribut, in dem Bitweise Dinge wie Forensichtbarkeit kodiert sind? Hat das einen bestimmten Grund bzw. wieso sind derartige Dinge nicht über eine zusätzliche Relation “user_forum” o.ä. realisiert?
MfG
Stefan
Es ist so, dass waehrend der beschaeftigte Prozess nicht mehr antwortet der fcgi process manager alle paar Sekunden ein neues php-fcgi forkt.
IIRC hab ich noch nicht rausgefunden, was der Sinn davon ist, verhindern konnte ich es jedenfalls noch nicht.
Das Timelimit zu erhoehen wuerde das Problem nicht loesen sondern ueberhaupt erst verschlimmern.
geht das nicht irgendwie mit -idle-timeout?
Hm, kann ich nix zu sagen, ich hatte bislang keine Probleme mit PHP und FastCGI. Weiß jetzt aber auch nicht, ob ich da so oft langlaufende Prozesse starte. Prinzipiell bin ich aber der Meinung, dass sowas möglich sein muss. Nicht jeder Vorgang ist innerhalb von 2 Sekunden abgeschlossen.
Näheres zur UNB-Datenbank ist übrigens hier dokumentiert:
http://newsboard.unclassified.de/devel/docs/database
Sowat. Wuerdest du mal testweise ein Skript mit [m]sleep($viel);[/m] starten (und kurz danach ein anderes PHP-Skript aufrufen) und mir sagen, was im Apachelog dann passiert? Bei wird so lange alle 3 Sekunden (= startDelay, AFAIK) ein neues php-fcgi geforkt bis der erste Prozess wieder was ausgibt. Und das passiert unabhaengig davon, wieviele Requests in der Zeit reinkommen.
Kannst du das reproduzieren?
So, nun bin ich endlich dazu gekommen, das auszuprobieren. Meine Testmethode ist ziemlich primitiv, deshalb eine kurze Erklärung:
Das PHP-Skript kann je nach URL-Parameter eine beliebige Anzahl Sekunden warten. Ich hab’s mal mit 30 Sekunden probiert.
Da ich nicht weiß, in welchem Apache-Log ein PHP-FCGI-Forking stehen soll, hab ich einfach immer wieder die PHP-Prozesse gezählt:
ps aux |grep $userid |grep php5-fcgi |wc -l
Zu Beginn waren es für meine Domain und alle Subdomains insgesamt 14 Prozesse. Das klingt plausibel. Die vollständige Liste hinter der Zählung sieht auch gut aus. Wenn ich dann das Warteskript starte, ist es einer mehr. Wenn ich dann noch meine Homepage aufrufe, werden es alle paar Sekunden einer mehr. Das liegt aber innerhalb des Messtoleranz, find ich. Soll ich mal viel länger testen?
Jetzt, ca. 2 Minuten später sind die PHP-Prozesse immer noch da, aktuell 18. Mal schauen, wann die wieder weggehen.