• SwissSign: geplante Downtime: Klick

  • Willkommen im neuen Forum.

    Solltet ihr "Social Media Login" im alten Forum genutzt haben, macht bitte ein Passwort Reset mit der damals benutzten E-Mail Adresse eures Social Media Kontos. Solltet das nicht funktionieren, dann schaut hier bitte rein: KLICK

  • NSP Forum als App inkl. Push Nachrichten (iOS): Klick

[Gelöst] code.jquery.com langsam

SBW

Well-known member
Hallo NSP-Team,
wir nutzen das Modul LargeFiles für den sicheren Transport von großen Datenmengen (100MB <-> 10GB). Funktioniert seit langem zuverlässig und lässt bisher keine Wünsche offen.

Seit knapp zwei Wochen erreichen uns von externen Partner als auch intern das selbe Problem:
Das Laden von der enQSig Seite dauert in unregelmäßigen, regelmäßigen Abständen bis zu 30 Sekunden.

Gestern Morgen war ich selbst davon betroffen. In den Entwicklertools (F12) des Browsers konnte man sehen, dass code.jquery.com 21 Sekunden benötige, um die Dateien https://code.jquery.com/jquery-2.2.0.min.js und https://code.jquery.com/ui/1.11.4/jquery-ui.min.js auszuliefern. Schließt man den Browser und öffnet das Webportal enQsig erneut, ist der Ladevorgang pfeilschnell (505ms).

Nachdem wir 21 bzw. ohne mich 20 Rückmeldungen erhalten habe, muss bei jQeruy, CDN Provider, Carrier o.ä. was im Argen sein. Die betroffenen waren so kooperativ und haben uns ihre ISP genannt:
Unitymedia Business (BW), Unitymedia Privat (NRW), EWE Business, TeleData FN, Telekom MagentaZuhause, Telekom DeutschlandLAN IP, Telekom DeutschlandLAN Connect IP (DCIP) , Telekom Business Premier Access (BPA) und M-net.

Kurz um: Ist es denkbar die beiden Dateien wieder in die Installation des Webportals zu integrieren, damit die Abhängigkeit Dritter verschwindet?


Schönes Wochenende!
Daniel
 
Hallo zusammen,
inzwischen hat sich die Situation wieder verbessert.

Allerdings "schmeckt" (heißt bei uns Schwabenland so) mir Abhängigkeit nicht so ganz.
Ist es denkbar jQuery in Large Files zu intergrieren?


/Daniel
 
Hallo zusammen,
seid gestern häufen sich diesbezüglich die Beschwerden wieder bei uns. Primär gibt es wohl Probleme bei Unitymedia/Vodafone.
Gibt es seitens Produkt Management oder Entwicklung bereits Überlegungen dazu?


Gruß,
Daniel
 
Hallo Daniel,

vielen Dank, für die Informationen und das du uns damit auf dem laufenden hältst.
Wir möchten in der Zukunft das WebPortal generell umstrukturieren und dabei ist unser Ziel möglichst auch auf externe Komponenten wie jQuery zu verzichten.

Dies ist zwar keine Ad-Hoc Lösung für den Moment aber eine Lichtblick für die Zukunft.

Gruß,
Jan
 
Guten Morgen Jan,
die beiden Meldungen sind die Spitze des Eisbergs (negativen Rückmeldungen innerhalb von 48 Stunden, mehr als 10 verschiedene Personen/Unternehmen).

Oh weh... Ich lese in einem Satz die magischen Worte "möchten, Zukunft, möglichst". Das bedeutet nach meiner Erfahrung, dass eine zeitnahe Umsetzung nicht erfolgen wird.
Ich sehe mehrere (zielführende) Optionen...

Quick & Dirty
Falls die externen Verweise im Klartext im Quellcode ersichtlich sind, darf die Entwicklung diese gerne nennen. Die Anpassung trau ich mir zu. :rolleyes:

Support
Falls die Priorität (auch unter Anwendung von Scrum) der Thematik an den dafür ausbleibenden Support Tickets liegt, kann ich ab sofort (fast wöchentlich) "Futter" liefern. Bloß was macht der NSP Support mit den Informationen? Vermutlich Schultern zucken und der Hinweis, dass in diesem Fall nichts unternommen werden kann. Es wäre aus meiner Sicht primär eine ABM für deine Kollegen - rein aus Statistikzwecken. Was gerade in der schweren Zeit dazu führen kann, dass andere, evtl. dringenden Support Tickets länger auf ihre Bearbeitung warten müssen.

Motivation
Falls es an der Motivation liegt, so kann ich natürlich gerne aktiv tätig werden. Wiederkehrende Probleme kratzen irgendwann an der Kundenzufriedenheit. Früher oder später habe ich deshalb graue Haare, was widerrum in meinem Alter (< 40) zu einem unausweichlichen Dialog mit meiner Frau führt. Wie das Gespräch ausgeht, kann der eine oder andere aus eigener Erfahrung sich vorstellen. :angel:

Hand auf Herz Jan, im Moment ist's relativ ruhig. Diese Woche bisher eine Person und das war gestern Abend gegen 18:48 Uhr (Vodafone, Hessen). Wenn der Schnitt in der Woche bei 3-4 Personen liegt und das konstant über die kommenden 5-6-7-8 Wochen, dann falle ich vom Stuhl. Da haben meine Kollegen vom Helpdesk irgendwann auch keinen Spaß mehr, wenn man sich wiederkehrend intern als auch extern rechtfertigen muss.


Gruß,
Dani
 
Daniel und ich habe ein wenig experimentiert und einen Workaround geschaffen um den NSP zu zwingen seine lokal mit gelieferten jquery Dateien zu nutzen.
Um das ganze für alle möglichst komfortabel zu halten habe wir vom NoSpamProxy uns auch dazu entschlossen das Verhalten vollständig zu ändern so dass code.jquery.com gar nicht mehr genutzt wird :)


Aktuell kann folgendes vorgehen gemacht werden:

Auf dem WebPortal muss die Datei "C:\Program Files\Net at Work Mail Gateway\enQsig Webportal\Views\Shared\_Layout.cshtml" editiert werden, dafür muss nicht einmal der IIS gestoppt werden.
Idealerweise wird die Datei vorweg einmal gesichert.


Dort findet man in Zeile 11 und 12:
<script src="//code.jquery.com/jquery-2.2.0.min.js" integrity="sha256-ihAoc6M/JPfrIiIeayPE9xjin4UWjsx2mjW/rtmxLM4= sha384-K+ctZQ+LL8q6tP7I94W+qzQsfRV2a+AfHIi9k8z8l9ggpc8X+Ytst4yBo/hH+8Fk sha512-pXR0JHbYm9+EGib6xR/w+uYs/u2V84ofPrBpkgLYyKvhZYJtUUvKSy1pgi8tJZAacsPwgf1kbhI4zwgu8OKOqA==" crossorigin="anonymous" type="text/javascript"></script>

<script src="//code.jquery.com/ui/1.11.4/jquery-ui.min.js" integrity="sha256-xNjb53/rY+WmG+4L6tTl9m6PpqknWZvRt0rO1SRnJzw= sha384-YWP9O4NjmcGo4oEJFXvvYSEzuHIvey+LbXkBNJ1Kd0yfugEZN9NCQNpRYBVC1RvA sha512-BHDCWLtdp0XpAFccP2NifCbJfYoYhsRSZOUM3KnAxy2b/Ay3Bn91frud+3A95brA4wDWV3yEOZrJqgV8aZRXUQ==" crossorigin="anonymous" type="text/javascript"></script>

Diese Zeilen löschen oder auskommentieren.


Gruß
Jan
 
Guten Abend Jan,
Um das ganze für alle möglichst komfortabel zu halten habe wir vom NoSpamProxy uns auch dazu entschlossen das Verhalten vollständig zu ändern so dass code.jquery.com gar nicht mehr genutzt wird
bis dato ist in aktuellen Version nach wie vor code.jquery.com eingebunden. Dies als Hinweis, da für mich nicht klar ist, ob das Verhalten bereits geändert sein sollte oder es noch auf der ToDo steht. Ich wende natürlich den bisherigen Workaround an. :)


Gruß,
Daniel
 
Hallo Daniel,

nein die Änderung ist noch nicht implementiert.
Aktuell ist auch noch keine Version mit der Änderung in Aussicht, aber es ist nicht in Vergessenheit geraten und steht weiterhin auf der ToDo Liste ;)
 
Guten Abend Jan,
lohnt es sich noch ein PowerShell Skript dazu zu schreiben oder ist eine Umsetzung absehbar?


Gruß,
Daniel
 
Hallo Daniel,

leider kann ich noch nichts zeitnäheres versprechen :/
Ein PowerShell Skript könnte dir somit erstmal das leben erleichtern.
Was ebenfalls gehen sollte und bei mir im Test geklappt hat ist das Anpassen der Berechtigungen auf die Layout Datei. (Screenshot hängt an)
Wir ändern eigentlich nicht viel aktuell am WebPortal und wenn dann mehr im Backend als im Frontend. Durch das Deny Recht kann der Installer die Datei nicht tauschen und alles sollte so bleiben wie zuvor ;) Der Installer ist in meinem Test daran auch nicht zusammengebrochen weshalb ich dir die Idee überhaupt erst vorschlage.


Eine Implementierung unserer Seits wäre zwar deutlich schöner aber hier nimmt die Arbeit einfach gar kein ende - was andererseits natürlich auch schön ist ;)


Gruß,
Jan
 

Anhänge

  • layout_permission.PNG
    layout_permission.PNG
    120.7 KB · Aufrufe: 5
Hallo Daniel,

leider keine guten Neugikeiten.
Die Änderung wurde planmäßig für ein Update nach dem Release 14 vorgesehen.
Das bedeutet, dass sich dies noch etwas ziehen wird :/


Gruß,
Jan
 
Hallo Jan,
hätte nicht gedacht das ein vermeidlich minimalinvasiver Eingriff fast zwei Jahre in Anspruch nehmen kann.
Können wir das Ganze mit einer süßlichen Kalorienbombe für die Entwicklung beleben?  :angel:


Gruß,
Daniel
 
Zurück
Oben