Frame vs Include

[Kopp]

Hallo,

Ganz einfache Frage:
Was ist Serverlastiger? Ein PHP-"Haupt"-Script das per include() sagen wir mal 5-10 Seiteninhalte lädt oder stattdessen 5-10 HTML-Frames die den Inhalt "nachladen" (kleine PHP-"seiten")?

Zunächst war ich überzeugt, dass includes die bessere Lösung sind aus HTML/Design-Sicht (Weniger Darstellungsprobleme usw) doch jetzt vermute ich, dass durch die includes des "Hauptscripts" also index.php bei hoher Besucherzahl mehr belastet als einfache HTML-iframes, da das Script nicht "zur ruhe" kommt. Bei Frames werden alle Scripts zunächst abgearbeitet und kleinere PHP-"Seiten" werden mit Hilfe von Session-Variablen "nachgeladen" wobei bei der include-Version alles auf einen streich passiert!

ist meine vermutung also richtig, dass iframes hier die bessere Lösung wären oder könnte man das sogar verallgemeinern, dass iframes in Bezug auf Serverlast immer die bessere Lösung sind!?

o_o
Kopp

[frankx]

Hellihello

also bei allen Framediskussionen ist mir die Serverlast nicht untergekommen, und ich bin eigentlich vom Prinzip her ein großer Framefreund.

Dank und Gruß,

frankx

[Beat]

Ganz einfache Frage:
Was ist Serverlastiger? Ein PHP-"Haupt"-Script das per include() sagen wir mal 5-10 Seiteninhalte lädt oder stattdessen 5-10 HTML-Frames die den Inhalt "nachladen" (kleine PHP-"seiten")?

Es ist ganz gewiss performanter, wenn du überhaupt nur isolierte Dateninseln ins Web stellst, und der Framesetrahmen möglichst nie aufgerufen wird.

Was immer du dir in deinen Framesets für einen Sessionmechanismus, eventuell gekoppelt mit Leserechten, ausdenkst. deine Dateninseln werden davon ganz unberührt bleiben.

Zunächst war ich überzeugt, dass includes die bessere Lösung sind aus HTML/Design-Sicht (Weniger Darstellungsprobleme usw) doch jetzt vermute ich, dass durch die includes des "Hauptscripts" also index.php bei hoher Besucherzahl mehr belastet als einfache HTML-iframes, da das Script nicht "zur ruhe" kommt. Bei Frames werden alle Scripts zunächst abgearbeitet und kleinere PHP-"Seiten" werden mit Hilfe von Session-Variablen "nachgeladen" wobei bei der include-Version alles auf einen streich passiert!

Du willst also immer noch php Seiten in die Frames laden. Dadurch erzeugst du eindeutig mehr Last. Denn jetzt müssen noch mehr Scripte auf deine Datenbanken zugreifen um Sessions zu kontrollieren.

ist meine vermutung also richtig, dass iframes hier die bessere Lösung wären oder könnte man das sogar verallgemeinern, dass iframes in Bezug auf Serverlast immer die bessere Lösung sind!?

Nein.

Rein statische Seiten sind bestimmt performanter. Jedoch kannst die Frage auch vergleichen mit dem Laden von zig Bildern für die Gui:
Was ist performanter: ein einziges Sprite oder zig Requests?

mfg Beat

[Kopp]

Hallo nochmal!

Vielleicht habe ich mich nicht gut genug ausgedrückt. In den Frames, so wie ich sie mir vorstelle, werden nur Session-Variablen bezogen und sonst nichts! Die Datenbankverbindung ist schon längst gelaufen bis dahin. Das ist ja der Springende Punkt.

Also derzeit sieht das bei mir so aus

include("datenbank.php"); // Baut Datenbankverbindung her
include("allgemine.funktionen.php"); // Funktionen die ich in jedem Projekt brauche
include("lokale.funktionen.php"); // Lokale Funktionen
include("verifikation_der_url.php"); // Überprüft ob der Url-Aufruf genehmigt wird
include("brain.php"); // Eigentlich Scripte für die "Berechnungen" von Variablen ect.
mysql_close($link); // Datenbank schließen

...
(Seite darstellen)
include("part1.php");
(Seite darstellen)
include("part2.php");
(Seite darstellen)
include("part3.php");
...

Ist doch Theoretisch "sauber" oder?

Vielleicht ist es aber noch Sinnvoller das Eigentlich Script von der Website zu trennen. Sprich thinking.php als erste Anlaufstelle und wenn das abgearbeitet ist wird erst start.php geladen und da wird nichts gemacht außer Variablen auszulesen. aber was hat man dann für einen Vorteil? Es dauert ja genau so lang wie vorher!?

Kopp

[Beat]

Vielleicht habe ich mich nicht gut genug ausgedrückt. In den Frames, so wie ich sie mir vorstelle, werden nur Session-Variablen bezogen und sonst nichts!

Ja und du drückst dich weiter ungenau aus. In den Frames werden ressourcen geladen.
Was du tun kannst: Die Frameset definierende Datei ist eine Datei, die gleichzeitig Sessions verwaltet. Diese Fähigkeit erstreckt sich aber nicht auf die Ressourcen in den Frames.

Die Datenbankverbindung ist schon längst gelaufen bis dahin. Das ist ja der Springende Punkt.

Der Springende Punkt bei Sessions ist, dass IDs für jeden schützenswerten Content bei jedem Request zu prüfen sind.

Also derzeit sieht das bei mir so aus

include("datenbank.php"); // Baut Datenbankverbindung her
include("allgemine.funktionen.php"); // Funktionen die ich in jedem Projekt brauche
include("lokale.funktionen.php"); // Lokale Funktionen
include("verifikation_der_url.php"); // Überprüft ob der Url-Aufruf genehmigt wird
include("brain.php"); // Eigentlich Scripte für die "Berechnungen" von Variablen ect.
mysql_close($link); // Datenbank schließen

...
(Seite darstellen)
include("part1.php");
(Seite darstellen)
include("part2.php");
(Seite darstellen)
include("part3.php");
...

Ist doch Theoretisch "sauber" oder?

Und du verbirgst, wie ich über die urls, die du in frames zu deponieren hast, mir einen direktzugriff erlaubst, der sich deiner Kontrolle entzieht.

Vielleicht ist es aber noch Sinnvoller das Eigentlich Script von der Website zu trennen. Sprich thinking.php als erste Anlaufstelle und wenn das abgearbeitet ist wird erst start.php geladen und da wird nichts gemacht außer Variablen auszulesen. aber was hat man dann für einen Vorteil? Es dauert ja genau so lang wie vorher!?

Dein Hauptscript sollte nur schnell sich ins Reine kommen, welches der geforderte Aufgabensektor (hier mit Frame assoziiert) ist, und nur das auf Bedarf einbinden/abarbeiten.
Vor dieser Entscheidung steht aber immer die Rechteentscheidung. Es sollte konzeptionell schlicht unmöglich sein, dass sich über Frames etwas daran vorbeimogeln kann. Das tut es aber, weil du urls für die Frameinhalte publizieren musst, und dann eine Prüfung, woher der Request stammt, nur möglich ist, indem jeder Frameinhalt wiederum die Fähigkeit zur Sessionprüfung hat.

Du erzeugst damit eine Redundanz, die du ohne Frames vermeiden kannst.

Abgesehen davon ist das EVA Prinzip am konsequentesten zu realisieren, indem man alles (schützenswerte) über einen zentralen Prozess leitet.

mfg Beat

[Kopp]

Also definitiv keine Frames (in meinem Fall).

Von mir aus nennen wir es EVA :-)
Beschränken wir uns mal nur auf VA:
V&A wird derzeit zusammen bewältigt.
Macht es sinn ein Script nennen wir es mal V.php von A.php zu trennen und im V.php-Script am ende eine Weiterleitung auf A.php zu machen?

Kopp

[Sven Rautenberg]

Moin!

Macht es sinn ein Script nennen wir es mal V.php von A.php zu trennen und im V.php-Script am ende eine Weiterleitung auf A.php zu machen?

Nicht in jedem Fall.

Es gibt das POST-Redirect-GET-Pattern, das wird aber nur verwendet, wenn man POST-Requests verarbeitet, um die Reload-Problematik zu entschärfen. Es gibt kein GET-Redirect-GET-Pattern, das wäre ziemlich sinnlos - zumal es den Server auch wieder mit einem zusätzlichen Request belastet.

- Sven Rautenberg

[Beat]

Beschränken wir uns mal nur auf VA:
V&A wird derzeit zusammen bewältigt.
Macht es sinn ein Script nennen wir es mal V.php von A.php zu trennen und im V.php-Script am ende eine Weiterleitung auf A.php zu machen?

A steht für Ausgabe.

EVA hat nichts mit der Zersplitterung in verschiedene Scripte zu tun. Es hat mit der Reihenfolge der Logik zu tun, damit keine voreiligen Fehlausgaben geschehen. oder fortgeschrittene Verarbeitung schon gar nicht geschieht, wenn die Rechte fehlen.
Der Vorteil von EVA ist, dass es eher eine Modularisierung eben im Sinne von Templates zulässt. Ob diese Templates in einer Bibliothek stecken, in subs vorliegen oder selbst wiederum Dateninseln darstellen, ist grundsätzlich egal und abhängig vom allgemeinen Konzept/Aufwand.
Es ist auch legitim, während der Verarbeitung die Ausgabe-Bestandteile vorzufüllen. Das wird auch meistens getan. Nur wird die Ausgabe verzögert bis die Ausgabe auch definitiv abgesegnet werden kann.

mfg Beat

[Cheatah]

Hi,

In den Frames, so wie ich sie mir vorstelle, werden nur Session-Variablen bezogen und sonst nichts!

und diese Werte muss der Server erst mal irgendwoher ermitteln und in ein Objekt zusammenpacken. Ähnliches passiert mit $_GET, $_POST, $_REQUEST, $_COOKIE, $_SERVER, $_FILES, $_ENV und Konsorten. Er muss auch die Konfiguration analysieren, Speicherbereiche bereitstellen und was weiß ich was noch alles.

All diese Dinge sind schon längst geschehen, wenn Du ein include() ausführst - der tatsächlich anfallende Organisationsaufwand ist minimal. Bei einer neuen Ressource sind sie jedoch erneut nötig.

Die Datenbankverbindung ist schon längst gelaufen bis dahin. Das ist ja der Springende Punkt.

Dieser Punkt springt bei include() und bei Frames gleichermaßen. Es existiert kein Gewinn, egal wofür Du Dich entscheidest. Es sei denn, Du ziehst in Betracht, irgendwann die Datenbankverbindung in einem include() doch noch mal zu benutzen, dann erhöht sich der Performance-Verlust bei Frames.

Also derzeit sieht das bei mir so aus

[...]

include("verifikation_der_url.php"); // Überprüft ob der Url-Aufruf genehmigt wird

Sicherheitsbedenken aller Art sind auch bei solchen Frames nicht zu vernachlässigen, deren Ressourcen Dir eher harmlos erscheinen. Punkte wie diesen solltest Du also auch dort unterbringen. Ein weiterer Minuspunkt gegen Frames.

Vielleicht ist es aber noch Sinnvoller das Eigentlich Script von der Website zu trennen. Sprich thinking.php als erste Anlaufstelle und wenn das abgearbeitet ist wird erst start.php geladen und da wird nichts gemacht außer Variablen auszulesen.

Ich denke eher, dass es sinnvoller ist, HTTP als das zu nehmen, was es ist: als zustandsloses Protokoll. Jeder Request steht komplett für sich selbst, ein Kontext existiert nicht. Die Aufsplittung einer (inhaltlichen) Präsentation in mehrere Requests mutet da eher albern an: Ein Dokument, das momentan gerade mal in einem Inhalts-Frame geladen ist, hat in Wirklichkeit keinerlei Zusammenhang zu einem anderen Dokument, das sagen wir mal in einem Navigations-Frame geladen sein könnte. Betrachte die beiden separat (also so, wie es etwa auch eine Suchmaschine macht), und Du wirst unwillkürlich an diverse Filme erinnert, in denen eine Leiche stückchenweise gefunden und mühsam zusammengesetzt wird, bis man plötzlich feststellt, dass nur wenige Menschen zwei Füße besitzen, deren großer Zeh auf der linken Seite liegt.

aber was hat man dann für einen Vorteil? Es dauert ja genau so lang wie vorher!?

Bei Frames nach Vorteilen zu suchen, hat einen etwas esoterischen Charakter und dürfte wachsende Erfolgschancen haben, wenn der Vorgang von Drogen unterstützt wird. Man findet zwar auch ohne derlei Mittel durchaus Vorteile von Frames - aber eher in dem Maße, wie man Täler vor Ayers Rock findet. Ohne Drogen nennt man sie halt "Furchen".

Cheatah

[Cheatah]

Hi,

ist meine vermutung also richtig, dass iframes hier die bessere Lösung wären oder könnte man das sogar verallgemeinern, dass iframes in Bezug auf Serverlast immer die bessere Lösung sind!?

bei Frames kommt zusätzlich zu dem Aufwand, den der Server mit der Abarbeitung der assoziierten Dateien hat, noch die Requestbearbeitung (ggf. mit dem Starten neuer Apache-Worker, Prozessor-Instanzen u.ä.) und der erhöhte HTTP-Traffic (pi mal Daumen 2kB für Request- und Response-Header pro Ressource) hinzu. Die Last ist garantiert höher als die beim Verarbeiten eines include(). Sie erscheint Dir vielleicht geringer, weil sie verteilter ist - nicht zuletzt dadurch, dass der Client mit den Frames eine höhere Last besitzt.

Cheatah

[Multi]

Mahlzeit,

ist meine vermutung also richtig, dass iframes hier die bessere Lösung wären oder könnte man das sogar verallgemeinern, dass iframes in Bezug auf Serverlast immer die bessere Lösung sind!?

Nein, das hängt immer von den Frameinhalten ab. Wenn diese statisch sind, stimmt deine Annahme, sopbald die Inhalte dynamisch erzeugt werden, kann es anders aussehen, Zusätzliche Datenbankabfragen wurde ja schon als Beispiel genannt.

Was sich bei Frames aber drastisch erhöht, ist der Wartungsaufwand. Du muss je für jede Frameseite eine eigene HTML/PHP/sonstwas-Seite warten und testen. Bei PHP per include() hast du unterm Strich nur eine einzige Seite, die du bei Bedarf erweiterst.

[Sven Rautenberg]

Moin!

Ganz einfache Frage:
Was ist Serverlastiger? Ein PHP-"Haupt"-Script das per include() sagen wir mal 5-10 Seiteninhalte lädt oder stattdessen 5-10 HTML-Frames die den Inhalt "nachladen" (kleine PHP-"seiten")?

Ganz klar die Frames-Variante.

Ein Browser kann nur eine maximale Zahl an HTTP-Connections zum Server eröffnen. Über diese Connections müssen alle Elemente der aktuell zu ladenden Seite beschafft werden, d.h. es werden zwingend Dinge nacheinander geladen, nicht parallel. Deshalb ist es bei Seiten, die schnell sein wollen, eigentlich Standard bei der Optimierung, die Webseite aus möglichst wenig Elementen zusammenzusetzen:

- nur ein einziges, großes, gut komprimiertes Javascript
 - nur ein einziges, großes, gut komprimiertes CSS
 - nur ganz wenige einzelne Grafiken, stattdessen aber
 - nur eine einzige große CSS-Sprite-Grafik, die als positioniertes Hintergrundbild jeweils nur einen winzigen Ausschnitt zeigt - eben genau denjenigen, der als Icon gerade benötigt wird.

Wenn du jetzt also anstelle der einen, mit PHP zusammengesetzten Seite ein Frameset lädst, dann bürdest du dem Client zusätzliche Ladevorgänge auf - und weil das zentrale Frameset erstmal nur HTML-Dateien lädt, werden Bilder etc. erst danach vom Server abgerufen.

Zusätzlich kommt noch die Problematik mit den Sessions ins Spiel: PHP sperrt die Datei, in der die Sessiondaten liegen, gegen wechselseitiges Überschreiben. Deshalb warten alle Skripte, die diese Datei durch den Befehl session_start() lesen wollen, so lange, bis das erste Skript, was den Zugriff erhalten hatte, beendet wird, oder durch session_write_close() den sessiondatenverändernden Part für erledigt erklärt. Die einzelnen HTML-Seiten des Framesets werden also nicht mal parallel geladen, sondern schön nacheinander. Wobei sie den Server eben auch deshalb belasten, weil für die Zeit, in der das passiert, jeweils ein Webserver-Prozess benutzt wird, der nichts tun kann, sondern abwartet. Du sperrst dir im Extremfall also freiwillig vier oder mehr Prozesse zur Auslieferung der HTML-Seite, wo du mit einem includierenden Skript nur einen einzigen benötigt hättest, der insgesamt vermutlich schneller wäre.

Zunächst war ich überzeugt, dass includes die bessere Lösung sind aus HTML/Design-Sicht (Weniger Darstellungsprobleme usw) doch jetzt vermute ich, dass durch die includes des "Hauptscripts" also index.php bei hoher Besucherzahl mehr belastet als einfache HTML-iframes, da das Script nicht "zur ruhe" kommt.

Wann immer du "vermutest" - gewinne Gewissheit, indem du nachmisst. Nur reale Messwerte geben dir Gewissheit, was aktuell "Sache" ist. Wobei zu beachten ist, dass diese Messwerte natürlich auch noch auf ganz andere Art optimiert werden können.

ist meine vermutung also richtig, dass iframes hier die bessere Lösung wären oder könnte man das sogar verallgemeinern, dass iframes in Bezug auf Serverlast immer die bessere Lösung sind!?

Nein. Im Allgemeinen ist deine Vermutung falsch.

- Sven Rautenberg

[Beat]

• nur ganz wenige einzelne Grafiken, stattdessen aber
• nur eine einzige große CSS-Sprite-Grafik, die als positioniertes Hintergrundbild jeweils nur einen winzigen Ausschnitt zeigt - eben genau denjenigen, der als Icon gerade benötigt wird.

Was mir Anlass zur Themendrift gibt, weil ich derzeit gerade ein solches Sprite in Inkscape entwerfe.
Sprites, die eine gemeinsame Funktion haben, sind relativ einfach zu entwickeln. solange man weiss, dass man nie eine repeat-x repeat-y Eigenschaft braucht.
Wenn ich aber die gesamte GUI-Grafik in einem Sprite laden will bekomme ich aktuell Designprobleme.
Wie lege ich die Sprites geeignet aus.

Ein zweites Bedenken stammt von mobilisten, besagend, dass mobiles Probleme bekunden, wenn das Sprite zu gross ist. Das geschieht aber genau dann, wenn man aus Mangel an repeat Möglichkeit übergrosse Backgrounds entwerfen muss, oder grössere Logos verwendet.

Aus dieser Beschränkung wird man doch vielleicht zwei drei Sprites verwenden müssen, was aber auf Dauer immer noch viel besser ist als Einzelgrafiken, besondern für Dinge wie Listbullets, Filesystem Icons, etc...

Wäre es effektiv via CSS möglich, einen repeat nur auf einen kleinen Bildausschnitt anzuwenden, liessen sich auch kleinere Spritefiles erzeugen.
Ich kenne aber keine Methode.

mfg Beat;

[Kopp]

War ich kürzlich eingefroren oder so?
Das sind ja ganz neue Techniken von denen ich da höre..
Wo werde ich über sowas informiert?
Wo kann ich mehr darüber lesen?
Vielleicht sollte ich meine Seite einfach mal komplett neu Designen :-) Dann klappts auch wieder mit den Besuchern ;-)

Kopp