nicht angemeldet
Wie groß darf eine HTML-Seite sein?
Hallo,
was ist die maximale Größe einer HTML-Seite, die der Internet Explorer 5.5 verkraften kann?
In meinem Intranet (also nicht Modem/ISDN, daher spielt die Übertragungsgeschwindigkeit eine eher untergeordnete Rolle) stelle ich Berichte als HTML-Tabellen dar, die locker mehrere (zehn)tausend Zeilen beinhalten könnten, je nach Userangaben (aktuelle Grenze; 32000 Zeilen). Ich will wissen, ob diese riesigen Tabellen meinen Browser (bzw. den IIS 5 Webserver, der sie liefern muss) überfordern werden, oder unerträglich langsam aufgebaut werden. Wo ist die Grenze, wo gibt der Browser auf...
Bis jetzt habe ich bei meinen Recherchen (Google, MSDN, SelfHTML-Archiv) nur Angaben für Webdesigner gefunden, wie klein man eine Seite halten soll, um sie schnell übers Internet übermitteln und gelangweilten Surfern Geduldsproben ersparen zu können. Dabei wurden die browsereigenen Grenzen nicht erwähnt.
Gruß und vielen Dank für Anregungen/Erfahrungen,
RMH
-
Hi!
was ist die maximale Größe einer HTML-Seite, die der Internet Explorer 5.5 verkraften kann?
Ich glaube, du solltest dich erstmal fragen, wieviel Inhalt für den User maximal auffassbar ist. Eine solche riesige Seite schreit danach weitergeklickt zu werden, weil es so ermüdent wirkt.
Einzelne kleinere Seiten spornen viel mehr dazu an, alles zu lesen.Tschüss!
--
Genug der Worte,
genug blabla,
ich liebe dich,
das reicht!-
Ich glaube, du solltest dich erstmal fragen, wieviel Inhalt für den User maximal auffassbar ist. Eine solche riesige Seite schreit danach weitergeklickt zu werden, weil es so ermüdent wirkt.
Einzelne kleinere Seiten spornen viel mehr dazu an, alles zu lesen.Im Normalfall ja... hier aber gelten die normalen Regeln nicht. Es handelt sich um ein firmeninternes Berichtswesen, also reine Produktivitäts- und Verkaufszahlen statt Unterhaltung, und die Anforderung kommt direkt von den Anwendern (oder zumindest deren Vertreter, unserem Auftraggeber).
Beispiel: zur Zeit möchten die Anwender Rankingberichte, z.B. die besten Verkäufer sortiert nach Umsatz. Ein solcher bundesweiter Rankingbericht kann schon 100000 Einträge beinhalten. Natürlich würde kein normaler Mensch sich sowas anschauen, aber die Anwender lassen sich keine rein theoretischen Grenzen ohne technische Begründung aufsetzen.
Dazu noch als Hintergrund: sie wollen das Ganze auch ausdrucken oder in Excel exportieren können. Bei der Vorstellung wird mir schlecht, aber als Dienstleister muss ich sagen können "geht" oder "geht nicht", und warum.
Wenn ich z.B. sagen könnte, ab 15000 Zeilen mit 100 parallelen Anwendern ginge mit dem Browser/Webserver/Arbeitsspeicher definitiv nichts mehr, hätten wir eine Basis für weitere Planung und Entwicklung (z.B. nach Alternativen zur Webdarstellung suchen). Mit ungenauen Aussagen wie "eigentlich keine Grenze, aber mehr als 1000 Zeilen würden wir ungern zulassen wollen" oder "es kommt darauf an" habe ich dagegen schlechte Karten.
Im Normalfall wäre das Ganze kein Problem, aber erfahrungsgemäß gibt es immer mindestens einen User, der sich bei der Auswahl der Kriterien vertippt oder "einfach mal ausprobieren" will, wieviel auf einmal wohl ginge... Ich will nicht in diese Situation geraten.
Gruß,
RMH
-
-
Hallo Richard,
ich hätte bisher nichts von einer tatsächlichen Obergrenze gehört, gehe daher davon aus, dass es keine gibt. Trotzdem kannst Du an Probleme stoßen - abhängig davon, was sonst noch auf dem Rechner läuft, was es für einer ist (Prozessor, Arbeitsspeicher), wie kompliziert das Rendering der HTML-Seiten ist usw. Ich selber habe auf meiner alten Möhre die Erfahrung gemacht, dass bei sehr langen Tabellen Browser/Rechner etwas zäh werden, nicht mehr flüssig reagieren. Hängt aber wie gesagt von Deiner Umgebung ab, daher: Versuch macht kluch!
Grüße,
Utz
-
was ist die maximale Größe einer HTML-Seite, die der Internet Explorer 5.5 verkraften kann?
Weder HTML noch HTTP kennen AFAIK eine Größenbegrenzung, von daher sollten auch Browser keine kennen.
Ich will wissen, ob diese riesigen Tabellen meinen Browser (bzw. den IIS 5 Webserver, der sie liefern muss) überfordern werden, oder unerträglich langsam aufgebaut werden. Wo ist die Grenze, wo gibt der Browser auf...
Bevor der Browser aufgibt, gibst Du auf :)
Nein, ernsthaft: Diese Frage lässt sich nicht beantworten, da sie (zumindest theoretisch) einzig und alleine von der verwendeten Hardware und Deinem Geduldsfaden abhängt.
Die einzige Softwaregrenze, die bei Dir mit Sicherheit irgendwie existieren wird, ist 2^32-1 (etwas über 4 Milliarden) - der maximale Wert einer ganzen Zahl, den die derzeit üblichen Heimrechner in einem Stück speichern können (für allgemeine Zwecke).Also, probier' es einfach aus. Irgendwann wird bei Dir der Punkt erreicht sein, an der Dein Rechner keinen Platz mehr hat oder Du nicht mehr warten willst oder schlichtweg die Übersicht in Deiner Seite verlierst.
Gruß,
soenk.e -
Hi,
In meinem Intranet (also nicht Modem/ISDN, daher spielt die Übertragungsgeschwindigkeit eine eher untergeordnete Rolle) stelle ich Berichte als HTML-Tabellen dar, die locker mehrere (zehn)tausend Zeilen beinhalten könnten, je nach Userangaben (aktuelle Grenze; 32000 Zeilen). Ich will wissen, ob diese riesigen Tabellen meinen Browser (bzw. den IIS 5 Webserver, der sie liefern muss) überfordern werden, oder unerträglich langsam aufgebaut werden. Wo ist die Grenze, wo gibt der Browser auf...
meine Erfahrungen, sicherlich auch Deine mittlerweile, bei >10MB HTML-Code wird's bereits bei manchen Rechnern ganz uebel. Koennte mit dem Arbeitsspeicher zusammenhaengen. :-)
Gruss,
Lude -
was ist die maximale Größe einer HTML-Seite, die der Internet Explorer 5.5 verkraften kann?
Das hängt wohl in erster Linie von der Leistungsfähifkeit der Rechner ab, die die Seite darstellen sollen. Mein 266'er Prozessor geht schon, bei heuzutage üblichen Seiten, oft mächtig in die Knie und wenn ich eine größere Anwendung parallel laufen hab, sind auch schnell die Resourcen knapp.
Insofern ist eine Zahlenangabe nicht möglich (neben den schon erwähnten techn. Grenzen).
Über den Server würd ich mir eher weniger Gedanken machen, ist ja schließlich heutzutage auch üblich Filme downzuloaden und die dürften noch größer sein.
Struppi.
-
Moin!
Über den Server würd ich mir eher weniger Gedanken machen, ist ja schließlich heutzutage auch üblich Filme downzuloaden und die dürften noch größer sein.
Die Frage beim Server ist doch: Wie lange dauert die Generierung und Ausgabe der Seite? Abhängig von der Sprache und den Einstellungen kann man da durchaus an Grenzen gelangen.
PHP hat standardmäßig 30 Sekunden Skriptlaufzeit - damit kein abgestürztes oder in einer Endlosschleife gefangenes Skript endlös läuft. Diese Zeit kann man konfigurieren, also auch 10 Minuten draus machen, aber es dürfte für den Anwender eher nicht hilfreich sein, 10 Minuten auf die komplette Seite zu warten. Wieviele Daten kann man in 30 Sekunden senden? Bei 100 MBit/s dürften das grob geschätzt 300 MByte sein. Das ist eine heftig große Seite. Bei 10 Minuten Laufzeit kommen 6 GByte über die Leitung.
Mal angenommen, ein Tabelleneintrag bestünde aus 300 Byte, dann würden im ersten Fall 1 Million Datensätze dargestellt werden können. Ich würde behaupten, dass sich in diesem Fall niemand mehr für die letzten Datensätze interessiert - und finden wird in dieser Monstertabelle auch niemand mehr etwas.
Das wahre Problem dürfte also eher nicht sein, dass riesige Tabellen abgefordert werden, sondern dass ein Weg gefunden werden muß, den Benutzern eine vernünftige Ansicht auf die in der DB gespeicherten Daten zu geben. Die Auflistung aller enthaltenen Datensätze ist in den allerseltensten Fällen wirklich sinnvoll.
- Sven Rautenberg
--
"Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)-
Hi,
Das wahre Problem dürfte also eher nicht sein, dass riesige Tabellen abgefordert werden, sondern dass ein Weg gefunden werden muß, den Benutzern eine vernünftige Ansicht auf die in der DB gespeicherten Daten zu geben. Die Auflistung aller enthaltenen Datensätze ist in den allerseltensten Fällen wirklich sinnvoll.
es gibt da schon was. Und zwar die Datenbankabfrage per HTTP, auch als 'Webabfrage' bekannt. 'MS Excel'-Clients tun sowas schon mal.
Gruss,
Lude-
Moin!
Das wahre Problem dürfte also eher nicht sein, dass riesige Tabellen abgefordert werden, sondern dass ein Weg gefunden werden muß, den Benutzern eine vernünftige Ansicht auf die in der DB gespeicherten Daten zu geben. Die Auflistung aller enthaltenen Datensätze ist in den allerseltensten Fällen wirklich sinnvoll.
es gibt da schon was. Und zwar die Datenbankabfrage per HTTP, auch als 'Webabfrage' bekannt. 'MS Excel'-Clients tun sowas schon mal.
Aber das wäre in diesem Fall wirklich Wahnsinn, eine "Datenbankabfrage" auf diese Weise zu realisieren.
Ich bin mir nicht 100% sicher, aber auch MS Excel bietet doch die Möglichkeit, eine Datenbank _direkt_ zu befragen. Eine Abfrage der x.ten Tabellenzelle einer mehrere hundert Megabyte großen, dynamisch generierten HTML-Tabelle dürfte die Ausgeburt des Bösen sein. Der DB-Admin wird da alle Hebel in Bewegung setzen, um diesen Schwachsinn zu verbieten.
- Sven Rautenberg
--
"Bei einer Geschichte gibt es immer vier Seiten: Deine Seite, ihre Seite, die Wahrheit und das, was wirklich passiert ist." (Rousseau)-
Hi,
Das wahre Problem dürfte also eher nicht sein, dass riesige Tabellen abgefordert werden, sondern dass ein Weg gefunden werden muß, den Benutzern eine vernünftige Ansicht auf die in der DB gespeicherten Daten zu geben. Die Auflistung aller enthaltenen Datensätze ist in den allerseltensten Fällen wirklich sinnvoll.
es gibt da schon was. Und zwar die Datenbankabfrage per HTTP, auch als 'Webabfrage' bekannt. 'MS Excel'-Clients tun sowas schon mal.
Aber das wäre in diesem Fall wirklich Wahnsinn, eine "Datenbankabfrage" auf diese Weise zu realisieren.
Warum?
Ich bin mir nicht 100% sicher, aber auch MS Excel bietet doch die Möglichkeit, eine Datenbank _direkt_ zu befragen.
Wie?
Eine Abfrage der x.ten Tabellenzelle einer mehrere hundert Megabyte großen, dynamisch generierten HTML-Tabelle dürfte die Ausgeburt des Bösen sein. Der DB-Admin wird da alle Hebel in Bewegung setzen, um diesen Schwachsinn zu verbieten.
Ich bin der Admin! :-) (Stimmt leider nicht mehr ganz.) - Die Zeiten aendern sich und wenn die Verbindung z.B. DSL oder 10MegBit ist, dann sind z.B. 10MB recht schnell bzw. verdammt schnell da.
(Von mehreren hundert MB habe ich, glaube ich, nicht geschrieben. Das kommt erst in 5 Jahren.)Wir haben da einige Nutzer aus den kaufmaennischen Ebenen, die z.B. gerne mal ihre OLAP-Cubes auf die genannte Art und Weise aktualisieren. (Begeistert bin ich auch nicht davon, aber wie geht's mit vertretbarem Aufwand besser?)
Gruss,
Lude
-
-
Das wahre Problem dürfte also eher nicht sein, dass riesige Tabellen abgefordert werden, sondern dass ein Weg gefunden werden muß, den Benutzern eine vernünftige Ansicht auf die in der DB gespeicherten Daten zu geben. Die Auflistung aller enthaltenen Datensätze ist in den allerseltensten Fällen wirklich sinnvoll.
es gibt da schon was. Und zwar die Datenbankabfrage per HTTP, auch als 'Webabfrage' bekannt. 'MS Excel'-Clients tun sowas schon mal.
Datenbankabfragen und Excel kommen nicht in Frage: es sind Standardberichte, die vorgegeben sind, und sie werden ausschließlich von der Software generiert. Dazu kommt eine Menge Nachbearbeitung und Customising, das erst mit dem fertigen XML/HTML geschieht (Steuerspalten entfernen, benutzerabhängige Anzeige und Sortierung usw.). Nur die absoluten Poweruser werden mit dem Tool auf die Datenbank losgelassen, alle normalen Anwender gehen übers Web.
Darüber hinaus wird das Ganze in ein Portal eingebunden, und läuft quasi-versteckt, die User kriegen nur die Anzeige und steuern alles über Eingaben auf den HTML-Seiten. Dann kommen Sicherheitsmaßnahmen dazu - es soll keiner direkt darauf zugreifen können, es gibt immer mehrere Security-Schichten dazwischen.
Fazit: nur die Webanzeige zählt, oder ich muss mir was Anderes ausdenken.
-
Hi,
Datenbankabfragen und Excel kommen nicht in Frage: es sind Standardberichte, die vorgegeben sind, und sie werden ausschließlich von der Software generiert. Dazu kommt eine Menge Nachbearbeitung und Customising, das erst mit dem fertigen XML/HTML geschieht (Steuerspalten entfernen, benutzerabhängige Anzeige und Sortierung usw.). Nur die absoluten Poweruser werden mit dem Tool auf die Datenbank losgelassen, alle normalen Anwender gehen übers Web.
Darüber hinaus wird das Ganze in ein Portal eingebunden, und läuft quasi-versteckt, die User kriegen nur die Anzeige und steuern alles über Eingaben auf den HTML-Seiten. Dann kommen Sicherheitsmaßnahmen dazu - es soll keiner direkt darauf zugreifen können, es gibt immer mehrere Security-Schichten dazwischen.
Fazit: nur die Webanzeige zählt, oder ich muss mir was Anderes ausdenken.
ja, was haben denn die Tests (keonnte mir vorstellen, dass Du welche durchgefuehrt hast, nachdem im Forum ja "nicht viel kam") ergeben? - Mich taeten die Resultate auch interessieren. - Meine Erfahrungen habe ich Dir schon mitgeteilt.
Gruss,
Lude-
ja, was haben denn die Tests (keonnte mir vorstellen, dass Du welche durchgefuehrt hast, nachdem im Forum ja "nicht viel kam") ergeben? - Mich taeten die Resultate auch interessieren. - Meine Erfahrungen habe ich Dir schon mitgeteilt.
Hi Lude,
der produktive Betrieb läuft zur Zeit mit einem Maximum von 1000 Zeilen (übliche Berichte liegen zwischen 10 und 100 Zeilen). Das reicht schon, um eine spürbare Verlangsamung (ASP: Sekundenbereich, DLLs: Sekunden bzw. Zehntelsekunden statt Millisekunden) der Aufbereitung zu verursachen.
Zur Zeit gehe ich den anderen Weg, nämlich Überzeugungsarbeit leisten, dass man die Daten sinnvollerweise anders aufbereitet und zur Verfügung stellt. Das wurde erstmal akzeptiert - wenn die User es sich anders überlegen, werde ich wohl echte Härtetests (Größenordnungen höher) machen müssen.
Gruß,
RMH
-
-
-
-
Moin!
Über den Server würd ich mir eher weniger Gedanken machen, ist ja schließlich heutzutage auch üblich Filme downzuloaden und die dürften noch größer sein.
Die Frage beim Server ist doch: Wie lange dauert die Generierung und Ausgabe der Seite? Abhängig von der Sprache und den Einstellungen kann man da durchaus an Grenzen gelangen.
Das ist ebenfalls ein Problem. Hier sind mehrere Server im Einsatz: der Client fordert einen Bericht übers Web an, der Webserver leitet die Anfrage an den Berichtsserver weiter, der Berichtsserver generiert ein SQL-Statement auf Basis der vorhandenen Metadaten (in der DB) und schickt es an den Datenbankserver, der Datenbankserver arbeitet das Statement ab und schickt die Ergebnisse an den Berichtsserver, der alles als XML an die Webserver/Webanwendung (IIS/ASP) zurückschickt, die wiederum das Ganze in HTML darstellen soll...
Bei jedem Schritt sind Engpässe möglich. Vorgesehen im System sind zunächst um die 1500 Anwender. Um die Datenbank mache ich mir weniger Sorgen, aber alles andere... wenn ich denke, wie sich der Berichts- bzw. Webserver verhalten könnte, allein um das Ganze in XML zu verwalten bzw. via ASP-Anwendung in HTML zu formatieren, da habe ich kein so gutes Gefühl. Daher wird zur Zeit standarmäßig jede Abfrage, die zuviele (>32000) Zeilen generiert, gar nicht erst weiterverarbeitet, sondern es wird eine Fehlermeldung produziert.
Die Anwender wollen es aber anders. Es ist nicht ganz so schlimm wie "drucken Sie mir bitte das Internet aus", aber sie wollen zuerst alle Zahlen auf einmal, um dann in Eigenregie das auszupicken, wofür sie sich interessieren. Sozusagen die gesamte Bibliothek mit nach Hause nehmen, um dann nur ein paar Zeitschriften zu lesen.
Also, ran an die Ermittlung der möglichen Flaschenhälse!
-
-
-
Man kann auf Dateisystem Ebene sehr wohl den theoretisch maximale Größe einer Datei angeben.
Mehr als 2 GB sollte keine Datei (auch keine .html Datei) haben, weil damit z.b. Win95, Win98, Win98SE, WinME definitiv nicht zurecht kommen (Spezifikation). Das wäre also schonmal eine theoretisch wirklich MAXIMALE Grenze. Win XP sollte damit klar kommen.
Btw: Sowas kann man sehr leich selbst testen.
Ich würde aber trotzdem noch weiter suchen, um eine kleinere Grenze zu finden, um besser vor den Kunden argumentieren zu können.
Grüße
-Marco Wagner-