Das längste Thema

  • Sollen die Router von netcup hellsehen?

    sag es 2mal, und auch andere Router können wie aus dem Nichts auf einmal hellsehen;

    nennt sich dann MMRTP (MIster Merlin Routing Protokoll) :D


    ich hatte vor rund 1-2 Wochen bei mir im LAN beim IPv6 etwas geändert (IPv6 ist bei mir nach wie vor nur via 6in4-Tunnel erreichbar)

    und siehe da, auf einmal ist forum.netcup.de ohne komischer Krücke¹ auch über IPv6 erreichbar;

    sogar ping6 forum.netcup.de geht ohne Probleme :)


    ¹ ip6tables -t mangle -A FORWARD -i br0 -o sit1 -d 2a03:4000:35:8e2::95 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1421:1536 -j TCPMSS --set-mss 1420

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • "NEUEN PC KAUFEN". Folge ich dem Link, komme ich tatsächlich in den Shop von HP, also meinem Hersteller

    Grundgütiger. Also ich habe ja auch schon viel gesehen, aber das sprengt echt jeden Rahmen... mir fällt dazu gerade spontan nur ein Wort ein: pervers.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Zu spät, nutze schon andere. Aber immerhin wurde es anscheinend mal als (schon seit viele Monaten bestehendes) Problem erkannt...

    Betreibe auch schon seit Ewigkeiten meine eigenen Nameserver und nutze nicht mehr die von netcup.

    Ich habe aber trotzdem Hoffnung, dass es dann weniger Posts zu dem Thema hier im Forum geben wird... ^^

    VPS 500 G8 Plus | VPS Karneval 2020 | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Like 1
  • Gibt es den Netcup-Support eigentlich noch ?


    Ich habe ein Ticket (NCSUP-16205), wo ich seit letzte Woche Mittwoch auf Rückmeldung warte.

    (Server hat stellenweise so hohe IO-Latenz, das er nicht mehr reagiert - Migration angefragt)


    Ein anderes Ticket (NCSUP-18208), ist ebenfalls noch nicht gelöst.

    Ein Server (192.168.0.20) kann einen anderen Server (192.168.0.40) über VLAN nicht erreichen.

    Bei einem anderer Server (192.168.0.10) funktioniert es ohne Probleme.


    Beide Server liegen in einem Account mit Service Level A+ (Sofortige Reaktionszeit bei einer Störung)


    Und die Beschwerdestelle ist nun auch weg :(

  • Und die Beschwerdestelle ist nun auch weg :(

    Echt? =O

    Man kann ein Ticket nicht mehr eskalieren?

    DAS wäre eine echte Verschlechterung. :thumbdown::thumbdown:

    Nach meiner Erfahrung hatte nämlich der First-Level-Support nicht immer die ausreichende Kompetenz, um meine Anfrage zu bearbeiten (oder überhaupt zu verstehen ;) ), die Beschwerdestelle hat mich dann aber bisher immer zufrieden gestellt.

  • Echt? =O

    Man kann ein Ticket nicht mehr eskalieren?

    DAS wäre eine echte Verschlechterung. :thumbdown::thumbdown:

    Nach meiner Erfahrung hatte nämlich der First-Level-Support nicht immer die ausreichende Kompetenz, um meine Anfrage zu bearbeiten (oder überhaupt zu verstehen ;) ), die Beschwerdestelle hat mich dann aber bisher immer zufrieden gestellt.

    Oha. Den Support werde ich demnächst vielleicht auch mal wieder in Anspruch nehmen müssen. Ich bin auf ein Phänomen gestossen, das ich mir nicht erklären kann. Dass es die Beschwerdestelle nicht mehr gibt finde ich einigermassen alarmierend und auch die (Nicht-)Reaktionszeiten, von denen hier berichtet wird. Ich hoffe, das ist dem Personalmangel geschuldet oder jetzt einfach anders geregelt, dass es vielleicht nach mehreren Antworten automatisch eskaliert wird oder nach welchen Regeln auch immer.


    Aber nun zu meinem aktuellen Problem. Vielleicht weiss ja auch hier jemand was darüber. Seit kurzem bin ich nun auch Kunde beim Webhoster S, dem zigfachen Service-Weltmeister mit der dicken Weltkugel in der Fernsehwerbung. Ich habe da ein Aktionsangebot wahrgenommen, weil ein Kunde von S mit einem Auftrag gedroht hat, ich mit S noch überhaupt keine Erfahrungswerte hatte und ich deshalb einfach vorab Erfahrungen aus erster Hand mit S Shared Webhostings sammeln wollte, um ein böses Erwachen am Projektende auszuschliessen. Auch im Hinblick auf mögliche zukünftige Anfragen von S-Kunden.


    Meine schlimmste Befürchtung, dass mein CMS dort vielleicht nicht installierbar oder lauffähig sein würde, war schnell ausgeräumt. Ich hatte aber schon öfter Erfahrungen anderer mitbekommen, nach denen die Webhostings von S nicht unbedingt ein Ausbund an Schnelligkeit seien und insbesondere die Datenbanken sehr langsam. Das nahm ich dann zum Anlass, um das einmal selbst zu überprüfen.


    Ich habe zu diesem Zweck die selbe Website jetzt auf 4 verschiedenen Webhostings installiert, inklusive dem bei S und einem von netcup. Zusätzlich als Referenz noch auf einem größeren netcup Rootserver. Auf Caching habe ich hier komplett verzichtet, weil mich nicht die Zugriffszeiten auf den Cache interessieren, die nicht viel mit der tatsächliechen Performance des Webhostings zu tun haben, sondern die Zeiten für die Erzeugung des HTML. Vorab habe ich mir auf die Schnelle einfach mal die Ergebnisse von Google Pagespeed angeschaut, die Ergebnisse waren zwar teilweise etwas überraschend für mich, aber nachvollziehbar. Das Paket von S war jedenfalls der Verlierer. Alle anderen, inklusive netcup RS und Webhosting 4000, schienen relativ nahe beisammen zu liegen.


    Nun wollte ich diesen ersten Eindruck mit ein paar eigenen Zahlen untermauern. Ich habe ein PHP-Skrikt erstellt, das die 5 URLs per curl runterlädt und die URL, TTFB und die Zeit bis das HTML runtergeladen ist, in eine Datei protokolliert. Diese Skript habe ich dann von einem anderen RS aus per Cronjob alle 10 Minuten aufgerufen. Und hier ist das netcup Webhosting plötzlich sehr langsam, langsamer als es eigentlich sein kann. Teilweise 6-7 Sekunden bis zum ersten Byte, selten mal unter 2 Sekunden. Einzelne Ausreisser allerdings bis unter 0,5 Sekunden. S dümpelt so bei 2-3 Sekunden rum, die anderen beiden Webhostingpakete streuen zwischen 0,18 und 0,6 Sekunden. Der RS streut so um die 0,1 Sekunden, hat aber auch einen Vorteil bei der Verbindung zum aufrufenden RS.


    Alle Werte, bis auf die des netcup Webhosting 4000, sind für mich schlüssig und nachvollziehbar. Aber wie entstehen die langsamen Zeiten des Webhosting 4000? Ich würde ja sagen, vielleicht ist es einfach so langsam. Aber wo bekommt dann Google Pagespeed die 0,4 Sekunden für "First Contentful Paint" und "Time to Interactive" her? Hier streuen zwar die Zeiten auch etwas, aber >2 Sekunden kommen schlicht nicht vor. Kennen die eine Abkürzung? Oder rufen die eventuell mehrfach auf, was die Ladezeit kürzer machen könnte, weil dadurch der PHP Code des CMS im OPCache liegt? ?(;) (Die letzte Idee kam mir jetzt beim Schreiben, das baue ich versuchshalber bei mir auch mal ein.) Oder kann es sein, dass netcup Zugriffe von Servern per curl (= Bots) irgendwie runterbremst und gewisse Server (Google ...) davon ausnimmt? Die anderen Webhoster im Test tun das offenbar nicht, möglicherweise eventuell noch S, aber die anderen beiden jedenfalls nicht. Mein RS offensichtlich auch nicht :D.

  • Teilweise 6-7 Sekunden bis zum ersten Byte, selten mal unter 2 Sekunden. Einzelne Ausreisser allerdings bis unter 0,5 Sekunden. S dümpelt so bei 2-3 Sekunden rum, die anderen beiden Webhostingpakete streuen zwischen 0,18 und 0,6 Sekunden. Der RS streut so um die 0,1 Sekunden, hat aber auch einen Vorteil bei der Verbindung zum aufrufenden RS.


    Ich koennte da komplett falsch liegen, aber bei solchen Zeiten habe ich immer als erstes die DNS-Aufloesung im Verdacht. Als zweites einen Fallback von IPv6 auf IPv4.

  • Ich koennte da komplett falsch liegen, aber bei solchen Zeiten habe ich immer als erstes die DNS-Aufloesung im Verdacht. Als zweites einen Fallback von IPv6 auf IPv4.

    Hatte ich auch im Verdacht, aber dann habe ich mir die entsprechenden Zeiten angeschaut, unter anderem namelookup_time, connect_time pretransfer_time. Alle sehr kurz. IPv6 hatte ich auch im Verdacht und liess mir die IP-Adresse ausgeben. War tatsächlich eine IPv6. Dann habe ich IPv4 Auflösung fest eingestellt, danach hatte ich eine IPv4 in der Ausgabe und die Zeit hat sich nicht geändert. Mir fällt nichts Besseres mehr ein, als dass netcup da irgendwas anhand der IP und/oder dem User Agent verzögert. Vielleicht sollte ich um ganz sicherzugehen, dass es nicht an IPv6 liegt, mal eine externe Seite per IPv6 runterladen. Ich habe da leider nichts eigenes außer S. und meine netcup-Server. Habe jetzt die Beschränkung auf IPv4 wieder rausgenommen und suche mir mal ein paar Opfer zum Testen :D .


    Edit: wikipedia.org hat mich zugelassen per IPv6, TTFB 0,31 Sekunden. Auch google.com per IPv6, TTFB 0,08 Sekunden. Geht also auch schneller per IPv6 außerhalb des Netcup Netzwerks.

    Edited 2 times, last by tab ().

  • Ich habe ein Ticket (NCSUP-16205), wo ich seit letzte Woche Mittwoch auf Rückmeldung warte.

    (Server hat stellenweise so hohe IO-Latenz, das er nicht mehr reagiert - Migration angefragt)

    Vor ein paar Wochen hatte ich genau dieses Problem. Für ca. 2 Tage war die io Latenz so hoch, dass selbst ein ls teilweise Sekunden dauerte und alle Services hingen. Der support hat nach einem Tag nach einer Erklärung meiner Benchmarks gefragt und gesagt, dass die Anfrage weitergeleitet wird (Zu dieser Zeit war die Geschwindigkeit aber schon wieder normal). Dann kam die Erklärung, dass der Server eine Defekte HDD hatte und einen Raid rebuild gemacht hat.

    Eine Informations-Email wäre natürlich super gewesen, aber der support hat relativ schnell geantwortet obwohl ich kein besonderes Service Level habe.

  • Bei mir sieht es im Normalzustand auch relativ ähnlich aus (ein Grund warum ich zu einem Server mit SSD wechseln möchte):
    pasted-from-clipboard.png

    Durchschnittlich nur 1% iowait, aber bei jeder Last bremst die HDD aus.

    Ich habe jetzt auch mal die Latenz zum Logging hinzugefügt, um genauere Informationen zu sammeln.

    Hat dein Server auch noch eine HDD?


    Der Raid rebuild sah übrigens so aus und hat den Server komplett blockiert:
    pasted-from-clipboard.png

  • Weiss jemand warum der Support momentan solange dauert? Habe gestern geschrieben weil 2 ausgelaufene Server noch bei mir im SCP stehen, habe aber bis jetzt keinerlei Antwort erhalten. Nicht dass ich Ärger bekomme, weil die noch darin stehen.

  • Weiss jemand warum der Support momentan solange dauert?

    Ich tippe mal auf die Nachwirkungen von…

    Durch die kürzliche Umstellung auf das neue Ticketsystem bei uns kann es in wenigen Fällen noch zu längeren Bearbeitungszeiten kommen. Ich gehe davon aus, dass dies schon bald der Vergangenheit angehören wird.

  • Das ist ja auch schon wieder ein paar Wochen her. Das darf keine Ausrede Begründung mehr für zu lange Wartezeiten sein. Zumal meiner Erfahrung nach vor der Umstellung schon Reaktionszeiten von 24 Stunden Normalität waren, was nicht gerade schnell ist, vor allem im Vergleich mit anderen Hostern. Primäres Problem scheint mir eher eine personelle Unterbesetzung als eine Frage des Werkzeugs zu sein.