Webhoster Sammelthread

  • Ich persönlich rate von einem Managed Server bei Strato ab.

    Ich habe eben mit dem Kundensupport telefoniert. Die haben eine veraltete Datenbankversion im Einsatz und damit ist es nicht möglich, die aktuelle Woltlab Suite zu installieren. Sagte der Supportmitarbeiter auch.

    Schade!

  • So, hoste jetzt bei Kittmedia und kanns wirklich empfehlen, alle Performance und Serverfehler weg, herrlich! Der Umzug wurde vorgenommen und Preis Leistungsverhältnis ist super und der Support ist auch immer zeitnah, wenn Fragen da waren! :)

    Bist du du, oder bist du jemand anders 👀

    Ich kann Kittmedia empfehlen :thumbup:

    Wir sind mit einem größeren Projekt seit einigen Jahren bei Kittmedia.

    Ich steh' zwischen großen Bergen auf 'nem Felsvorsprung
    Blick' auf eine zusammenbrechende Weltordnung
    Ich kam grad noch weg, schon
    Beginnt in jedem Winkel der Welt da draußen das Armageddon 😵‍💫

    Edited once, last by Hundiiiiiiiiii (July 19, 2022 at 3:55 PM).

  • Ich persönlich rate von einem Managed Server bei Strato ab.

    Ich habe eben mit dem Kundensupport telefoniert. Die haben eine veraltete Datenbankversion im Einsatz und damit ist es nicht möglich, die aktuelle Woltlab Suite zu installieren. Sagte der Supportmitarbeiter auch.

    Schade!

    Strato war noch nie gut was webhosting angeht die server sind da alle falsch eingestellt und sorgen für fehler ich bin seit jahren bei einen kleinen hoster und dort hatte ich nie fehler was wbb angeht bei strato immer

    Der Kluge lernt aus allem und von jedem der Normale aus seinen Erfahrungen und der Dumme weiß alles besser.

    Viele Menschen im Internet sind, mehr Schein als Sein!

  • Kenn deren aktuelle Produkte nicht, war aber vor zwei Jahren mal Kunde. Damals vServer, war sehr zufrieden damit. Haben ein selbst entwickeltes Control Panel "cloudpit" für die Server. Bei dem Webhosting wird es Plesk sein. Fallen mit Expansion, Aufkäufen auf. Verwenden Plesk, sind da auch sehr engagiert. Geschäftsführer sehr cooler Typ, Mitarbeiter ebenso sehr korrekt. Arbeitsklima dort scheint sehr gut zu sein, was sich dann natürlich auch auf den Kundensupport übertragt. Haben mir mal einen Job angeboten, kam mir alles sehr solide rüber.

    https://www.dogado.de/firma/experten die hier abgebildeten Personen existieren tatsächlich.

    Würde vorschlagen denen einfach mal ne Mail zu schreiben mit deinen Anforderungen, kannst ja mal nach einem Test-Account fragen. Was "aktuell" in deinem Kontext bedeutet, ist mir leider nicht bekannt. Kannst du die Anforderungen konkretisieren? Plesk ist ja technisch in der Regel auf einem guten Stand, deren Hostsysteme liefen damals schon mit SSD, könnte jetzt ggf. auch schon was schnelleres sein, haben IPv6, ein WCF konnte ich da auch gut betreiben.

    Bin vor ein paar Tagen dahin gewechselt leider lässt sich die opcache reset Einstellung nicht aktivieren. Hätte ich das eher gewusst. Naja ansonsten macht der Anbieter einen guten Eindruck und Support sehr korrekt.

  • Hallo,

    Das ist Inkompetenz bei der Server-Konfiguration in Reinform. Effektiv bedeutet dies, dass mehr parallele PHP-Prozesse erlaubt sind, als gleichzeitige Verbindungen zur Datenbank. Jede Request verwendet eine eigene Datenbankverbindung und beendet diese am Ende wieder. Wenn aber die Limits fehlerhaft konfiguriert sind, kommt es zu dieser Fehlermeldung.

    laut webgo-Support handle es sich hierbei um keine Fehlkonfiguration, sondern um eine bewusste Einschränkung aus Sicherheitsgründen:

    Antwort des webgo-Support

    „Es ist tatsächlich so, dass es eine Einschränkung von 15 gleichzeitigen Zugriffen von einem Benutzerkonto auf die MySQL Datenbanken gibt. Dies ist kein Fehler in der Konfiguration sondern ist aus Sicherheitsgründen beabsichtigt.


    Probleme entstehen meist, wenn dasselbe Benutzerkonto für den Zugriff auf mehrere Datenbanken verwenden wird und Sie können dies vermeiden in dem Sie für Ihre Datenbanken in Ihrem webgo Webspace Admin Nebenbenutzer für Ihre Datenbanken anlegen.


    Lassen Sie den Zugriff von einer Webseite auf die jeweilige Datenbank immer über das Nutzerkonto der Nebenbenutzer laufen. So vermeiden Sie eine Sicherheitssperre durch zu viele gleichzeitige Zugriffe eines Nutzers.“

    Nein, das ist bei einigen Hostern normal. Es muss halt unglaublich kompliziert sein, zwei effektiv zusammengehörige Werte auf denselben Wert zu setzen. Das Limit der SQL-Verbindungen muss größer oder gleich der Anzahl an parallel erlaubten PHP-Requests sein, sonst hat man bei ein bisschen mehr Traffic sofort diese Fehlermeldung.

    Auch das sieht der webgo-Support anders und gibt – nach meinem Verständnis – als Erklärung an, dass nicht jede PHP-Anfrage eine Datenbankverbindung erfordere:

    Antwort des webgo-Support

    „Nicht jeder PHP Prozess ist eine Datenbankanfrage. Um das Beispiel eines Obstkorbs zu wählen: Die Anzahl der Bananen darin muss nicht gleich der Anzahl der Trauben sein, auch nicht wenn beide in die Kategorie Obst fallen.


    Ein Punkt auf den ich noch einmal hinweisen möchte ist, dass für jede Datenbank in der webgo Webspace Admin Nebenbenutzer angelegt werden und jeder Nebenbenutzer hat sein eigenes Limit von 15 gleichzeitigen Verbindungen.“

    Was hältst du von deren Argumentation?

  • Was hältst du von deren Argumentation?

    Mit der Argumentation kann man auch ein Auto mit 4 Sitzen verkaufen, aber nur 3 Sitze einbauen, weil sich ja vielleicht nicht jeder Mensch im Auto hinsetzen möchte. Eventuell geht man davon aus, dass dieser einen Obstkorb dabei hat, um sich darauf zu setzen? Polster werden eh überbewertet.

    Übrigens hat sich in die Nachricht vom Support ein Fehler eingeschlichen. Es wurde versehentlich „aus Sicherheitsgründen“ statt „zum Geld sparen durch Begrenzung der nutzbaren Ressourcen“ geschrieben (*). Kein Problem, das passiert auch den Besten.

    (Achtung: Die beiden vorherigen Absätze können eine ungesunde Menge an Sarkasmus enthalten.)


    Bei 15 maximalen Datenbankverbindungen hätte man auch einfach den Webserver so konfigurieren können, dass maximal 15 parallele (!) PHP-Anfragen verarbeitet werden können. Es ist wirklich so einfach.


    (*) Es spricht absolut nichts dagegen, Ressourcen-Limits festzulegen, das macht jeder so, einschließlich wir. Es ist aber einfach nur unsinnig, sich Konfigurationen auszudenken, bei denen man von vorne herein weiß (oder wissen müsste!), dass diese Probleme verursachen wird. Und dann „Sicherheitsgründe“ vorzuschieben ist dann doch ziemlich seltsam, wenn offenbar gleichzeitig bei der Anzahl paralleler PHP-Anfragen deutlich mehr drin ist – das passt einfach nicht zur Argumentation.

  • Wenn man von statischen Inhalten oder zumindest von Anwendungen ausgeht die ohne DB auskommen mag das stimmen. Aber das ist ja sicher die absolute Minderheit der PHP-Anwendungen.

    Uzimaster
    --------------------------------------------
    Si vis pacem, para bellum

  • Vermutlich teilen sich viele Anbieter dasselbe Cheat-Sheet.

    Dass ein PHP-Prozess nicht zwangsläufig eine Datenbankverbindung erzwingt ist völlig unerheblich. Dann wird der Worker eben "schneller" wieder frei und es wurde keine Datenbankverbindung geöffnet. Bis auf den Fakt, dass ggf. "mehr" Anfragen verarbeitet werden können ändert sich nichts, denn der PHP-Worker wird sowieso eingesetzt.

    Oft kommt dann noch die Aussage, dass ein PHP-Prozess anders herum auch mehr als eine Verbindung öffnen kann (2022, auf die selbe DB?), oder, dass "PHP die Datenbankverbindung nicht immer korrekt schließen kann und diese erst in ein Timeout laufen muss". Dann kann man aber auch einfach etwas mehr (dem Sparplan entsprechend) Datenbankverbindungen als PHP-Anfragen erlauben um einen Puffer für Anwendungen aus dem letzten Jahrhundert zu schaffen oder seine wilden Behauptungen zu untermauern, dass Datenbankverbindungen nach Zerstörung des DBO-Objekts existieren könnten. Es kann zwar immer mal ein Fehler mit einer Datenbankverbindung auftreten, aber dann ergibt der Fehler zumindest einen Sinn und wird nicht mutwillig provoziert.

  • Danke für eure Antworten.

    Da ich mich bezüglich dieses Themas kaum auskenne, frage ich mich nun, ob von Webhosting-Angeboten, bei denen der Webserver so konfiguriert wurde, lieber Abstand genommen werden sollte, wenn darauf die WoltLab Suite – womöglich sogar in mehreren Projekten – eingesetzt werden soll?

  • Hallo,

    [Zitat durch mich modifiziert]

    Da ich mich bezüglich dieses Themas kaum auskenne, frage ich mich nun, ob von Webhosting-Angeboten, bei denen der Webserver so konfiguriert wurde, lieber Abstand genommen werden sollte, wenn darauf die WoltLab Suite – womöglich sogar in mehreren Projekten – eingesetzt werden soll?

    Das ist kein Problem speziell mit WoltLab Suite. Der Fehler kann genau so mit WordPress, Joomla, XenForo, vBulletin oder jeder anderen PHP-Software, die die Datenbank nutzt auftreten.

  • Alles klar, dann werde ich mich weiter umschauen.

    Meine Freundin ist jetzt auch bei Kittmedia von Webgo, Webgo ist einfach furchtbar. Wirklich.

    Weshalb findest du webgo so furchtbar? Nur wegen des zuvor diskutierten Themas oder gibt es noch andere Gründe?

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!