VNC Console ganz schön träge und lahm

  • Hi,


    also ich weiss nicht wie es bei euch ist aber bei mir ist die vnc console sowas von am laggen, kommt mir vor wie ein Steinzeit Rechner. Per RDP ist es schon ein wenig schneller aber auch nicht flüssig. ich habe andere vps anderer anbieter und da ist es nirgends so laggy.

  • ich habe nur den Windows defender.selbst wenn ich ihn ausschalte ziemlich lahm. Alleine die Windows Server Installation dauert schon fast 4h. Jetzt ist es soweit installiert nur er dümpelt seid 30minuten vor sich hin.


    Und wenn ich mal zur Passwort Abfrage komme um mich einzuloggen..dauert es fast 1minute bis er einen Buchstaben nimmt. Also irgendetwas kann doch da nicht richtig sein oder.

  • Hallo imbissbronko,

    auf welchem Server hast du denn dein Windows installiert?


    Um dein Problem einzugrenzen, wären folgende Informationen hilfreich:

    • Root-Server oder VPS?
    • Wie viel RAM?
    • Welche Windows-Version?
    • Welche Architektur? (64 oder 32 bit Windows)
    • Wie hoch ist der RAM/CPU Verbrauch im Taskmanager?


    Tritt das Problem auch auf, wenn du den vServer im Rettungsmodus startest?

    Oder tritt das Problem auch auf, wenn du von einer Linux Live-CD mit grafischer Oberfläche bootest?

    Falls ja, solltest du den Support kontaktieren.

  • Guten Morgen,


    die Erfahrung zeigt das langsame VNC-Konsolen in der Regel auf eine Firewall zurückzuführen sind, die den https-Traffic auspackt und analysiert. Das wurde ja bereits oben angedeutet.


    Wenn nur der Windows-Defender als einziger Schutz unter Windows genutzt wird, täte ich auch sicher stellen, dass der Arbeitsplatz nicht bereits infiziert ist. Wird eine vorgeschaltete Hardware-Firewall genutzt, kann auch diese die Funktionalität den VNC-Streams behindern, wenn diese den https-Traffic analysiert.


    Darüber hinaus ist es natürlich wichtig, dass die Internetanbindung zum SCP stabil ist, hier keine Wechsel der IPs stattfinden etc. Auch benötigt der Client ausreichend Hardware.


    Mit freundlichen Grüßen


    Felix Preuß

  • Please pardon my response in English- but it is my native tongue; my German is quite poor, having only a few months of learning in school many, many years ago :)


    The problem is that this VNC instance is really poorly written. Every keypress/etc is literally AJAXified through so it causes a full request/response, which is somewhat strange in implementation, causing very poor bounce detection. It would be nice if NetCup would allow a user to connect to their service with their own choice of VNC product- because Guac VNC is incredibly poor- even when I RDP'd into a nearby-neighbor at Hetz just to try to set a password with less aggravation.

    The rest of SCP seems to be well-written for most users; I had to do virtually nothing to figure how things were laid out and designed. It truly is a shame about Guac-VNC.

  • [..] It truly is a shame about Guac-VNC.

    Just adding a second opinion to your statements: Sometimes one key press is registered multiple times, resulting in me trying to delete the unnecessary characters. Problem is: also the delete key is registered multiple times.. ;) So i'm having a hard time typing passwords, i simply can't see if i have some double characters in them.

  • Sometimes one key press is registered multiple times, resulting in me trying to delete the unnecessary characters. Problem is: also the delete key is registered multiple times.. ;) So i'm having a hard time typing passwords.

    Das geht mir genauso. Ich nutze die VNC-Konsole, um die Festplatten von vServern beim Starten zu entschlüsseln. Die Passworteingabe ist unmöglich, da unvorhersehbar. Das geht mir mit verschiedenen Client-Systemen und -Browsern so. Ich weiß nicht, was ich tun soll, außer die On-Screen-Tastatur zu benutzen und einfacher einzugebende Passwörter zu wählen (--> schlechte Idee).

  • Das geht mir genauso. Ich nutze die VNC-Konsole, um die Festplatten von vServern beim Starten zu entschlüsseln. Die Passworteingabe ist unmöglich, da unvorhersehbar. Das geht mir mit verschiedenen Client-Systemen und -Browsern so. Ich weiß nicht, was ich tun soll, außer die On-Screen-Tastatur zu benutzen und einfacher einzugebende Passwörter zu wählen (--> schlechte Idee).

    Hatte Anfang dieses Jahr auch mal einen Server bei Netcup und das selbe Problem. Ich hab allerdings gedacht, dass ich es irgendwie selbst zu verantworten habe.

  • Hallo zusammen,


    muss diesen Thread nochmal hervorholen.


    Leider habe ich zeitweise nur die Möglichkeit über VCP auf meinen vServer zuzugreifen. ssh ist gesperrt. Leider ist die Bedienung darüber im Moment praktisch nicht möglich :(

    Tastendrücke werden mehrfach oder gar nicht erkannt. Wenn man viel auf der Konsole arbeitet und regelmäßig Befehlt mit <CTRL>- bzw <ALT>- benutzt, kommt es immer wieder dazu, dass diese Tasten "hängen" bleiben. Sprich, ein eingegebenes "a" wird als <CTRL>-a angenommen. Das gleiche mit <SHIFT>, <CAPS LOCK>, <ALT> usw.

    Von der Thematik mit dem Tastaturlayout (<AltGr> funktioniert schlicht nicht) ganz zu schweigen.


    Fazit: VCP ist im Moment nicht benutzbar.


    Frage an netcup: Wird sich hier irgend etwas ändern? Das Problem scheint je etliche Leute zu betreffen, die hinter (Firmen-)Firewalls, Proxies, Antiviren-Scannern etc. hängen. Diese sind aber in der Regel nicht vom Benutzer kontrollierbar. Der oft gehörte Hinweis, diese zu deaktivieren, führt also ins Leere.


    Gibt es eine Möglichkeit, dies in der Implementierung des Clients anzugehen?


    Viele Grüße,

    carbonarius

  • Guten Morgen,

    Zitat

    Frage an netcup: Wird sich hier irgend etwas ändern? Das Problem scheint je etliche Leute zu betreffen, die hinter (Firmen-)Firewalls, Proxies, Antiviren-Scannern etc. hängen. Diese sind aber in der Regel nicht vom Benutzer kontrollierbar. Der oft gehörte Hinweis, diese zu deaktivieren, führt also ins Leere.


    also bei uns und den meisten Kunden arbeitet die VNC-Console wie sie soll. Sie ist nicht als Ersatz für eine SSH-Session gedacht sondern für eine Erstinstallation von Betriebssystemen mit grafischer Oberfläche.


    Wenn ich das richtig sehe, gibt es einige Firewalls die Streams aufbrechen die via SSL verschlüsselt sind. Das führt dazu, dass Pakete von dem Client nicht mehr in Echtzeit verarbeitet werden können. Hier wäre der einzige Lösungsansatz vermutlich eine leistungsfähigere Firewall clientseitig einzusetzen oder keinen via SSL verschlüsselten Stream aufzubrechen.


    Was sollen wir hier anders machen können? Auf den Einsatz von SSL verzichten?


    Sie könnten alternativ versuchen selbst VNC an Ihrem Server freizugeben und dann über einen VNC-Client auf diesem zuzugreifen. Auch das ist allerdings nicht das Gelbe vom Ei und ist hoch unsicher, wenn es nicht richtig gemacht wird.



    Mit freundlichen Grüßen


    Felix Preuß

  • Danke für die schnelle Antwort!


    Verzicht auf SSL oder dergleichen kann natürlich nicht die Lösung sein. Ich bin mir aber nicht sicher, ob in meinem Fall der SSL Stream aufgebrochen wird? Das SSL-Zertifikat scheint jedenfalls in Ordnung zu sein (keine Firewall, die als MITM läuft).


    In dem Anwendungsfall, in dem ich auf VNC zurückgreifen muss, ist leider auch ein eigener VNC client nicht möglich. In dieser Situation ist alles außer http(s) gesperrt. Selbst ssh auf Port 80 zu betreiben funktioniert nicht.

    Hatte mal mit dem Gedanken gespielt, den Zugang über eine Web-Konsole (ajaxterm o.ä.) zu ermöglichen. Dabei habe ich aber keine Erfahrung bzgl. der Sicherheit eines solchen Zugriffs. Mein Bauchgefühl sagt, eher schlecht...


    Weiter oben im Thread beschreibt Benutzer "saffable",

    The problem is that this VNC instance is really poorly written. Every keypress/etc is literally AJAXified through so it causes a full request/response, which is somewhat strange in implementation, causing very poor bounce detection.

    dass die Implementierung etwas seltsam sei. Deshalb meine Frage, ob man hier eventuell ansetzen könnte?


    Aber so wie es aussieht, muss ich wohl mit der Situation leben :(

  • Guten Tag,



    vielen Dank für Ihre Rückmeldung!


    Zitat


    dass die Implementierung etwas seltsam sei. Deshalb meine Frage, ob man hier eventuell ansetzen könnte?


    Wir sind für Verbesserungsvorschläge offen. Aktuell wüsste ich nicht wie wir es schaffen sollten einen Tastendruck nicht direkt an den Server zu übermitteln. Auch jede Bewegung der Maus muss an den Server übermittelt werden. Ansonsten wäre das ja noch schlimmer?



    Mit freundlichen Grüßen


    Felix Preuß

  • Nun, wenn tatsächlich jeder Tastendruck per AJAX zum Server gesendet wird wäre es definitiv eine Verbesserung, dies per Websocket zu erledigen.


    Ich habe generell keine Probleme mit der VNC-Konsole im SCP, könnte mir aber auch nicht vorstellen, diese dauerhaft zur Serververwaltung zu nutzen. Dafür ist sie ja auch nicht gedacht.

  • Es lässt sich ganz gut arbeiten mit dem WebVNC. Einige Eingaben werden doppelt und dreifach getätigt.

    Ich habe zwei Server, bei denen der SSH Daemon nur bei Bedarf gestartet wird.


    Hinter einem Corporate Proxy wird das hingegen sehr unbrauchbar (TLS wird nicht aufgebrochen).

    Ich habe schon bei anderen KVM Hostern VNC nativ benutzt, die das direkt anbieten.

    (sehr gut wenn man gleichzeitig über KVM als kernelbased virtual machine und keyboard, video, mouse reden möchte...)

    Die hatten ein zentrales VNC-Gateway - jede VM hatte eine Portnummer auf dem Gateway. Authentifizierung mit Benutzer / Passphrase.


    Evtl. ist das ja auch ein Weg für Netcup die native VNC Verbindung auszuleiten und anzubieten.

  • Als ich meinen Server das erste Mal über die VNC Console einrichten musste, war das Problem eher die falsche Tastenbelegung. Aber auch die träge Übermittlung von Tastenanschlägen. Ich bin gerade aus Zufall auf noVNC gestoßen. Die machen es mit WebSockets: https://github.com/novnc/noVNC

    Ein bisschen getestet habe ich schon, da lief es flüssig, trotz schlechtem WLAN Empfang.


    Die Netcup Konsole war aber auch OK. Man könnte ja mal A/B Tests durchführen?

  • aNewUser Ich habe nicht getestet, wie es bei netcup im Detail läuft. Aber prinzipiell unterstützt das eingesetzte Guacamole ebenfalls WebSockets, wenn alles richtig konfiguriert wird.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)