Homeoffice: Betrieb von Contao 4 über eine Remote-Verbindung unfassbar langsam

Hallo,

angesichts der aktuellen Situation (Corona) bedeutet das für viele von uns ja Homeoffice.

Da wir in der Firma natürlich in Teams an einer Datenbank arbeiten, sind wir darauf angewiesen, dass diese zentral liegt und durch mehrere Leute zeitgleich benutzt werden kann.

Beim Aufruf des Backend einer größeren Seite mit vielen Datenbank-Requests (600+), was bspw. auch im Contao-Backend auftritt, wenn man in die Artikel-Ansicht geht, braucht jeder Request im Schnitt 50ms was dazu führt, dass man für einen Aufruf teilweise 30s braucht.

Habt ihr hier irgendwelche Tipps (außer die Zahl der Requests zu senken, was kurzfristig nicht drin ist; das schauen wir uns perspektivisch aber auch an)? Kann man irgendwas an der Contao-, MySQL- oder PHP-Konfiguration machen, damit das ganze einigermaßen schnell läuft?

Hier noch die parameters.yml:

Code:

---

database_host: 192.168.178.123
database_user: sqluser
database_password: ''
database_name: somedb

---

Wären hier vielleicht persistente Verbindungen zum MySQL-Server eine Möglichkeit? Nutzt Contao Transaktionen oder Table-Locking was dann am Ende zu Problemen führen könnte? Was habt ihr da für Erfahrungen?

Danke schon mal!

Ciao The_Unknown

Per VPN ins Firmennetz gehen oder die Sites auf Servern im Internet entwickeln (dann wären die DB-Requests lokal und nur der Response muss übertragen werden).

Eine VPN-Verbindung besteht bereits. Allerdings habe ich meinen Rechner zu Hause und dadurch ist das alles am Ende eine Internetverbindung. Oder übersehe ich da etwas?

Die 2. Variante hatte ich auch schon in Betracht gezogen. Das wäre so der Notanker.

Zitat:

---

Zitat von The_Unknown

Eine VPN-Verbindung besteht bereits. Allerdings habe ich meinen Rechner zu Hause und dadurch ist das alles am Ende eine Internetverbindung. Oder übersehe ich da etwas?

---

Die DB-Requests wären bei diesem Szenario ja lokal (blieben im Firmennetz) und würden die Internetverbindung nicht betreffen. Über die muss "nur" der generierte Response.

Und je nach dem, was entwickelt werden soll: wenn es z.B. die Programmierung von Modulen betrifft, könnte man sich eine lokale Kopie erstellen, dort entwickeln und die Ergebnisse der Arbeit ab und zu auf die Installation auf dem Firmenserver übertragen. Was hier möglich ist, hängt natürlich von den Aufgaben und eurer Arbeitswiese ab.

In meinem Szenario: Modulentwicklungen mache ich lokal und wenn ich "fertig" bin, pushe ich mein lokales git Repository auf das in der Firma. Dann können meine Kollegen drauf schauen. Skripte für Datenaufbereitung etc. mache ich direkt über eine SSH-Verbindung. Das ist zwar nicht sondelich elegant oder komfortabel, für die in meinem Fall meist kleinen Jobs tut's das aber.

Mhm. Der Server befindet aktuell auch nur in unserem Firmennetz. Das heißt, ich muss ja sozusagen ein VPN nutzen. Was ich auch bereits mache. Mein Projekt liegt lokal und der DB-Server im Firmennetzwerk. Trotzdem habe ich pro request 50ms.

Das Problem hier ist wirklich die Datenbank-Geschichte. Wir können nicht wirklich mit lokalen Kopien arbeiten, da wir teilweise auch zeitgleich zu zweit oder zu dritt an einem Projekt arbeiten. Da braucht es eine gemeinsame Datenbank die synchron ist.

Zitat:

---

Zitat von The_Unknown

Mein Projekt liegt lokal und der DB-Server im Firmennetzwerk. Trotzdem habe ich pro request 50ms.

---

Wie bereits geschrieben: je nach dem, was Du machst, ist es eventuell sinnvoll, sich eine Kopie der Datenbank des Servers auf seinen lokalen Entwicklungsrechner zu holen und dort weiter zu arbeiten. Die so entwickelten Module oder Stylesheets können dann -- nachdem gewisse Entwicklungsstände erreicht wurden -- wieder zurück auf den Firmenserver.

Naja, wie gesagt. Da bei uns mehrere Leute parallel an einem Projekt arbeiten, ist eine synchrone Datenbank leider unausweichlich :(

Aber würdest du erwarten, dass der Performance-Einbruch kleiner ist, wenn ich im VPN bin?

Der Performance Einbruch kann nur vermieden werden, wenn sich Webserver und Datenbankserver im selben Netzwerk befindet.

Ich hab mir auch schon Gedanken darüber gemacht und SQL Proxies recherchiert :D. Scheint aber nicht so feasible zu sein.

ProxySQL scheint eine Option zu sein. Dann würde man aber nur die doppelten Queries abfangen (schon mal gut). Aber ob der Cache so schlau ist, nach einem UPDATE die entsprechenden Einträge zu löschen, weiß man nicht.

Ich verschiebe gerade mal ein Projekt auf den Server und würde dann per Remote die PHP-Dateien bearbeiten. Das könnte evtl. praktikabel sein.

ProxySQL unterstützt außerdem auch keine prepared statements - und ich denke da würde dann ein Großteil der SELECTs wiederum nicht aus dem Cache kommen.

Danke für deine Antworten, Spooky!

Ich habe jetzt ein Setup zusammengebaut, was evtl. halbwegs praktikabel ist.

Das Projekt liegt lokal und auf dem Server. Das Abgleichen dauert mit phpStorm ewig. Daher beschränke ich mich auf den automatischen Upload der Dateien. Das klappt soweit ganz gut. Was aber ein Risiko ist: dadurch, dass ich nicht vor jeder Änderung diesen lokalen Stand synchronisieren kann, kann es sein, dass jemand versehentlich auf einem alten Stand arbeitet und das dann automatisch geuploadet wird. Direkt auf dem Remote-Stand zu arbeiten geht allerdings auch nicht, weil das dann wieder viel zu langsam ist und ich da eine IDE nicht sinnvoll verwenden kann (Indexing, Refactoring, ...).

Der Knackpunkt ist, dass die Requests ja nicht so lange dauern, weil sie in der Berechnung so lange dauern, sondern, weil vermutlich jedes mal eine neue Verbindung zum Server aufgemacht wird. Das hat mich schon zu einer persistenten Datenbankverbindung geführt. Das bringt aber wiederum neue Probleme mit sich und scheint auch keine Option zu sein :(

Oder kann es sein, dass VPN und/oder MySQL irgendwie falsch konfiguriert sind? Ich kann mir irgendwie nicht vorstellen, dass alle mit einem VPN diese heftigen Probleme haben. Gerade unser Berufsstand arbeitet ja gern und viel in Home-Office.

Das Laufzeit-Problem wirst du niemals umgehen können, wenn die Datenbank nicht im selben lokalen Netz ist wie der Webserver. Per VPN magst du eine lokale IP im Netzwerk des Servers bekommen, aber es ändert nichts dran, dass die Queries und die Ergebnisse vom Server zu dir bzw umgekehrt übertragen werden müssen. Ist halt nicht das selbe wie ein PC der direkt im lokalen Netzwerk ist. Vermutlich läuft der Datenverkehr von dir zuhause auch noch quer durch halb Deutschland über mehrere Hops zum Internetprovider und dann von dort zum Server. Das dauert halt. Selbst wenn es nur 10 ms dauern würde - was superoptimistisch ist - hättest du immer noch einen Faktor 10 im Vergleich zum Büroarbeitsplatz. Da werden aus 3 Sekunden dann eben ganz schnell ;) 30. Wenn sich das nicht umgehen lässt, dass mehrere Personen gleichzeitig an der selben Datenbank rumfrickeln ... wenn die Datenbank nicht zu den Dateien kommt, dann müssen eben die Dateien (+IDE) zur Datenbank kommen. Ihr habt doch dort alle einen Arbeitsplatzrechner. Habe damit zwar keine praktische Erfahrung, aber vielleicht wäre es insgesamt schneller auf dem Arbeitsplatzrechner zu arbeiten (Remote Desktop)?

Remote-Desktop wäre eine Option. Das werden wir noch testen.

HTML-Code:

---

dann müssen eben die Dateien (+IDE) zur Datenbank kommen.

---

Wie genau soll die IDE zur Datenbank kommen? Das wäre in der Tat super, wenn man phpstorm auch noch auf dem Server laufen lassen kann. Ist das überhaupt möglich oder habe ich dich falsch verstanden?

Naja, nicht auf dem Webserver. Aber eben auf deinem normalen Arbeitsplatzrechner, der netzwerkmäßig schnell genug an den Datenbankserver angebunden ist. Sonst könntest du von dort auch nicht vernünftig arbeiten. Da dürfte ja sowieso schon alles installiert sein was du brauchst.

Ich glaube, dass nur gemeint war, die IDE im selben Netzwerk wie die Datenbank laufen zu lassen, also auf den PCs im Büro, wo auch der DB-Server liegt. Denn in Büro ging ja noch alles schnell genug. Aber für jeden Mitarbeiter eine eigene IDE, nicht eine auf dem Server.
Dann die Rechner im Büro von zu Hause aus per Remote Desktop zu bedienen.

Edit: schade, dass man während des Tippens nicht sieht, dass schon eine Antwort da ist ;).

Das würde dann Remote Desktop bedeuten, oder? Da wird programmieren aber auch schwer, wenn es Klötzchenbildung wegen der Übertragung gibt :(

Aktuell würde ich in die Richtung tendieren, phpstorm auf dem entfernen Rechner laufen zu lassen mit lokaler Kopie, die automatisch auf den Server im Büro uploadet.

So langsam wird echt klar, dass das Ganze echt Einschränkung bedeutet :(

Das kann ich bei solchen Projekten, wo mehrere Leute gleichzeitig an der selben Datenbankinstanz arbeiten, absolut nachvollziehen. Da tue ich mich als Einzelkämpfer natürlich wesentlich leichter. Da ist Homeoffice der Normalfall und ich bin der Einzige, der in der Datenbank rumpfuscht.

Vielleicht gibt es hier ein paar Anregungen, wie man lokal entwickeln kann und dennoch den "Ärger" mit dem DB-Merge gering hält:

https://www.trilobit.de/ck2019/peter/

Grund-Idee:
Wenn ich ein Modul/Bundle/Erweiterung entwickle, dann betrifft dies in der Regel nicht die komplette DB, sondern immer nur 1-2 Tabellen. Wenn ich jetzt gezielt nur diese Tabellen - oder (ich weiß ja was ich tue an der DB) nur meine ergänzten Zeilen Dumpe, lässt sich dies einigermaßen gut mergen in die Haupt-DB. Wenn jetzt beim Dump auch noch die ID weggelassen wird, kann ich das nahezu problemlos in die Datenbank übertragen.

Bspl.:
Ein neues Bundle bringt auch Anpassungen/Ergänzungen an tl_module mit.
Ein erster Dump passt nur die Struktur an.
Jetzt lege ich lokal im BE ein Modul Beispielhaft an - oder auch schon das "finale" Modul.
Jetzt hole ich mir diese eine Zeile aus tl_module und dumpe sie ohne die Spalte ID.
Dann kann ich dieses Modul einfach in die Hauptdatenbank importieren. Konflikte mit doppeler ID gibt es nicht. Es wird automatisch der nächste autoincrement Wert Verwendet. In der Live-Datenbank bleibt dann nur noch das Modul an der passenden Stelle einzubinden.

Teilen sich die Entwickler die Arbeiten auf und jeder zu Hause hat exclusiven Zugriff auf "seine" Tabellen, dann könnte der Dump der jeweiligen einzelnen Tabellen noch einfacher sein.

VG
Peter ;-)