Synchronisation häppchenweise um Abbrüche zu vermeiden #5446
Comments
|
+1 Man braucht aber keine große Anzahl. Bei mir (lokaler Ubuntu Server) reicht ein einzelnes 1.5GB Video zum Abbruch (ok, die Webhosting-Server sind schneller, aber max_execution_time oft knapper). Da reicht die Zeit nicht einmal, um einen (1) Hash zu bilden. |
|
Hm, ist aber nicht gerade beruhigend, wenn alle referenzierten Tickets geschlossen sind, also anscheinend nichts an diesem Problem getan wird? Im Ticket #5009 schlägt Thyon auch eine häppchenweise-Abarbeitung vor und du meintest, dass du mal schaust, aber das Ticket wurde ebenso geschlossen. Es handelt sich hier um einen essentiellen Part eines Content Management Systems - da ist es doch ein fatales Signal, wenn die Synchronisation die ganze Geschichte abrauchen lässt, sofern die Leute nicht gerade einen eigenen Server haben. Ich halte das für ein ganz wichtiges Problem. |
|
Es wird nicht "nichts an dem Problem getan", sondern es gibt für das Problem keine Lösung (wie in den Tickets erklärt). Wir haben das Thema auf der Agenda der AG Core und sollte uns eine Lösung einfallen, würde ich #5009 wieder öffnen. |
|
Danke. |
|
Das Prinzip bei mysqldumper abschauen? (bzw. das Konzept) Mal als Tipp, aber sicher schon bekannt. Das Teil peilt sich beim Backup automatisch auf Speicher und Zeit Begrenzungen ein. |
|
Ja, das BYSU Backup-Skript macht IMHO auch was Ähnliches, nämlich Speicherlimit und Skriptlaufzeit dynamisch anzupassen. |
|
Das Prinzip ist mir klar (hab ich ja u.a. beim Versenden von Newslettern so implementiert). Der Unterschied ist nur, dass es hier so nicht geht, da die Datenkonsistenz während der Synchronisierung nicht gewährleistet ist! |
|
Wir arbeiten nach dem selben Prinzip bei syncCto und dort haben wir es bis zu einer bestimmten Grenze auch geschafft. Auch wenn da das Problem noch nicht ganz behoben ist, da wir ab und zu immer noch die Speicherlimits sprengen. Eine Lösung ist aber vorhanden. |
Dann musst du alle Datenoperationen während der Synchronisation sperren. Low-Level Änderungen via FTP/FS kann man natürlich nicht sperren, aber damit muss man leben. |
|
Wie soll das denn über mehrere Request hinweg funktionieren? Soweit ich weiß, hebt PHP automatisch Table-Locks auf, wenn das Skript abgearbeitet wurde. Außerdem dürfte man während der Synchronisation eigentlich auch nicht lesend zugreifen, denn die Pfade könnten ja noch falsch sein. Eine partielle Abhilfe schafft sicher der geplante Wartungsmodus, aber auch der löst das Problem nicht vollständig. |
|
Mit Transaktionen glaube ich, musste man arbeiten: |
|
Transaktionen == InnoDB und leider (noch) nicht MyISAM. |
|
Und mit einer Kopie: zuerst tl_files kopieren und dann die Kopie synchen und schliesslich wieder zurückkopieren |
|
Auf jeden Fall eine gute Idee. Aber klappt das mit richtig vielen Datensätzen? |
|
Ich komme mehr aus der Datenbankecke (20+ Jahre Oracle, 10+ Jahre db-driven Web), denke vielleicht mal anders, hier meine Überlegungen:
Ein Ansatz:
Die Umsetzung dürfte nicht so schlimm sein wie es zunächst aussieht. Es gibt dabei natürlich noch ein paar nickelige Details (challenges not problems...). Ob man es anschließend auch im FE erlauben kann (ich habe irgendwo dazu ein issue gesehen), wäre dann zu prüfen. Ebenso Sync von file subtrees. Für Anwender mit eigenem Server (real cron oder inotifywait Möglichkeit) sollte idealerweise ein (kompatibles) Batchverfahren existieren, das den Sync automatisch im Hintergrund erledigt (ideal mit inotifywait bzw. icrond). Wenn hier der Ansatz als lohnenswert gesehen wird und sonst keiner richitg aktiv ist, versuche ich mich gerne an der Umsetzung. |
|
@thomaspahl 's Ansatz klingt echt gut. Ich würde auch über ein Lockfile gehen, einfach einen timestamp in Eine Prüfmethode könnte so aussehen: class Files
{
public static function isLocked()
{
if (!file_exists('system/tmp/sync.lock')) {
return false;
}
$maxExecutionTime = ini_get('max_execution_time');
if ($maxExecutionTime <= 0) {
$maxExecutionTime = 120; // fallback, 2 minutes timeout
}
$expire = file_get_contents('system/tmp/sync.lock') + ($maxExecutionTime * 2);
if ($expire > time()) {
return true;
}
unlink('system/tmp/sync.lock');
return false;
}
} |
|
Ich nehme an, dass md5_file() zum Abbruch führt, resp. die Zeit frisst. Ich kann mir jetzt aber nicht erklären, wozu wir den Hash überhaupt brauchen. Es geht doch "nur" darum, die Folder-/File-Struktur in der DB abzubilden. Ob die Prüfsumme aus irgend einem Grund ändert, kann doch dem System egal sein. Somit sehe ich den Ablauf wie folgt:
Die Synchronisation gehört meiner Meinung nach ins Menu Systemwartung. Die Sperre würde ich nicht anhand einer maxEcutionTime entfernen. Ich würde die Sperre aber durch eine Meldung angezeigen (Analog "abgesicherter Modus"). Im Fehlerfall kann die Sperre manuell entfernt werden (Checkbox analog dem abgesicherten Modus). |
|
@bekanntmacher nein, der Hash ist notwendig um Verschiebungen erkennen zu können. Wenn du die Sperre nicht automatisch aufhebt, wie gehst du damit um, wenn z.B. über einen Redakteur oder im FE die Sperre zu einem Dead-Lock führt, weil weder ein Redakteur und erst recht kein FE Besucher die Sperre entfernen darf? Vor allem wenn der Sync von extern getriggert wird, z.B. via cron ist ein automatisches Aufheben notwendig! |
|
@tristanlins nein, ist er nicht:
|
Also soweit ich die definition im Kopf habe, sollten vor allem Verschiebungen via FTP/FS durch den Sync erkannt werden. Deine Aussage ist also falsch. Aber vielleicht kann uns @leofeyer hier aufklären wie die Definition ist. |
|
Ist mir auch so bekannt, dass u.a. genau die Erkennung der Verschiebungen außerhalb von Contao erkannt werden können eines der Features ist. |
|
Das ist schon möglich. Es ist als Input meinerseits zu verstehen, das Konzept nochmals genauer anzuschauen... |
|
Wenn sich das wie oben von mir beschrieben umsetzen lässt, ist auch eine zusätzliche (Performance-)Option einfach zu ergänzen:
|
|
@thomaspahl die 3 stufen sind inkonsistenz: mv b a; mv c b <- fail bei detect moves; edit: oder auch nicht, kp grad, aber die ganze sache ist mMn eh zu verwurschtelt, deswegen: Ich finde den sync für FTP/native FS unnötig, wer sowas brauch muss halt auf native inode listener zurückgreifen... (oder alternativ ein manuelle nachträgliche eingabe im BE) Vorallem zu zeiten von JS-Uploadern ist FTP zugang gar nicht mehr so notwendig. Da würde ich lieber mehr arbeit in eine bessere Bedienung des Contao Datei Managers stecken (direct D&D in den Filetree und so sachen) |
|
@backbone87 Deinen letzten Eintrag finde ich irritierend, da mir nicht klar, ist ob ich dich richtig verstehe. Willst du sagen, dass man deiner Meinung nach FTP-Uploader komplett ignorieren soll und Redakteure einen Massenupload oder sehr großen Dateien über den Core-Uploader im Backend versuchen sollen? Meiner Erfahrung nach, kann man das total vergessen. Situation 1 - viele neue Daten die in diversen Unterordnern stecken: Schon mal versucht über den aktuellen Core-Uploader von Contao 3 in der Dateiverwaltung mehrere hundert Bilder in diversen Unterordnern auf einen Satz hochzuladen? Via FTP ist das ein Klacks. Situation 2 - große Dateien: Schon mal versucht im Core-Uploader von Contao 3 auf einem durchschnittlichen Webspace eine große Datei hochzuladen? Sagen wir mal, eine mehrseitige Broschüre mit großflächigen Bildern (~ gerne mal 50 MB), ein etwas längeres Video oder größere Audiodateien? Bilder in Druckqualität für einen Pressebereich? Via FTP kein Problem. Solange wir also in Contao CORE selbst keinen Uploader haben, der beide Situationen locker und mit entsprechendem Zwischen-Feedback an die Redakteure beherrscht, sollten wir entweder schleunigst eine Lösung für die Probleme rund um die Synchronisation haben oder aber aufhören damit zu werben, dass der Core für größere Websites (mit entsprechenden völlig marktüblichen Anforderungen) geeignet ist. |
|
Auf php.net gibt es noch einige Alternativvorschläge bzgl. Performance: http://php.net/manual/de/function.md5-file.php Dort werden als Alternativen zu md5_file() zwei Verfahren genannt, die je nach Dateigröße schneller sind. Sie funktionieren jedoch über exec(), sind also keine Lösung:
Wenn ein File-Hash unbedingt benötigt wird und man es nicht ganz so genau nimmt, wäre es vielleicht ein Weg, den Hash nur über einen Teil der Datei und die Dateigröße zu bilden: Wie NinaG schon schrieb: Upload über FTP muss weiterhin gewährleistet sein. Ich denke da nur an Seiten mit einer Vielzahl an kleinen Bildern oder eben großen Videos oder Druckvorlagen. Nachtrag: Habe eben mit openssl md5 und md5_file getestet und konnte die auf php.net genannten Geschwindigkeitsvorteile bei großen Dateien nicht nachvollziehen. Wer es ausprobieren möchte, sollte die Tests mehrfach laufen lassen, da sonst u. U. die Geschwindigkeit des Massenspeichers (HDD oder SSD) ungleich in die Messung mit einwirkt. |
|
@NinaG
... denn, ja, der Standarduploader ist noch kein annähernd gleichwertiger Ersatz für FTP. FTP hat einfach das Problem, das die ausgeführten FS-Commands (move, copy, touch, etc.) nicht an ein externes Script weitergeleitet werden können. Das kann man dann erst auf OS-Ebene wieder (mit einem inode-Listener oder anderen FS-Layern). Deshalb ist eine Software immer "blind auf dem FTP Auge". |
|
Die derzeitige Dateiverwaltung in der DB ist schick für Dateibestände mit wenigen und kleinen Dateien (was wohl die Mehrzahl der Installationen trifft). Für größere Dateimengen oder große Dateien ist die Architektur der Dateiverwaltung derzeit offenbar unausgereift. Auch meine Krücke zum Sync (weiter oben) dürfte da nur teilweise helfen. Bei großen Dateien ist der Hash kritisch, aber das Problem ist nicht auf den Hash beschränkt: Testcase: 3.0.6 (core master) update über 3.0.5 Music Academy install.
Weitere Beobachtungen:
Ich habe mal die sources von Drupal, Joomla, Papaya, Typo3, Wordpress auf md5_file() und md5() gescannt, um zu sehen was die so machen. md5_file() kommt überhaupt nur noch in Typo3 vor, die md5() Auswertung ist wegen der Menge etwas mühsam, zumindest in Joomla werden da auch file hashes berechnet Meine Schlussfolgerungen (supporting Nina, bekanntmacher, ..)
Damit ihr mich jetzt prügeln könnt, bin ich auf der Konferenz im Entwickler-Workshop... |
|
@thomaspahl Super! Danke für die ausführliche Analyse. Ähnliches hatte ich bereits befürchtet, ohne den Quelltext gesichtet zu haben. Die Geschichte mit den Thumbnails ist ein alter Hase, gegen den ich in früheren Versionen von Contao bereits zu kämpfen hatte. Die einzige Lösung damals war: Thumbnail-Preview ausschalten. Nachdem die Thumbnails aus waren, war das System wieder bedienbar. Vermutlich liegt es also an den Bildern. Vielleicht wäre es ein Lösungsansatz, das src-Attribut erst bei Sichtbarkeit per JS mit Inhalt zu füllen. Damals war jedoch die Devise: Das Backend muss auch ohne JS funktionieren... Jedes Bild erzeugt einen Request. Ist die Frage, was hier wirklich passiert, was den Browser in die Knie zwingt, wenn mehrere Tausend Bilder geladen werden sollen... btw. Was ich nicht sonderlich gelungen finde, ist, dass file-sync nur als Admin möglich ist. Damit müsste ich einem Kunden, der seine Dateien per ftp bereit stellt, Adminrechte geben. Wozu soll diese nicht konfigurierbare Einschränkung gut sein? |
|
@ofriedrich Die Display-Problematik des Dateimanagers bei vielen Dateien hängt nicht an Bildern und evtl. 1000 Nachlade-Request. Bei Anzeige von 3000 .txt Dateien wird nur 1 Request an den Server geschickt (der für die Seite), die Icons sind gecacht, ebenso CSS etc. Hier kommt der Browser beim Rendern ins Schwitzen (der HTML Quellcode ist fast 7MB). Bei den 1000 kleinen Bilddateien sieht man zwar das Laden, aber eigentlich stecken Server und Browser das im erwarteten Umfang weg, auch hier ist das anschließende Rendern der Schwerpunkt (man kann den Sprung in CPU sehr genau sehen). Müssen Thumbnails erst generiert werden, ist der Server erst lange am Rödeln bevor er den ersten Output produziert - wenn er es denn schafft, da häufen sich die HTTP 500 errors. |
|
In 3a57b90 wurden umfangreiche Änderungen am DBAFS vorgenommen. |
|
DBAFS := Database Assisted File System oder DBAFS := Database Aided File System ? |
|
Beides ist möglich. "aided" ist ein bisschen technischer (es gibt z.B. "computer-aided" oder "machine-aided") und "assisted" ist ein bisschen allgemeiner (wobei es auch "computer-assisted" gibt). |
ghost
mentioned this issue
Sobald man wirklich viele & große Dateien in der Dateiverwaltung hat, ist die Chance sehr groß, dass die Verbindung bei der Synchronisation abbricht, weil die Maximum Execution-Time o.ä. erreicht wird. Bei durchschnittlichen Hosted-Webspaces kann das ziemlich fix geschehen, da dieses Hosted Spaces alle nicht so arg stark sind, selbst wenn es größere Pakete sind.
Ich habe hier z.B. einen Kunden der unter anderem ca. 500 MP3-Dateien in der Dateiverwaltung hat (die auf unterschiedlichsten Seiten innerhalb der Website eingebunden sind), die eine Gesamtgröße von ca. 1.5 GB haben. Leider tritt das Problem des Abbruchs bei der Synchronisation aber auf, so dass die Dateiverwaltung praktisch unnutzbar ist, weil die Seite bei jeder Synchronisation hopps geht.
Daher meine Bitte:
Bitte baut die Synchronisation so um, dass sie häppchenweise synchronisiert. Ich kenne das von anderen Programmen so, dass man dort festlegen kann, nach wievielen Sekunden die Aktion automatisiert (glaub via JS?) kurz unterbrochen und neu gestartet wird (ab dem Punkt, an dem sie zuvor bewusst nach der Zeit unterbrochen wurde).
Ich denke, das wäre eine sehr wichtige Sache um die eigentlich gute Idee der Synchronisation auf Hosted Webspaces gut nutzbar zu machen, denn so wie das derzeit ist, kann ich Contao 3 niemandem empfehlen, der auf seiner Website aktiv eine größere Anzahl von Audio oder Video-Dateien in Inhaltselementen nutzen will.
The text was updated successfully, but these errors were encountered: