Edge vs. Chrome als Browser in ASP

[#1]

Moin zusammen,

wir haben auf unserem ASP auch Chrome installiert und ich nutze den Browser schon immer als Standard. Heute ist mal wieder eine Beschwerdelawine bzgl. der Performance von ASP (wir sind vor ca. 1,5 Jahren gewechselt und unser alter (6 Jahre) Server war tatsächlich schneller) losgetreten worden. Deshalb haben wird uns die CPU Auslastung ein wenig mehr angesehen. Frappierend war, dass die Nutzung von Edge die CPU extrem belastet hat (Auslastung beim Öffnen oder Aufrufen von Google Maps 100% über einen gefühlt ziemlich langen Zeitraum) und in den Sitzungen neben dem Browser kein anderes Programm parallel aufgerufen werden konnte.  

Spannend ist, dass ich in Chrome auf dem gleichen Server in ASP das Problem zwar auch, aber deutlich weniger ausgeprägt habe.

Gibt es Erfahrungen dazu?

Schöne Grüße aus dem Norden

[#2]

Wird denn der Google Chrome dann auch in einem M365 Konto synchronisiert? 

[#3]

Beide werden nicht synchronisiert.

[#4]

Was ist es denn dann für asp? DATEVasp? Ich bin happy, dass im PARTNERasp der megra der MS Edge mit dem M365 Konto verbunden ist, Passwörter gespeichert werden und man auch lokal 1:1 die gleichen Daten zur Verfügung hat und den Browser mittels GPO verwalten kann, wobei das mit Chrome auch geht. 

[#5]

Datev ASP. M365 Synchronisierung im Browser ist bei uns einfach kein Thema, da keiner von uns lokal arbeitet. Outlook reicht.

[#6]

Dann lasst doch durch DATEV den Google Chrome als Standardbrowser setzen? Ich verstehe das Problem dann nicht.  

[#7]

Machen wir gerade selbst. Das Problem ist eher, dass das massive Auswirkungen in der Performance zu haben scheint (werden wir in den kommenden Tagen beobachten) und uns niemand von der Datev sagt, dass dort ein Problem ist. Die Kollegen im Lohn z.B. sitzen so ziemlich den ganzen Tag in der Personalakte und sind maximal genervt, wie langsam das Arbeiten damit ist. Sollte das tatsächlich durch den Browser besser werden, ist es schon blöd, dass das nicht kommuniziert wird.

[#8]

---

@nordlicht schrieb:

Machen wir gerade selbst.

---

Ein jeder Mitarbeiter für sich allein? 😱  Und neue Mitarbeiter müssen dann auch dran denken? OK. 

---

@nordlicht schrieb:

Das Problem ist eher, dass das massive Auswirkungen in der Performance zu haben scheint (werden wir in den kommenden Tagen beobachten) und uns niemand von der Datev sagt, dass dort ein Problem ist.

---

Mir ist nichts dergleichen zu Ohren gekommen. Kommt sicher auch auf die Anzahl User vs. Anzahl Kerne an. 

---

@nordlicht schrieb:

Sollte das tatsächlich durch den Browser besser werden, ist es schon blöd, dass das nicht kommuniziert wird.

---

Weil es bei anderen ggf. genau umgekehrt ist? Aber wenn's für Euch passt, ist doch OK.

[#9]

Moin Nordlicht

Was wirklich Amok läuft habt ihr also nicht herausgefunden.

Eine geratene Abhilfe kann dann nur zufällig funktionieren.

Zumal Sie schreiben, dass auch Chrome viel CPU-Ressourcen brauchte.

Ich bin kein Freund von Edge, aber im Grunde ist es ein Chrome mit anderer GUI (Schnittstelle zum Nutzer).

D.h., es werden wohl alle Chromium-basierten Browser da ein Problem haben. Ausweichen ginge nur auf Firefox oder Safari. Kann man versuchen (zumindest Firefox) aber das wäre bei mir nicht die erste Wahl der Lösungssuche.

OK, meine Erfahrung, kann also ein schlechter Hinweis sein:

Solche "Amok-Läufe" bei einem Browser geschehen i.d.R. wenn Javascript involviert ist. Sprich, dort ein Programmfehler dafür sorgt, dass viele Ressourcen genutzt werden.

Javascript ausschalten, wäre dann eine gute Maßnahme, was aber oft (so auch bei Google Maps) nicht geht.

Was ich auch schon erlebt habe: Zu wenig Arbeitsspeicher. Windows ist dann wie doof am Paging. Prüfen Sie mal, wie hoch die Auslastung des Arbeitsspeichers ist.

Und wenn Sie dabei sind, beobachten Sie auch, wie die CPU-Last ohne Browser sich entwickelt.

Auch Festplattenbeanspruchung und Netzwerkauslastung sind einen Blick wert. Sprich, mal anschauen was der Task-Manager so liefert.

Was mir im Augenblick so einfällt.

QJ

[#10]

Google Maps und Co sind allerdings auch nicht die optimalsten Kandidaten, um auf Terminalservern "massiv" genutzt zu werden. (Mit Citrix _könnte_ man jetzt noch entsprechende Seiten per Browser Content Redirection lokal "wiedergeben" lassen, was ich mir (als Betreiber) in einem DATEVasp / PARTNERasp allerdings nicht ans Bein binden würde.)

Wer mag, kann ja mal mit den Fishbowls spielen 😉 : 

• HTML5 Fish Bowl (eucscore.com) (Startet mit 10 Fischen)
• WebGL Aquarium (webglsamples.org) (Startet mit 500 Fischen)

[#11]

2000 Fische bei mir ohne Probleme lokal am Laptop mit i5-1335U 😀! Danke für den Tipp @janm. Bestätigt meine Meinung, dass die Zukunft wohl nicht ThinClient Billig-CPUs heißen wird. 

[#12]

Moin quantenjoe,

ist leider nicht so einfach rauszufinden was genau das Problem sein könnte. Auf den ASP Servern der Datev ist vieles wie z.B. perfmon für uns gesperrt, d.h. alles was über Taskmanager hinausgeht ist dicht.

Hat uns auch gewundert, dass Edge und Chrom sich so unterschiedlich verhalten. Beim tatsächlichen Arbeiten in Datev z.B. in der Personalakte ist heute allerdings kein riesiger Geschwindigkeitsgewinn zu merken.

CPU ohne Browser ist eher unauffällig, Arbeitsspeicher ist in der Regel bei ca. 75%.

[#13]

Moin Janm,

"Google Maps und Co sind allerdings auch nicht die optimalsten Kandidaten, um auf Terminalservern "massiv" genutzt zu werden."

Da wird sich die Datev mit ASP aber drauf einstellen müssen. Sie selbst zieht mehr in die Cloud und auf den Terminalservern werden wir eben immer mehr die Cloud auf den Servern nutzen. Irgendwann wird es dann kippen und die Terminalserver werden wegfallen. 

[#14]

Jetzt müsste "die Cloud" nur noch etwas genauer definiert werden.

Wenn tatsächlich größerer Bedarf an grafikintensiven Workloads für DATEVasp / PARTNERasp da wäre, würde es sicherlich bereits Lösungen geben. Für eine Handvoll Kunden wird "den ganzen Aufwand" sicherlich keiner betreiben bzw. wollen die Kunden "den Aufwand" dann sicherlich (jetzt) auch noch nicht bezahlen.

Wenn grafikintensive Workloads bereits jetzt für eine Kanzlei ein Must-Have sind, dann ist DATEVasp / PARTNERasp derzeit die falsche Lösung zur Anforderung.

---

@nordlicht  schrieb:

Irgendwann wird es dann kippen und die Terminalserver werden wegfallen. 

---

Das denke ich nicht. Auch wenn später mal "alles" im Browser läuft, haben so verwaltete Terminalserver / VDIs in einem vernünftigen Serverraum / Rechenzentrum durchaus noch Vorteile.

[#15]

Moin Nordlicht,

Arbeitsspeicher bei 75% ist wirklich eher unauffällig.

Die Sperren wie perfmon sind natürlich auch nicht hilfreich Sprich: Ist Mist für uns Anwender.

Ich tippe jetzt mehr auf den Browser als das Problem. Vielleicht einmal alle gespeicherten Browserdaten löschen? So dass alles in den Webseiten wieder bei Null anfangen muss.

Mehr fällt mir gerade nicht ein

QJ

[#16]

Moin quantenjoe,

probieren wir mal aus. Haben wir früher auf unseren eigenen TS regelmäßig zentral gemacht und auf ASP nicht.