Den Eindruck habe ich leider besonders in letzter Zeit auch. Wobei mich die altbackene Oberfläche deutlich weniger stört als ein paar andere Dinge wie z.B. die PHP-Version pro Domain.Zitat:
Zitat von tab
Druckbare Version
Den Eindruck habe ich leider besonders in letzter Zeit auch. Wobei mich die altbackene Oberfläche deutlich weniger stört als ein paar andere Dinge wie z.B. die PHP-Version pro Domain.Zitat:
Zitat von tab
Ja, die Oberfläche ist mir persönlich auch wurscht. Sie funktioniert und ich finde problemlos die Einstellung die ich suche, das reicht mir völlig. Klar, auf meinem Smartphone ist sie schlicht unbedienbar. Aber das brauche ich selten - bisher noch nie - und mehr als CSS müsste dafür auch nicht überarbeitet werden.
Leider nicht, der Quellcode ist so übel, dass man da mit CSS richtige Probleme bekommt. Ich habe mir das wichtigste mit dem Addon Stylus https://addons.mozilla.org/de/firefox/addon/styl-us/ angepasst.Zitat:
Zitat von tab
PHP-Code:form table table table td.schwarz12[colspan="7"] {
color: #333;
font-size: 1rem;
font-family: Verdana;
}
form table table table td.schwarz12[colspan] a.schwarz12,
form table table table td.schwarz12[colspan] a.schwarz12b {
background-color: #eee;
color: #333;
display: inline-block;
font-size: 1rem;
line-height: 40px;
min-height: 40px;
min-width: 40px;
text-align: center;
font-weight: normal;
}
form table table table td.schwarz12[colspan] a:focus,
form table table table td.schwarz12[colspan] a:hover,
form table table table td.schwarz12[colspan] a:active,
form table table table td.schwarz12[colspan] a.schwarz12b {
background-color: #333;
color: #eee;
text-decoration: none;
}
form table table table td.schwarz12[colspan] a.schwarz12b[href*='&num=&msg='] {
background-color: #eee;
color: #333;
}
[class^=mytextarea] {
font-family: Consolas;
font-size: 14px;
width: 70vw;
min-height: 300px;
}
In meinen Webgo Accounts kann ich nur bis PHP 7.1 stable auswählen.
Ich bin auf vielen Servern unterwegs. Zuerst versuche ich immer ohne die Cloud, um diese Ressource zu schonen, wenn's nicht geht, schalte ich sie ein. Da sind einige dabei, wo ich die Cloud einschalten muss.
Nur mal so als Idee :Zitat:
Zitat von Andreas
Gibt es eine Möglichkeit dem Composer Aufruf via CM den Parameter '-d memory_limit=-1' mitzugeben ?
Ja, gibt es, eingeben kann man das. Aber es steht halt einfach nicht mehr RAM zur Verfügung. Ob das jetzt der Prozessmanager begrenzt oder wer/was auch immer.
Und wo ?Zitat:
Zitat von tab
Ich hatte bei meinem Hoster beim manuellen Aufruf des Composers auch Memory Probleme und konnte diese mit diesem Parameter 'lösen'.
In der Konsole beim Aufruf des Befehls, so wie Du es geschrieben hast. Da kann man freilich alles reinschreiben. Aber ein unendliches memory_limit bedeutet halt noch lange nicht, dass der Prozess unendlich viel RAM zur Verfügung hat. Es bedeutet lediglich, dass PHP nicht von sich aus einen Fehler wirft bei Überschreitung des memory_limits. Der Fehler ist dann halt, dass das allokieren des Speichers fehlgeschlagen ist. Im Endeffekt ist das Ergebnis das selbe, nur dass der Prozess halt läuft, bis er irgendwann den benötigten Speicher nicht mehr bekommt. Bei Deinem Hosting hat der Prozess damit eben genügend RAM bekommen, hier aber nicht.
Zitat:
Zitat von tab
Ich glaube, es war gemeint, dass auch der Contao Manager, nicht per Konsole, diesen Parameter bekommen soll.Zitat:
Zitat von harley-rider
Bei manchen Serverkonfigurationen ist das ohnehin bereits der Fall: https://github.com/contao/contao-man...ig/servers.yml
Yeap !Zitat:
Zitat von folkfreund
Sorry, ich habe keine E-Mail-Benachrichtigung erhalten. Ich möchte nicht unhöflich erscheinen.
Vielen herzlichen Dank für die Antworten auf meine Fragen. Das hat mir schon sehr bei der Einschätzung geholfen.
Meine umgezogene Website läuft, Matomo/Piwik auch, alles recht flott (wesentlich flotter als bei jweiland). Der Import meiner "alten" Piwik-/Matomo-DB mit 100MB hat mehr als 8 Stunden gedauert, da war ich misstrauisch. Auf Anfrage hat ein sehr hilfsbereiter Support-MA das selbst nochmal wiederholt, da ich dachte über den Support-Account ginge es schneller. Es hat zwar funktioniert, aber auch so lange gedauert, die DB ist offenbar sehr komplex. Aber dass er das gemacht hat, fand ich sehr entgegenkommend.
Der webgo-Support hat mir bei meinen Fragen und Problemchen sehr freundlich und kompetent geholfen, ich bin sehr positiv überrascht.
Die webgo-Admin-Oberfläche ist schon ok. Ich bin da durch jweiland nicht verwöhnt, im Gegenteil.
Auf meine Fragen hinsichtlich HTML2, Webmailer (Horde Probleme, dafür Roundcube) und PHP pro Domain erhielt ich ebenfalls die Antworten, dass Aktualisierungen für dieses Jahr in Planung seien, ein Termin aber unbestimmt. Hoffentlich verhaspeln die sich nicht. Die vollständige Datenlöschung (inkl. Backups) einiger Benutzer im Januar 2019 war offenbar auch ein Flüchtigkeitsfehler eines externen Mitarbeiters mit schlimmen Folgen.
Jetzt muss ich meine Backups machen und Domains transferieren.
Aufgrund der Antworten hier und der Erfahrungen der letzten Tage bleibe ich bei webgo und werde mir den Test bei All-Inkl ersparen. Der Cloud-Resolver stört mich nicht so sehr, ich wollte eben nur Abhängigkeiten von einer "externen" Dienstleistung vermeiden sowie externe Datentransfers minimieren (das wird ja auch als Hinweis beim Aktivieren des Cloud-Resolvers angezeigt).
Nochmals vielen Dank, frohes Schaffen!
Du kannst die composer updates ja auch lokal ausführen und dann am Server nur mehr ein composer install (via SSH oder Contao Manager).Zitat:
Zitat von bejoro
Danke Dir, aber ich habe keine Ahnung wie ich das machen sollte. Das geht über mein derzeitiges Wissen hinaus, da ich mich mit der Anwendung des composers bisher nicht beschäftigt habe.
Aber es ist gut zu wissen, dass es eine Möglichkeit gibt, sollte der Cloud-Resolver einmal nicht oder nicht mehr funktionieren.
Kann ich Deinen Vorschlag auch noch anwenden, jetzt da ich alles über den Contao-Manager installiert habe?
Führt Dein Vorschlag dazu, dass ich den Contao-Manager dann nicht mehr nutzen kann (z. B. zur Installation von Erweiterungen)?
Sorry, ich habe mich mit der Composer-Infrastruktur bei Contao noch nicht befasst, da fehlt mir der Überblick.
Edit:
Oh, meinst Du es so, dass ich ein lokales "Schattensystem" habe, erzeuge mir lokal im "Schattensystem" eine composer.json/composer.lock, die ich dann auf den Server übertrage und dort ein composer install ausführe?
JaZitat:
Zitat von bejoro
Nein ;)Zitat:
Zitat von bejoro
Genau. Im Idealfall hast du sowieso immer eine lokale Kopie der Website, um Änderungen und Updates testen zu können.Zitat:
Zitat von bejoro
Das ist cool! :)
Das werde ich einmal ausprobieren, wenn ich wieder etwas mehr Luft habe, sehr interessant!
Frage, OffTopic: Ist es hinsichtlich der Kompatibilität besser ein "Schattensystem" auf Linux-Basis (LAMP) aufzusetzen oder ist XAMPP unter Windows ebenfalls völlig ok?
Prinzipiell ist es egal. Du musst nur aufpassen, dass deine lokale Umgebung nicht zu sehr von der Server Umgebung abweicht, aufgrund der Abhängigkeiten. Bspw. sollte die PHP Version die selbe sein. Notfalls kannst du die Plattform Definition des Live Servers aber auch direkt in der composer.json eintragen.
Da hilft es vielleicht, ältere Daten zu löschen. Länger als 90 Tage würde ich sie nicht aufheben.Zitat:
Zitat von bejoro
Wow, 8 Stunden für 100 MB :eek: Hat der Supportmitarbeiter den Import der Datenbank nicht via Konsole gemacht? Ich habe gestern einen Dump einer Datenbank mit knapp 400 MB via mysqldump/mysql exportiert und anschließend wieder importiert, was jeweils vielleicht nur ca. 10 Sekunden gedauert hat.
Ja, ich muss die Piwik-DB einmal bereinigen. Ich dachte aber nicht, dass diese relativ kleine Piwik-DB so problematisch sein kann.
Der webgo-Support-MA hat das über die Shell aber innerhalb meines Accounts gemacht. Also genauso, wie ich es bei meinem ersten Versuch auch gemacht habe. Ich habe keine Ahnung, warum das so lange dauert. Aber der Import meiner relativ kleinen Conatao-DB mit 1,4 MB hat auch bestimmt über 20 Minuten gedauert. Der Dump hingegen geht relativ schnell, bei Piwik und Contao, nur ein paar Sekunden. Aber der Import dauert ewig. Ich verwende MySQL-DBs, da ich mir bei MariaDB hinsichtlich der Kompatibilität nicht sicher war. Vielleicht ginge es mit MariaDB schneller?
Krass. Also normal scheint mir das ja nicht zu sein. Können das auch andere bestätigen, dass das wirklich so lange dauert?Zitat:
Zitat von bejoro
Das wäre wichtig zu klären, um das ggf. zu reklamieren. Vielleicht stimmt ja etwas auf meinem Server/Account nicht.
Einen weiteren nicht so schönen Punkt bei webgo habe ich gerade entdeckt.
Beim Download von Backups per SFTP ist die Bandbreite auf 1,3 MiB/s begrenzt.
Bei jweiland hatte ich da immer meine vollen 50 Mbit/s.
Verschmerzbar, aber nicht so schön.
Nein, das sollte nicht mehr als ein paar Sekunden dauern, auch nicht per phpMyAdmin. Sind die 1.4MB komprimiert?
Die 1,4MB und die 100MB waren schon unkomprimiert, also reine sql-Text-Dumps.
So langsame Dateitransfers kenne ich weder bei Webgo noch sonstwo. Da stimmt was nicht.
Meinst Du den MySQL-Import oder den Download?Zitat:
Zitat von amateur
@all
Ich habe den Support angeschrieben. Wenn das jemand mit einem GoPlatin-Account testen könnte, wäre das natürlich perfekt, aber das kann ich nicht erwarten.
Es wäre nämlich nicht lustig, wenn eine Wiederherstellung meiner Installation einen ganzen Tag benötigt, nur weil der DB-Import so lahm ist. Vielleicht ist ja das GoPlatin-Paket aufgrund des günstigen Preises ja extrem beschnitten. Aber das ist nur Spekulation.
Also ich habe vorhin ein komplettes Backup eines Kundenwebspace runtergeladen. Ich habe es jetzt nicht auf die Kommastelle parat, aber der Download von 2.4 GB hat zwischen drei und vier Minuten gedauert. Also ca 10-13MB/Sekunde. Das ist auch ein Platin-Paket. Ach ne, Moment, das war Download über die Downloadfunktion der Backups. Du meinst sicher was anderes. Muss ich gerade mal probieren...
Hmm, gibt auch mehr als 10 MB/s per WinSCP und Protokoll SFTP. Das war aber eine große Datei, nicht viele kleine. Aber das hast du ja wahrscheinlich auch so gemacht. Viele kleine sind immer langsamer.
Lieben Dank, ich nutzte FileZilla mit SFTP. Ich habe gerade nochmal den Download über das Web-Interface angestoßen, auch nur 1,3 MB/s statt bei mir sonst 5,7 MB/s (VDSL 50 Mbit/s).
Aber der langsame DB-Import ist aus meiner Sicht noch viel kritischer. Vielleicht erhält man ja doch nicht durchgängig SSD-DBs? Oder mit meinem Paket stimmt etwas nicht. Alles sehr mysteriös und nicht gerade vertrauenerweckend. Aber ich will nicht überreagieren, vielleicht klärt es sich ja.
Ich würde den Support darauf ansprechen, das ist definitiv nicht normal. Notfalls sollen sie Dich auf einen anderen Server umziehen. Auf welchem bist Du denn?
Danke, ich habe den Support auf den SQL-Import und die niedrige Download-Bandbreite angesprochen. Ich bin gespannt, was der Support antwortet.
Ich bin auf Server S186.
Was geht denn hier ab! Ich habe gerade zwei Emails vom webgo-Support erhalten:
und kurz danach:Code:wir konnten Ihre Wunschdomain die-krebsis-sind-zu-besuch.de erfolgreich registrieren.
WICHTIG: Bitte beachten Sie, dass es bis zu 24 Stunden dauern kann, bis die Domain weltweit auf unsere Serversysteme zeigt.
10 Euro sparen?
Wenn Sie mit uns zufrieden sind, dann empfehlen Sie uns doch einfach weiter. Für jede erfolgreiche Empfehlung kassieren Sie und der Geworbene 10 Euro Bonus!
Alle Informationen zu der webgo Freundschaftswerbung finden Sie unter folgendem Link:
Edit:Code:es geht um Ihren Account mit der Kundennummer: xxxxx
Wir haben auf Ihren Wunsch hin die Domain die-krebsis-sind-zu-besuch.de in einen anderen Kundenaccount transferiert.
Die Domain befindet sich nun nicht mehr in Ihrem Account.
Für Fragen und Anregungen stehen wir Ihnen gerne zur Verfügung.
Senden Sie einfach eine E-Mail an:
Da wird einem schon schwindelig und man denkt an Account gehackt etc. Antwort vom Support:
Code:Bedauerlicherweise kam es zu einem Systemfehler, welcher eine Domainregistrierung, welche unter einer anderen Kundennummer vom System vorgenommen werden sollte, bei Ihrer Kundennummer passierte.
Dies haben wir dann korrigiert, sodass diese Domain nicht weiter mit Ihnen assoziert ist.
Wir entschuldigen uns für die entstandenen Unannehmlichkeiten.
Ich wünsche Ihnen noch ein ausgezeichnetes Wochenende.
Ok, auf S186 habe ich leider kein Hosting, also keine Chance den Download vom selben Server zu testen. Aber ich denke mal, der Server hat ein Problem. Hast du eventuell die Möglichkeit, irgendeine große Datei ohne vertrauliche Inhalte in einem übers Web zugänglichen Ordner zu legen, damit man sie per Browser und/oder wget runterladen kann?
Ich habe eine 500 MB Testdatei auf meinen Webspace hochgeladen. Den Link sende ich Dir per PN.Zitat:
Zitat von tab
Es wird noch schlimmer, wenn ich die Datei selbst herunterlade komme ich auf 500 bis 600 kB/s.
Geht bei mir deutlich schneller, vergleichbar zum anderen Platinpaket, also ca 10 MB/s, was auch halbwegs zu meiner 120 MBit Anbindung passt.
Ich habe sie auch mal von einem anderen Webspace per wget geladen:
Das entspricht dann in etwa der 1 GBit/s Anbindung des anderen Webspace.Code:Testdatei.dat 100%[=====================>] 500.00M 98.9MB/s in 5.7s
Also hast du wahrscheinlich eine schlechte Verbindung zu Webgo. Erklärt aber nicht diese langen Zeiten beim Datenbankimport?!?
Vielen Dank! Das ist schon sehr seltsam. Ich hatte noch nie solche Probleme mit meinem 50Mbit-Anschluss, ob Deutschland, USA etc. Aber daran kann ich wohl nichts ändern - unglaublich.
Gerade zum Test einfach bei VMWare einen Download für Workstation PRO 15 gestartet - 5,7 MB/s - so wie ich es kenne.
Ich habe den Backup-Download von webgo nochmals gestartet, jetzt sind es nur noch 500 bis 600 KB/s, das wird immer schlechter.
Ich verstehe es nicht.
Dein Internetanschluss kann ja durchaus völlig in Ordnung sein. Es reicht ja schon eine langsame Verbindung auf einer Teilstrecke von Dir zu Webgo bzw umgekehrt, wo genau das Problem liegt dürfte auch Webgo interessieren und es kann wahrscheinlich behoben werden. Das kann auch durchaus die Datenbank erklären, wenn Du den Dump direkt von deinem Rechner in phpMyAdmin hochgeladen hast.
Ich hoffe, das lässt sich klären, denn im Moment sind es nur noch 400 KB/s.
Ich habe die SQL-Dumps per SFTP auf den Server transferiert und per shell "mysql" eingespielt (so auch der Support-MA), daran kann es nicht liegen.
Außerdem würde eine phpmyadmin-Sitzung bei GoPlatin nur 140 Sekunden zulassen.
Bisher keine Reaktion vom Support.
Ich habe den DB-Import bei jweiland getestet.
3,7 MB Contao DB-Import (SSH, mysql): 6 Sekunden (webgo, bereinigte Contao-DB mit 1,4 MB: über 20 Minuten)
104 MB Piwik DB-Import (SSH, mysql): 113 Sekunden (webgo: über 8 Stunden)
Alles MySQL 5.6.
Wenn es dringend ist, würde ich den telefonischen Support oder den Live Chat probieren, keine Ahnung ob da jemand am Wochenende E-Mails oder Tickets bearbeitet. Diese Zeiten sind jedenfalls weit weg von akzeptabel. Muss dann eigentlich am MySQL-Server liegen oder an der SSD-Festplatte, denn von der "normalen" Festplatte lesen kann der Server ja wesentlich schneller. Sonst könnte er beim Download nicht fast 100 MB pro Sekunde schicken.
Nein, dringend ist es im Moment bei mir nicht. Es läuft ja jetzt alles. Nur der Piwik-Zugriff ist sehr langsam (Reports generieren).
Es entspricht eben nur nicht so ganz der Werbung mit 365 Tage Support.
Aber über die Reaktionszeiten unter der Woche (letzte Woche) kann ich mich nicht beklagen.
Ein DB-Import erfordert schon sehr viele HD-Zugriffe, deshalb sind normale Festplatten damit überfordert (hohe Latenz), aber für SSDs ist das normalerweise kein Problem. Ein rein sequenzielles Lesen einer großen Datei von einer konventionellen Festplatte oder von einem RAID ist natürlich heutzutage kein Problem. Und 100 MBit/s (ca. 11 MB/s) sind natürlich ein Witz für heutige HDs.
Ich halte Euch auf dem Laufenden. Aber ärgerlich ist das für einen Neukunden schon und gibt einem nicht gerade ein gutes Gefühl. Aber da hier doch einige zufriedene webgo-Kunden unterwegs sind, versuche ich mich ein wenig zu beruhigen.
Am Samstagabend erhielt ich eine Rückmeldung vom Support, dass meine Anfrage an eine entsprechende Abteitlung weitergeleitet wurde.
Nachdem ich bis jetzt keinerlei Rückmeldung erhielt, habe ich getestet.
Die Internetverbindung zu "meinem" Server S186 ist in Ordnung und es wird beim Download meine volle Bandbreite (50 Mbit/s, 5,6 KByte/s) unterstützt.
Der Import einer Contao4-SQL-Datenbank mit 2.028.894 Bytes dauerte jetzt 20 Sekunden (vorher 1,4 MB über 20 Minuten, jweiland 3,7 MB in 6 Sekunden).
Der Import einer Piwik-SQL-Datenbank mit 127.353.709 Bytes dauerte jetzt 363 Sekunden (vorher über 8 Stunden, jweiland 104 MB in 113 Sekunden).
Sind das akzeptable Werte?
Ich gehe deshalb davon aus, das die Probleme gelöst wurden. Leider habe ich keinerlei Rückmeldung erhalten.
Mag sein, dass es vielleicht noch besser gehen könnte, weiss ich jetzt nicht, kann es aber gern mal testen mit einer Contao 4 Datenbank per SSH. Ist aber doch zumindest erträglich im Vergleich zu vorher. Kommt vielleicht auch drauf an, wie das Setup bei jweiland ist. Ich könnte mir vorstellen, dass ein Datenbank-Import in einem shared hosting eventuell mit einem Datenbankserver schneller ist, der eben nicht auf dem gleichen Server liegt wie die ganzen Webhostings. Das kann sich dann aber für die "normalen" Datenbankzugriffe im Betrieb auch umkehren, weil nicht jeder Zugriff übers Intranet läuft, auch wenn das sicher sehr schnell ist. Der Preis des Hostings ist zwar kein sicherer Indikator für die Leistungsfähigkeit, aber es wäre zumindest möglich, dass bei jweiland einfach weniger Kunden auf einem Server sind und mehr CPU-Zeit für die Konsolenprozesse zur Verfügung steht und eventuell auch für die Bearbeitung von Requests. Das billigste Webhosting kostet ja bei jweiland immerhin ca 3x so viel wie das webgo Platinpaket.
Lieben Dank für Deine schnelle, ausführliche Antwort und Deine Einschätzung, sehr hilfreich.
Wenn alles so bleibt, dann kann ich gut damit leben.
Wenn Du magst und Luft hast, kannst Du ja einen Test-Import auf einem Deiner Platin-Pakete durchführen, es hat aber keine Eile. Interessant wäre es aber schon, ob da große Unterschiede zwischen verschiedenen Servern erkennbar sind.
Ich habe einige reservierte Domains. Auftrund der 11 inkludierten de-Domains im Platin-Paket kann ich zukünftig zusätzlich einiges sparen, gegnüber jweiland. Natürlich wäre der Luxus schön, alle Domains extern günstig zu hosten (z.B. do.de), um den Webhoster jederzeit schnell wechseln zu können, aber der Luxus hat eben auch seinen Preis.
Wenn die Leistung bei webgo/Platin so bleibt, wie es jetzt ist und sich nicht verschlechtert, dann ist es das optimale Paket für mich.
Kurzer Test ergab ca 22 Sekunden für den Import eines Dumps (C4-Datenbank) mit 5393511 Bytes in der Konsole.
Edit: Das waren MySQL-Datenbanken, kein MariaDB. Das geht immer noch nicht, weil ich das Ticket für den falschen Webspace abgesetzt hatte , meinen eigenen :rolleyes:. Naja, so komme wenigstens ich jetzt in den Genuss von Contao 4 mit MariaDB. Mache ich das selbe Spiel halt für den Kunden gelegentlich nochmal. Hat ja keine Eile, ich mache das Update erst mal mit der MySQL-Datenbank fertig. Naja, Update ist eigentlich ist schon fertig, ich muss aber auch noch ein kleines facelifting durchführen. :D
Die Pakete bei jweiland (DF) sind schon sehr auf Leistung getrimmt soweit ich das von früher weiss. Sind alle speziell zugeschnitten auf die Anforderungen von TYPO3, dass ist dann auch für Contao von Vorteil.
Ich denke für eine Typo3 Website braucht man im Normalbetrieb eher mehr Leistung und RAM als für Contao 4 bei einer vergleichbaren Seite. Echte Erfahrungs-/Messwerte habe ich da aber nicht. Dementsprechend werden die Pakete ausgelegt sein, was natürlich für jede andere Software auch kein Nachteil ist.
Herzlichen Dank. Das entspricht der Geschwindigkeit bei jweiland. Also habe ich bei meinem Paket/Server eine eher langsame Konfiguration erwischt.Zitat:
Zitat von tab
Meine Tests waren auch via SSH direkt in der Konsole (mysql).
Würdest Du das bei webgo reklamieren? Es ist immerhin noch mehr als die dreifache Zeit, die mein Server S186 benötigt.
Das kann ich nicht uneingeschränkt bestätigen, das war möglicherweise vor langer Zeit einmal so. Meine Website auf webgo reagiert wesentlich schneller (wesentlich geringere Ladezeiten), auch der Contao-Backend und der Piwik-Backend reagieren wesentlich flotter. Das kann natürlich mit der schnelleren und latenzärmeren webgo-Internet-Anbindung zusammenhängen. Vor langer Zeit hatte ich meine Website mit Typo3 umgesetzt (deshalb jweiland), aber das lässt sich jetzt natürlich nicht mehr vergleichen.Zitat:
Zitat von mlweb
Der Import-Test zeigt, dass webgo, wenn man den richtigen Server erwischt, genauso schnell beim DB-Zugriff ist.
Das kann man jetzt so nicht unbedingt sagen, ich bin mir da nicht sicher ob die Zeit einfach linear von der Größe des Dumps abhängt. Aber langsamer scheint es schon zu sein, also würde ich nochmal nachfragen mit diesen Webgo-internen Vergleichswerten. (S129)Zitat:
Zitat von bejoro
Ich habe am 02.04. nochmals an den Support geschrieben, dass andere GoPlatin-Server (S129) offenbar noch immer wesentlich flotter mit MySQL arbeiten als mein Server/Paket. Ich hatte höflich gefragt, ob man da noch etwas machen kann.
Leider habe ich bis heute wieder keinerlei Rückmeldung vom Support erhalten. Ich kenne die Gepflogenheiten diesbezüglich bei webgo noch nicht. Vielleicht ist keine Meldung auch eine gute Meldung.
Ich habe nochmals einen Test-Import (SSH, mysql) einer Conatao-DB durchgeführt und er läuft etwa 30% schneller als am 02.04. Ob das die "natürliche" Varianz des Servers ist oder ob der Support nochmal etwas optimiert hat, kann ich nicht sagen.
Da es nicht sichergestellt ist, dass ich z. B. bei All-Inkl besser fahre und die Pakete dort wieder andere Nachteile haben und aufgrund der hier geschilderten, insgesamt guten Erfahrungen mit webgo, werde ich dabei bleiben. Ich weiß jetzt, dass der webgo-Support insgesamt gut arbeitet und das GoPlatin-Paket für meine Anwendung gut geeignet ist.
Nochmals vielen herzlichen Dank an tab für seine Mühe und Unterstützung beim Testen, Spooky und an die anderen auskunftswilligen Forumsmitglieder für ihre Einschätzungen/Erfahrungen hinsichtlich webgo.
Meine Erfahrungen bisher: Wenn es um konkrete Dinge ging, wie letztens z.B. die Einstellung der MariaDBs zu ändern, war der Support immer relativ schnell. Rückmeldung dass es erledigt ist innerhalb von weniger als 24 Stunden. Im konkreten Fall mit der Bitte, es jetzt nochmal zu testen. Bei mehr allgemeinen Dingen, wo also nicht unbedingt sofort klar war was zu tun ist oder man eventuell Rücksprache mit Vorgesetzten halten musste, hat die Rückmeldung bisher auch schon mal 2-3 Tage gebraucht. Ich bin mir jetzt nicht ganz sicher, ob immer eine Rückmeldung kam, auch wenn die Behebung eines Problems offensichtlich war. Wenn ich Fragen gestellt habe, dann habe ich aber immer auch eine Antwort erhalten.Zitat:
Zitat von bejoro
Hallo,
ich habe vor ein paar Tagen eine neue Contao 4.4 Installation aufgesetzt.
Bis gestern auch allles gut gelaufen.
Dann habe ich eine favicon Erweiterung installiert und aufeinmal bringt er mir im Backend Imagick not installed und im Frontend ein Server Error (laut Logs auch imagick not installed)
Laut WebGo läuft imagick. und ich lade auch in der php.ini per "extension=imagick.so" die Erweiterung.
Aber irgendwie bringt er mir ab und zu den Fehler.
Habt ihr eine Idee?
Liegt es vielleicht an der Erweiterung (ma3xl3/contao-easy-favicon)?
Wie gesagt in der php.info finde ich das Modul Imagick auch nicht. Ist an die Technik von Webgo weitergeben, aber vielleicht habt ihr noch eine Idee?
Wenn in der phpinfo() Imagick nicht vorkommt, dann ist es auch nicht geladen. webgo muss das analysieren und beheben (wenn es denn geladen sein sollte).
Hi,
danke für deine schnelle Antwort.
WebGo hat nun einen SystemCheck gemacht und angeblich funktioniert es wieder. Wollen das aber intern noch sich anschauen, weil es kannnciht sein, dass ein Modul ab und zu abstürzt und nicht mehr richtig lädt.
Nach gut 15 Monaten mit Webgo und meiner Contao-Installation gestalten sich meine Erfahrungen mit diesem Hoster als sehr gemischt.
Das SQL-Server-Problem zu Beginn meines Vertrags (extrem langsamer Import von SQL-Dumps) wurde schnell gelöst.
Die ersten etwa 7 Monate war alles zufriedenstellend. Ich brauchte praktisch keinen Support, alles lief einwandfrei und sehr schnell.
Aufgrund der Heimarbeit/Lock-Down wurde die Netzanbindung/Internetknoten bei Webgo überlastet. Meine Website hatte Ladezeiten von mehreren Minuten. Ich wurde vom Support an meinen VDSL-Provider verwiesen. Erst umfangreiche Diskussionen führten zu einer Intervention durch Webgo, da das Problem natürlich nicht auf meiner Seite zu suchen war, sondern durch die überlastete Webgo-Internet-Anbindung verursacht wurde.
Seit 8 Monaten wird mir bei einer mittlerweile auftretenden extrem langsamen SFTP-Performance (extrem schwankend und instabil, nur 150 bis 600 KByte/s bei VDSL50-Leitung) nicht geholfen (bei Webgo nicht reproduzierbar), trotz hohen Test-Aufwands und Lösungsvorschlägen meinerseits. SFTP zu anderen Internet-Servern läuft problemlos. Ich hatte auch angeboten, gemeinsame Tests zu koordinieren, um das Problem nachzustellen, keine Reaktion.
Ich müsste den Server wechseln, was mir letzten Monat von der Beschwerde-Stelle angeboten wurde, was für mich viel Aufwand bedeutet (alle E-Mail-Konten auf allen Clients umstellen).
Letzte Woche habe ich nun zusätzlich eine extrem langsame und instabile HTTPS-Performance festgestellt (Verbindungsabbruch beim Download, extrem langsam), Page Speed von 99 auf 84 gesunken.
E-Mail an Webgo, seit einer Woche keine Antwort.
Ich habe in einer einzigen E-Mail meinen Ärger bekundet (nicht unverschämt oder beleidigend, einfach verärgert und eine Lösung fordernd).
Seitdem scheint der Support für mich vollkommen eingeschlafen zu sein.
Das Angebot des Serverwechsels der Beschwerde-Stelle habe ich am Montag angenommen, bis heute keine Antwort.
Ich war vor Webgo 12 Jahre bei jweiland.net. Dort hatte ich nie irgendwelche Probleme und der Support war immer extrem kompetent und schnell, ich habe diesen aber keine 10 Mal in 12 Jahren benötigt.
Wenn ich aus Kostengründen nicht hätte wechseln müssen, ich wäre dort geblieben.
Man bekommt immer das, wofür man bezahlt, nehme ich an.
Im Prinzip ja. Was jweiland betrifft - kenne die auch sehr gut - dort kommen die höheren Kosten m.E. vor allem deshalb zu Stande, weil sie neben Ihren normalen Leistungen einigen speziellen Service für TYPO3 Installationen bieten. Für Contao braucht man das halt nicht. Deshalb bin ich dort irgendwann auch weg.Zitat:
Zitat von bejoro
Webgo war vor ein paar Jahren ein Super Hoster. Inzwischen sind sie das nicht mehr - vielleicht zu schnell zu groß geworden. Ich habe nur noch ein paar wenige Kunden dort. Ansonsten bin ich inzwischen mit vielen kleinen Kunden bei All-Inkl. Ansonsten ist Hostingwerk eine sehr gute Empfehlung.
Außer dass sich da irgendwie nicht viel tut habe ich da bisher keine Probleme. Mittlerweile habe ich sogar PHP 7.4, jetzt schon!! :D Gestern bemerkt.
Da muss ich jetzt eh mal meine Leichen (=Entwicklungsinstallationen) aus dem Keller räumen, damit ich umstellen kann auf 7.4. Die Kundeninstallationen machen auch keine Probleme, Mail funktioniert im Rahmen dessen, was ich bei Postfächern eines shared-Hosting erwarten würde. Ein Business-Mail Account ist es freilich nicht, aber das kann man für den Preis auch nicht erwarten. Geschwindigkeit der Websites werde ich künftig überwachen - falls ich mein hierzu vorgeseheneses Netcup-Hosting dazu bekomme, die Ausgaben eines Cronjobs in eine Logdatei zu schreiben. Aber das ist ein ganz anderes Thema :rolleyes:. Aber bei den ersten manuellen Testaufrufen meines Skripts hat sich Webgo geschwindigkeitsmäßig nicht so gut geschlagen wie erwartet. Ich schiebe es erst mal darauf, dass da noch PHP 7.2 verwendet wird, deswegen muss ich jetzt umstellen, damit alle getesteten Installation die selbe PHP-Version verwenden. Geht ja bei Webgo leider nur für alle Websites. Kunden werde ich dort jetzt aber nicht aktiv zu einem Wechsel überreden, jedenfalls solange es nicht schlimmer wird. Pagespeed einer Kundenseite ist gemäß dem Test soeben nach wie vor auf 100/100.
Spitzenreiter bei den ersten Testaurufen war allerdings - Hostingwerk (wer hätte es gedacht?) :D. Aber das Feld lag relativ dicht beisammen, auch Ionos.
Herzlichen Dank für die interessanten Antworten und die Empfehlungen. Ich muss sehen, ob ich mir einen Wechsel leisten kann.
Dann stehe ich offenbar nicht alleine mit meiner Beobachtung da, dass sich die technische Qualität und der Support bei Webgo, wenigstens in den letzten 8 Monaten, massiv verschlechtert haben.
Vielleicht wollen die mich auch nur loswerden, da ich mit dem günstigen Platin-Aktionspaket unterwegs bin und einige reservierte de-Inklusivdomains darüber laufen habe, keine Ahnung, aber ich erhalte offenbar keinen Support mehr. Ich musste einfach massiv Kosten sparen, da es schon einige Zeit nicht mehr so gut läuft, jetzt sowieso.
Ich werde mir All-Inkl und Hostingwerk näher ansehen, lieben Dank. Vielleicht muss ich doch wieder wechseln.
Wenn es am Geld hängt, kannst du auch mal netcup probieren. Auch da hast du 30 Tage Zufriedenheitsgarantie, eventuell mehr Inklusivdomains und Speicher als bei den anderen zum ähnlichen Preis oder auch günstiger. In letzter Zeit höre ich da aber auch so einige unzufriedene Kunden im Forum, deswegen mag ich das zumindest momentan nicht uneingeschränkt empfehlen. Contao läuft in meinen Paketen aber eigentlich recht gut. Vielleicht auch hier von Server zu Server unterschiedlich. Mail scheint momentan auch etwas problematisch zu sein. Erst wurde geklagt, dass kein Spam aussortiert wird, jetzt beklagen sie sich, dass zuviel Spam bzw wichtige Mails ausgefiltert werden. Ich nutze dort produktiv keine Mail, kann also nichts aus eigener Erfahrung dazu sagen. Mails von meinen anderen Mail-Accounts sind bisher immer angekommen.
Herzlichen Dank für den Vorschlag, aber Ärger habe ich jetzt schon genug.
Contao und E-Mail funktionieren ja auch bei Webgo.
Ich wollte mich ja auch mit dem SFTP-Performance-Problem arrangieren, aber nachdem jetzt auch noch die HTTPS-Übertragung schwer beeinträchtigt, mein PageSpeed so stark gesunken ist und der Webgo-Support sich offenbar nicht mehr um diese Probleme kümmert, mache ich mir schon Sorgen. Das ist schon ein starkes Stück.
Nachdem ich auf meine wiederholten (sachlichen) Support-Anfragen und der Annahme des Angebots für einen Serverwechsel keine Antworten mehr erhalte, werde ich Webgo wohl verlassen müssen. Die Inklusivdomains haben aus meiner Sicht einen Nachteil, sie machen einen schnellen Hosterwechsel schwieriger.
Moderation: Hostingwerk spezifische Fragen in einen eigenen Thread ausgelagert.
Mein Umzug von webgo zu Hostingwerk ist abgeschlossen.
Nochmals lieben Dank an @mlweb und @tab für diese Empfehlung!
Im Moment sieht es so aus, dass webgo mich gemäß Sonderkündigungsrecht "Zufriendeheitsgarantie" aus dem Vertrag lässt und mir den letzen Rechnungsbetrag zurückerstattet. Ich hoffe die machen nicht noch irgendwelche Schwierigkeiten.
Ich bin sehr zufrieden mit Hostingwerk, sehr schneller Server (hoffentlich bleibt das so), sehr gut durchdachte Verwaltung (wenn auch einfach gehalten) und schneller (sehr geduldiger) Support durch Herrn Feyer, kein Vergleich mit webgo.
DB-Imports laufen um den Faktor 30 schneller bei Hostingwerk als bei meinem webgo-Server, obwohl der schon vom Support dahingehend optimiert wurde, da z. B. ein Contao-Import mehrere Stunden gedauert hat, jetzt Minuten und bei Hostingwerk Sekunden.
Aufgrund meiner Performance-Probleme bei webgo mit SFTP, HTTPS und der Interneranbindung seitens webgo habe ich mir ein Python-Script geschrieben, welches seit Monaten auf meinem lokalen Server läuft und eine Datei mit 5 MB herunterlädt, einmal von einem Server in den USA (als Vergleich, Laststpitzen, Anbindungsabhängig) und von meiner Website. Zu den Zeiten hoher Internet-Last aufgrund Corona, dauerte ein Download einer Datei mit 5 MB teilweis mehrere Minuten, webgo hat dann bei der Telekom eine Erweiterung des Netzknotens veranlasst, dann war es besser, trotzdem gibt es noch immer Zeitbereiche, in denen sehr hohe Antwortzeiten auftreten.
Ich habe einmal ein Diagramm eines Ausschnitts beigefügt, man sieht eindeutig, wann ich von webgo auf Hostingwerk umgeschaltet habe.
Das ist schon heftig und zeigt die Probleme, die webgo bei der Anbindung hat.