Performanceunterschied bei Webanwendungen zwischen "interner" und "externer" Anfrage

[DerLord]

Performanceunterschied bei Webanwendungen zwischen "interner" und "externer" Anfrage

Moin zusammen,

ich habe soeben ein Phänomen festgestellt, welches ich mir so spontan (noch) nicht erklären kann.

Ich habe den Plex Server auf dem NAS (RS815+) installiert und sitze gerade an meinem Desktop-PC. Jetzt rufe ich die Webanwendung vom Plex auf und lasse mir zB alle FIlme (ca. 270) im Plakat-Modus anzeigen, d.h. es werden die originalen Cover dargestellt. Hole ich mir die Seite lokal per NASort rödelt er gut und gerne 1-2 Minuten bis alle aufgebaut sind. Hole ich mir die gleiche Seite per plex.mydomain.de (nginx Reverse Proxy, TLS-verschlüsselt per LE) ist alles auf Knopfdruck auf dem Bildschirm. Beides ist beliebig reproduzierbar, sprich es ändert sich auch bei wiederholtem Seitenaufbau rein gar nichts. Laut erster (Kurz)-Analyse holt er sich aber in beiden Fällen nichts aus dem Browsercache, sondern holt jedes einzelne Cover immer wieder neu ab.
Die "externe" Lösung geht sowas von geschmeidig von der Hand, die "interne" dagegen fühlt sich etwas übertrieben dargestellt eher wie ein 56k-Modem an. Obwohl beides auf der selben Maschine läuft und es dieselbe Webanwendung ist, beides sollte über nginx laufen. Das Ziel ist ebenfalls das selbe, nur der Weg scheint sich irgendwo zu unterscheiden. Cached nginx als Reverse Proxy mehr oder besser als als Webserver? Wenn ja macht es so einen Unterschied aus, obwohl Inhalt, Quell- und Ziel-Rechner identisch sind?

Hat jemand eine Idee, wie es dazu kommen oder besser noch wie man das korrigieren kann?

Oder kann es sein, dass doch noch der Apache verwendet wird? Woran kann man es erkennen?
Bei der "externen" Anfragte bekomme ich im HTTP-Header(Antwort) ein zusätzliches Feld mit Server=nginx zurück, Bei der internen gibt das ganze Feld erst gar nicht.

Nachtrag:
es betrifft auch andere Anwendungen. Seit dem Upgrade auf DSM 6 kam mir auch die WebGUI vom NAS sehr träge vor, vom ersten Tag an. U.a. deswegen habe ich ja gestern auch den RAM auf 16GB erweitert. Alles baut sich erst langsam und sehr mühevoll auf. Ein Klick auf die Systemsteuerung bringt eine Wartezeit von 20-40s mit sich, danach baut sich jedes einzelne Icon erst mal nach und nach auf. Soeben testweise ausprobiert und verglichen: Eine "externe" Anfrage vom gleichen Rechner über meine Domäne hat hier den gleichen Effekt -> alles rasend schnell.

Grüße
DerLord

 

[tschortsch]

Hat der Reverse Proxy einen aktivierten Cache?
Bei der Webanwendung werden diese wohl immer frisch erstellt, beim zugriff über den Proxy könnten die doch aus dem Proxy Cache kommen.

 

[DerLord]

Ja, was mich dabei aber sehr verwundert, ist die Tatsache, dass der selbe Dienst auf der selben Maschine eine Anfrage von dem selben Client aus Performance-Sicht so dermaßen unterschiedlich aufbereitet. Da liegt schon eine kleine Welt dazwischen.

Beispiel DSM WebGUI.
Die scheint serienmäßig über nginx zu laufen, es wird ja auch ein Serverblock in der nginx.conf generiert. Dennoch wird die Anfrage des Login-Screens(!) über meine Domäne und eigener config in 1,7s vollständig übergeben, die "interne" Anfrage per generierter config benötigt dagegen fast 21s(!). Wie gesagt hier beides über nginx und jeweils mit leerem Browsercache.

"intern"
Anhang anzeigen 29703

"extern"
Anhang anzeigen 29704


Irgendetwas läuft da im Standard falsch...


/edit
Chrome ist auch hier etwas schneller, aber es steht immer noch 1,6s zu 18,6s

 

[tschortsch]

Die Anhänge kann man nicht öffenen.

Da ist definitv was falsch.
Bei mir ist der Loginscreen nach maximal 5s da und ich hab keinen Proxy laufen.

Vieleicht hast du dir durch das herumkonfigurieren irgendwo ein Ei gelegt.

Hier findest du wahrscheinlich mehr zur Konfiguration http://www.synology-forum.de/showthread.html?73345-DSM-6-Reverse-Proxy&goto=newpost

 

[DerLord]

Komisch, gestern waren die Anhänge noch da, hier sind sie noch mal (von gestern):

"intern"


"extern"



Viel "herumkonfiguriert" habe ich nicht. Also, über die DSM WebGUI habe ich gar nichts eingestellt, außer den Backend unter Webstation auf nginx. Sonst ist alles in diese Richtung auf default. Ich mag es nicht so gerne, sich etwas "zusammen zu klickern", auch wenn es erst mal easy erscheint. Aber man weiß halt ohne große Recherche nicht, was macht diese GUI-Funktion >genau<. Legst du selber configs an, ohne die originalen anzupacken, hast du immer einen besseren Überblick über die Änderungen und kannst diese natürlich auch besser nachvollziehen, sichern und später wiederherstellen.
Deshalb habe ich den Reverse Proxy ausschließlich durch eigene configfiles umgesetzt. Wenn ich diese entferne und den Dienst neustarte, ändert sich von der Laufzeit her gar nichts.

Heute sieht es so aus:
intern ~17s, mit Borwsercache 2,7s
extern 1,7s mit Browsercache 0,85s

Mit und ohne eigene configs (also System-Default) sind es jeweils nahezu identische Werte.

Deine 5s sind ein >hinnehmbarer< Wert, aber dennoch ist er mMn für einen Loginscreen(!) sehr sehr hoch. Nimm mal einen Browser, den du nicht im Alltag verwendest und leere mal den Cache. Achte darauf, ob er wirklich alles neu herunterlädt oder sich aus dem Cache bedient. Ich denke, dass du die WebGUI nicht zum ersten Mal aufgerufen hast. Wenn 5s schon der Wert mit Browsercache ist, liegt er sogar noch doppelt so hoch wie meiner.

In privaten Umgebungen mag das hupe sein, da man eh per default einen großzügigen Cache aktiviert hat. Aber ist man viel beruflich unterwegs, wo der Cache komplett deaktiviert ist, ist es schon etwas nervenaufreibender ;-)

Wie gesagt, es ist mir erst so krass seit dem Update von DSM 5.2 auf 6.0 aufgefallen. Vorher lief alles sehr zügig. Und die vHosts hatte ich vorher auch schon.


PS: Danke für den Link, aber die configs dort sind von mir ;-)

 

[tschortsch]

Hab jetzt nochmal die nachgeschaut wie lange der Zugriff wirklich dauert wenn der Cache leer ist.
Firefox nehm ich standartmäßig < 2 Sekunden
Edge (nach wegklicken des Sicherheitshinweises wegen des Zertifikats) < 2 Sekunden.

Oh, na ich hab nicht so genau auf den Usernamen geachtet der die Configs hineingestellt hat
Hab den Thread nur interessiert mitgelesen.
Da kann ich dir keine weitereren Hineweise geben da du von der Materie sowieso mehr Ahnung hast

 

[DerLord]

Laut deiner Signatur hast du DSM 5.2, ist das in deinem Testfall noch aktuell? Wie gesagt bei mir lief es unter 5.2 auch noch alles sehr zügig, die Probs kamen (zeitlich) erst mit 6.0

 

[tschortsch]

Ja ist aktuell.

Selbst bei meiner DS209+ mit DSM4.2 ist der Login nach spätestens 3 Sekunden da.

 

[DerLord]

OK; dann hinkt der Vergleich. Bei meiner Rack mit DSM 5.2 lief es auch noch subba. Wie gesagt, ist erst seit 6.0 so...
Ob es an dem Update selbst liegt oder sich zeitgleich eine Änderung meinerseits eingeschlichen hat, weiß ich nicht. Aber in der WebGUI mache ich idR nichts. Und alle Änderungen an configs protokolliere ich. Da ist nichts auffälliges dabei.

Hat sonst noch jemand das Problem unter DSM 6.0?