Ankündigung

Einklappen
Keine Ankündigung bisher.

Verschiebung der Einstellung alter PHP-Versionen & Info zur neuen Webserverplattform

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Zitat von Kabinenkoffer Beitrag anzeigen
    Guten Tag zusammen,
    ich habe bisher nicht verstanden warum ich den Tarif überhaupt wechseln soll? Eine Gegenüberstellung wäre hier sicher sinnvoll. Geht es nur um etwas mehr Webspace und einen schnelleren Prozessor?
    Wenn dafür Funktionen wie z.B. individuelle Einstellungen auf dem Server nicht mehr möglich sind und alles 20-30 Euro mehr kostet macht das alles wenig Sinn für mich. Gibt es eine Testmöglichkeit für
    Bestandskunden? Eine Art Probeumzug mit der Möglichkeit des Abbruchs nach einigen Tagen? Ich finde die Informationen sehr dürftig und schaue mir das alles vielleicht in 1-2 Jahren nochmals an :-)
    Viele Grüße
    Das bisherige Image, was auf den Servern läuft, ist in die Jahre gekommen und die Weiterentwicklung dessen ist in vielen Punkten nicht mehr gut möglich. Beispielsweise MySQL kann nicht weiter mit neueren Versionen bedient werden.

    Klar, lieb gewonnene Möglichkeiten geben wir auch nicht gerne auf, mussten aber Kompromisse bei der Neuentwicklung eingehen. Es werden hier sicher in den nächsten Monaten und Jahren noch Änderungen und Verbesserungen kommen, es geht aber leider nur nach und nach.

    Sie können natürlich einen neuen Tarif/Server einfach zusätzlich buchen und testen. Über die Geld-zurück-Garantie können Sie 60 Tage risikofrei testen. Bei Nichtgefallen erhalten Sie Tarifpreis und Einrichtungsgebühr zurück. Das gilt auch bei Tarifwechseln. Lediglich ausgenommen sind Zusatzleistungen wie Domains, SSL-Zertifikate sowie Sucuri Website Security. Technisch wird ein Rückwechsel aber leider problematisch und sicher auch aus Aufwandsgründen bei Ihnen intern nicht sinnvoll.

    Das Einstiegsposting in diesen Thread hier zeigt Unterschiede der Tarife recht umfangreich auf. Dies wurde auch noch aktualisiert in den letzten Tagen.

    Mit freundlichen Grüßen

    Nils Dornblut
    Blog - Facebook - Twitter
    Communitybetreiber: domainfactory GmbH
    Impressum / Pflichtangaben

    Kommentar


      Zitat von gazzo Beitrag anzeigen

      Bad-News! Folgende Aussage erhielt ich soeben vom Support: TOP und PS wird es aktuell in den neuen Tarifen nicht geben. Ob und wann dies ggf. verfügbar sein wird, können wir aktuell nicht sagen.

      Sorry Nils Dornblut ! Aber einen dedizierten Server ohne Prozessüberwachung??? Konfuse Politik die DF da die letzte Zeit fährt.
      Das Thema wird, wie gerade geschrieben, intern diskutiert. Ich melde mich hier, wenn es Neuigkeiten gibt.

      Mit freundlichen Grüßen

      Nils Dornblut
      Blog - Facebook - Twitter
      Communitybetreiber: domainfactory GmbH
      Impressum / Pflichtangaben

      Kommentar


        Zitat von Nils Dornblut Beitrag anzeigen
        Inodes bei Managed Servern und Reseller Dedicated liegen bei 10 Millionen in der Standardeinstellung. Bei Bedarf erhöhen wir diese. Im Shared Hosting limitieren wir diese aktuell auf 1 Million um das System insgesamt stabil zu halten.
        Das ist bzw war nicht korrekt. (Wurde das nun angepasst?) Wir haben einen Managed Server und die Standardeinstellung liegt bei 1.000.000. Ebenso wie beim Shared Hosting. Steht auch so in den FAQ, wie mir vom Support gesagt wurde, was aber - da essentiell - in der Leistungsübersicht sinnvoller wäre!

        [edit]In der Tat wurden diese für uns zwar erweitert auf 20mio, aber ohne Prozessüberwachung per Script ist der Server für uns so nutzlos[/edit]

        Wir haben den Server wieder gekündigt. Greift dann die 60Tage-Rückerstattung nun automatisch?
        Zuletzt geändert von gazzo; 15.10.2020, 13:54.

        Kommentar


          Liebes DF-Team,

          nun ist die verschobene PHP-Umstellung so kurzfristig wie nie zuvor angekündigt worden. Krass, was Sie Ihren Kunden abverlangen.

          Zudem, wie Sie sicher verfolgt haben, ist es mit der Umstellung nicht getan, viele Applikationen (unter anderem meine) müssen auf eine neue Version gehievt werden, die wiederum weitere Voraussetzungen hat, wie in meinem Fall, eine neuere MySQL-Version.

          Wenn Sie die alten PHP-Versionen abschalten, ohne dass neue DB-Versionen zur Verfügung stehen, hört mein Forum auf zu funktionieren, ich werde es möglicherweise nicht einmal mehr updaten oder portieren können.

          Wie ist Ihr Zeitplan für die Einführung der neuen MySQL-Versionen (oder Alternativen) und wie stellen Sie sich die Lösung für die Migration und das Updaten der Kunden wie mich vor?

          Besten Gruß,

          Andreas

          Kommentar


            Zitat von AndreasW Beitrag anzeigen
            Wie ist Ihr Zeitplan für die Einführung der neuen MySQL-Versionen (oder Alternativen) und wie stellen Sie sich die Lösung für die Migration und das Updaten der Kunden wie mich vor?
            Ein Update von MySQL ist technisch leider nicht möglich. Unter anderem daher haben wir unsere neue Tarifgeneration der 64-Bit-Tarife eingeführt. Dort bieten wir mit MariaDB 10.4 eine aktuelle SQL-Version an. Der Tarifwechsel kann über das Kundenmenü erfolgen.

            Mit freundlichen Grüßen

            Nils Dornblut
            Blog - Facebook - Twitter
            Communitybetreiber: domainfactory GmbH
            Impressum / Pflichtangaben

            Kommentar


              Zitat von gazzo Beitrag anzeigen

              Das ist bzw war nicht korrekt. (Wurde das nun angepasst?) Wir haben einen Managed Server und die Standardeinstellung liegt bei 1.000.000. Ebenso wie beim Shared Hosting. Steht auch so in den FAQ, wie mir vom Support gesagt wurde, was aber - da essentiell - in der Leistungsübersicht sinnvoller wäre!
              Wir haben es entsprechend hier in den FAQ:

              https://www.df.eu/de/support/df-faq/...actory/#c24138

              Pro Quota können maximal 10.000.000 Dateien (inodes) angelegt werden.

              [edit]In der Tat wurden diese für uns zwar erweitert auf 20mio, aber ohne Prozessüberwachung per Script ist der Server für uns so nutzlos[/edit]
              Wie definiert sich für Sie Prozessüberwachung bzw. was wollen Sie damit machen/tun können?

              Wir haben den Server wieder gekündigt. Greift dann die 60Tage-Rückerstattung nun automatisch?
              Für diese Garantie wenden sie sich bitte über das Kundenmenü an uns. Automatisch greift diese nicht.

              Mit freundlichen Grüßen

              Nils Dornblut
              Blog - Facebook - Twitter
              Communitybetreiber: domainfactory GmbH
              Impressum / Pflichtangaben

              Kommentar


                Wir waren über 15 Jahre lang begeistere Fans von D)F. Leider wurde die letzten 2, 3 Jahre irgendwie der Zug verpasst! Schön das nun grundsätzlich was passiert! Es muss nur eben auch weiterhin sinnvoll und praktikabel bleiben. Ansonsten bleibt dann nur der Abschied.

                Zitat von Nils Dornblut Beitrag anzeigen
                Wie definiert sich für Sie Prozessüberwachung bzw. was wollen Sie damit machen/tun können?
                Wir nutzen Shopware-Shops! Diese sind mit der Warenwirtschaft (REST) verbunden. Ein "Backlog" Script sorgt dafür, dass Änderungen sequentiell abgearbeitet werden. Damit es nicht zur Überlast kommt. Dieses Shell-Script läuft quasi im Loop und ruft wiederkehrend ein PHP-Script auf. Das Script wiederum ist natürlich auf eine bestimmte Anzahl durchzuführender Operationen limitert. Das Script selbst kommt garnicht von uns, sondern wird so für die WaWi als "Connector" zur Verfügung gestellt.

                Nun sollte es aber nicht durch einen möglichen Mehrfachaufruf zu Kollisionen bei der Bearbeitung kommen. Es ist also essentiell, dass das Script nur einmal läuft. Sollte es zu einem Abbruch kommen, stellt ein Cron sicher, dass es wieder gestartet wird. Dazu muss der Cron aber ja wissen ob das Script noch aktiv ist. Wir schreiben also eine PID-File und können so ganz schlicht die Instanz prüfen. Also im Grunde ganz banale PID Überwachung, wie sie schon seit Jahrzehnten praktiziert wird. Dazu benötigt man ja nun zumindest "ps" oder alternativ "pgrep". "top" ist nur nice2have um schnell mal fehler, zombies usw zu finden.

                Anderes Beispiel: Wir nutzen für unsere Middleware PHP Scripte, die per REST Daten mit der WaWi in beide Richtungen syncen (Bestellung holen, Artikelverfügbarkeiten schreiben usw.) ... Zwar könnte man hier theoretisch auch (je nach Progammieransatz) mehrere Scripte parallel laufen lassen, allerdings erhöht sich dadurch auch liniear der REST Zugriff. Die meisten API´s sind (zu Recht) zeitlich und in der Anzahl der Calls limitiert. Ein Script z.B. mit 100 Anfragen alle 5 Minuten, bedeutet bei doppelter Ausführung eben 200 Anfragen, bei 3-facher 300 usw. Durch die Limitierung "bremst" man sich wieder selbst aus, da die Schnittstelle geblockt wird bis wieder Kontingent frei wird. Da die Shops und die Middleware mit der WaWi kommunizieren, ist eine Kontrolle hier unerlässlich! (Siehe oben ...) Dafür hat man ja schließlich einen eigenen Server mit SSH Zugriff.

                Zumindest "ps" ist also bei vielen Anwendern (z.B. Shopbetreibern) unerlässlich. Ohne ist der Server schlicht unbrauchbar.

                Nach einigen Überlegungen haben wir uns, für unsere Shops, nun mittlerweile für einen anderen Hoster mit dedizierter Hardware, vollem Root-Zugriff, deutschem Server-Standort und dennoch gemanaged entschieden. Preis-/Leistung ist dabei weiterhin kostant und vergleichbar. Wir behalten hier bei D)F erstmal noch die Maschine mit dem alten Tarif für die Middleware und hoffen, dass D)F hier in den neuen Tarifen schnellstmöglich nachbessert, so was wir irgendwann dann auch damit "in die Neuzeit" (MariaDB, usw) wechseln können. So wird das erstmal nix!

                Kommentar


                  Zitat von gazzo Beitrag anzeigen
                  Wir waren über 15 Jahre lang begeistere Fans von D)F. Leider wurde die letzten 2, 3 Jahre irgendwie der Zug verpasst! Schön das nun grundsätzlich was passiert! Es muss nur eben auch weiterhin sinnvoll und praktikabel bleiben. Ansonsten bleibt dann nur der Abschied.
                  Soweit verständlich und vielen Dank, dass Sie sich die Zeit für diese ausführlichen Worte nehmen. Wir sind beim neuen Image sehr aktiv und möchten gerne Verbesserungen vornehmen.


                  Zitat von gazzo Beitrag anzeigen
                  Wir nutzen Shopware-Shops! Diese sind mit der Warenwirtschaft (REST) verbunden. Ein "Backlog" Script sorgt dafür, dass Änderungen sequentiell abgearbeitet werden. Damit es nicht zur Überlast kommt. Dieses Shell-Script läuft quasi im Loop und ruft wiederkehrend ein PHP-Script auf. Das Script wiederum ist natürlich auf eine bestimmte Anzahl durchzuführender Operationen limitert. Das Script selbst kommt garnicht von uns, sondern wird so für die WaWi als "Connector" zur Verfügung gestellt.

                  Nun sollte es aber nicht durch einen möglichen Mehrfachaufruf zu Kollisionen bei der Bearbeitung kommen. Es ist also essentiell, dass das Script nur einmal läuft. Sollte es zu einem Abbruch kommen, stellt ein Cron sicher, dass es wieder gestartet wird. Dazu muss der Cron aber ja wissen ob das Script noch aktiv ist. Wir schreiben also eine PID-File und können so ganz schlicht die Instanz prüfen. Also im Grunde ganz banale PID Überwachung, wie sie schon seit Jahrzehnten praktiziert wird. Dazu benötigt man ja nun zumindest "ps" oder alternativ "pgrep". "top" ist nur nice2have um schnell mal fehler, zombies usw zu finden.

                  Anderes Beispiel: Wir nutzen für unsere Middleware PHP Scripte, die per REST Daten mit der WaWi in beide Richtungen syncen (Bestellung holen, Artikelverfügbarkeiten schreiben usw.) ... Zwar könnte man hier theoretisch auch (je nach Progammieransatz) mehrere Scripte parallel laufen lassen, allerdings erhöht sich dadurch auch liniear der REST Zugriff. Die meisten API´s sind (zu Recht) zeitlich und in der Anzahl der Calls limitiert. Ein Script z.B. mit 100 Anfragen alle 5 Minuten, bedeutet bei doppelter Ausführung eben 200 Anfragen, bei 3-facher 300 usw. Durch die Limitierung "bremst" man sich wieder selbst aus, da die Schnittstelle geblockt wird bis wieder Kontingent frei wird. Da die Shops und die Middleware mit der WaWi kommunizieren, ist eine Kontrolle hier unerlässlich! (Siehe oben ...) Dafür hat man ja schließlich einen eigenen Server mit SSH Zugriff.

                  Zumindest "ps" ist also bei vielen Anwendern (z.B. Shopbetreibern) unerlässlich. Ohne ist der Server schlicht unbrauchbar.
                  Danke für die Worte. Ich gebe das an entsprechende Stellen und wir werden es diskutieren. Antwort diesbezüglich werde ich dann hier natürlich teilen.

                  Zitat von gazzo Beitrag anzeigen
                  Nach einigen Überlegungen haben wir uns, für unsere Shops, nun mittlerweile für einen anderen Hoster mit dedizierter Hardware, vollem Root-Zugriff, deutschem Server-Standort und dennoch gemanaged entschieden. Preis-/Leistung ist dabei weiterhin kostant und vergleichbar. Wir behalten hier bei D)F erstmal noch die Maschine mit dem alten Tarif für die Middleware und hoffen, dass D)F hier in den neuen Tarifen schnellstmöglich nachbessert, so was wir irgendwann dann auch damit "in die Neuzeit" (MariaDB, usw) wechseln können. So wird das erstmal nix!
                  Wie gesagt, danke für die offenen Worte und wir werden schauen, was wir zukünftig, aber dennoch zeitnah davon erfüllen können.

                  Mit freundlichen Grüße

                  Nils Dornblut
                  Blog - Facebook - Twitter
                  Communitybetreiber: domainfactory GmbH
                  Impressum / Pflichtangaben

                  Kommentar

                  Lädt...
                  X