nicht angemeldet
Folgender Thread "existiert nicht mehr" - war wichtig!
Hallo!
Hier hat Henryk mir nettwerweise viel interessante Dinge über SHELL und den verschlüsselten Mailversand geschrieben. Aber fast schneller als ich gucken konnte ist der Thread aunauffindbar im Archiv untergetaucht.
Im Archiv steht aber noch der Titel:
20.02.2002 (PHP) gesendete mail() mit Anhang verschlüsseln
aber leider folgender Link:
http://forum.de.selfhtml.org/archiv/2002/2/5180/
Wäre sehr schade wenn der weg wäre, aber wie ich Euch kenne zaubert Ihr den wieder aus irgendeinem Hut....
Viele Grüße
Andreas
-
jetzt komme ich mir irgendwie selbst ein bisschen unverschämt vor, sorry! Was ich sagen wollte:
Es wäre nett von Euch wenn Ihr mal schauen könntet ob der Thread tatsächlich nicht mehr existiert oder sonst bitte die Verknüpfung herstellen könntet. Wäre sehr nett von Euch! Und ob der für die Menschheit jetzt sooo wichtig war kann ich nicht sagen, nur Henryk hat mir da wirklich was gutes geschrieben, was mir sehr geholfen hat, nur habe ich es mir nicht alles gemerkt, und jetzt ist es weg.
Würd mich freuen wenn Ihr das vielleicht noch hinbekommt!Viele Grüße
Andreas -
Wäre sehr schade wenn der weg wäre, aber wie ich Euch kenne zaubert Ihr den wieder aus irgendeinem Hut....
jaja, ich bin ja schon dabei, kann auch mal paar Tage dauern, bis ich die ganze Texte ins richtige Regal eingestapelt habe. Also warte mal noch paar Tage und wenn es dann immernoch fehlt, erinnere mich nochmal.
-
jaja, ich bin ja schon dabei, kann auch mal paar Tage dauern, bis ich die ganze Texte ins richtige Regal eingestapelt habe. Also warte mal noch paar Tage und wenn es dann immernoch fehlt, erinnere mich nochmal.
Mein Beitrag hier ist kein Blödsinn, es dauert in der Tat manchmal paar Tag, bis die Threads im Archiv ankommen, dazu gab es wohl auch schonmal einen Beitrag von Stefan Muenz, der so hoffe ich mittlerweile im Archiv nachlesbar ist ;-)
-
Hallo!
Danke Dir!
Ich macht das aber doch nicht alles von Hand, oder? Wenn doch macht Ihr aber Eurem SLEFforum alle Ehre! Wieso macht Ihr das nicht einfach mit ner vernünftigen Datenbank, da laufen auch andere viel größere Foren mit, und die fallen auch nicht so oft aus wie das SELFforum - wohl immer wegen Überlastung, troz guter Hardware. Außerdem hat man dann nicht andauernd den Fehler "Ätsch, wird gerade ein anderes Posting bearbeitet..."!
Mit PHP oder wie Ihr wahrscheinlich bevorzugen würdet PERL und MYSQL ließe sich genau dieses Forum hier wirklich nicht schwer erzeugen, und ich bin mir trotz meines geringen Wissens im Gegensatz zu Euch sicher, das das slles viel schneller und schonender läuft.
Aber wenn das so einfach wäre hättet Ihr das wohl schon längst gemacht, oder?
Nun ja, ist nur mal eine Idee von mir, keine Kritik an Euch oder dem Forum, ein bescheidener Verbesserungs-VORSCHLAG!
Viele Grüße
AndreasPS: darüber denke ich schon lange nach und es interessiert mich wirklich warum Ihr das nicht macht!?
Grüsse
Andreas-
Ich macht das aber doch nicht alles von Hand, oder? Wenn doch macht Ihr aber Eurem SLEFforum alle Ehre!
Natürlich nicht, die Begründung hat Stefan damals afaik genannt, mußt du mal suchen, die weiß ich nicht mehr.
Wieso macht Ihr das nicht einfach mit ner vernünftigen Datenbank, da laufen auch andere viel größere Foren mit, und die fallen auch nicht so oft aus wie das SELFforum - wohl immer wegen Überlastung, troz guter Hardware. Außerdem hat man dann nicht andauernd den Fehler "Ätsch, wird gerade ein anderes Posting bearbeitet..."!
Die Ausfälle kürzlich hatten andere Ursachen, siehe News und die Sache mit dem Posting bearbeiten wurden auch schon x-mal erläutert, z.Bsp. öfter von Frank Schönmann.
Mit PHP oder wie Ihr wahrscheinlich bevorzugen würdet PERL und MYSQL ließe sich genau dieses Forum hier wirklich nicht schwer erzeugen, und ich bin mir trotz meines geringen Wissens im Gegensatz zu Euch sicher, das das slles viel schneller und schonender läuft.
PS: darüber denke ich schon lange nach und es interessiert mich wirklich warum Ihr das nicht macht!?
Ohne dich jetzt als "dumm" bezeichnen zu wollen, aber schaue dir mal die Sourcen dieses Forums an, vermutlich wirst du da erstaunt sein, auf welchem hohen technischen Niveau sich diese Forum befindet, es sieht vielleicht aus wie Matt Wright, aber die dahinterstehende technische Basis kann wohl fast jedem Vergleich standhalten: http://sf.net/projects/selfforum
Viel Spaß beim Staunen, dann wirst Du auch erkennen, warum die von Dir genannte Variante nicht unbedingt als Vorschritt zu bezeichnen wäre ;-)-
Hi!
Ohne dich jetzt als "dumm" bezeichnen zu wollen, aber schaue dir mal die Sourcen dieses Forums an, vermutlich wirst du da erstaunt sein, auf welchem hohen technischen Niveau sich diese Forum befindet, es sieht vielleicht aus wie Matt Wright, aber die dahinterstehende technische Basis kann wohl fast jedem Vergleich standhalten: http://sf.net/projects/selfforum
Viel Spaß beim Staunen, dann wirst Du auch erkennen, warum die von Dir genannte Variante nicht unbedingt als Vorschritt zu bezeichnen wäre ;-)Klar dass Ihr das alle besser wißt als ich arme Wurst an möchte-gern-nur-PHP-'Programmierer'! Und es sieht auch erstaunlich kompliziert aus;)
Leider kann ich das mit meinem Wissen noch nicht ganz würdigen, aber gestaunt habe ich schonmal! Hätte ich jetzt nicht gedacht sowas, naja, eigentlich doch. Nur was ich trotz dieses Supercodes nicht verstehe, mag ja programmiertechnisch vom anderen Stern sein, und auch ein Leckerbissen für jeden Perl-Liebhaber, nur als ich irgendwann vor kurzem mal Daten (Besucher, Traffic und Speicher glaub ich) zu diesem Forum gesehen hatte, wunderte ich mich etwas, denn soooooo viel war das auch nicht!
Ich bin mir dessen bewußt das ich mich hier wahrscheinlich ein bisschen weit aus dem Fenster lehne, aber ich frage mich ob das trotzdem viel besser ist als andere Datenbank-basierte Foren. Ihr wißt alle das ich wirklich noch viel lernen muß, aber das ist eine Sache die ich nicht verstehen kann.
Manchmal glaube ich das zuviele komplexe Prozesse auf dem Server durchgeführt werden und diser so immer sehr langsam, oder gar überlastet ist. Und ich hatte gedacht dass das bei Speicherung in einer Datenbank erheblich reduziert werden kann!Aber jetzt höre ich lieber auf bevor Ihr mich steinigt;)
Viele Grüße und entschuldigt bitte mein Unvermögen dies zu verstehen!
Andreas Korthaus
-
Hallo Andreas
Nur was ich trotz dieses Supercodes nicht verstehe, mag ja programmiertechnisch vom anderen Stern sein, und auch ein Leckerbissen für jeden Perl-Liebhaber, nur als ich irgendwann vor kurzem mal Daten (Besucher, Traffic und Speicher glaub ich) zu diesem Forum gesehen hatte, wunderte ich mich etwas, denn soooooo viel war das auch nicht!
Multipliziere die Datenmenge mal 10, dann hast du in etwa den tatsaechlichen Wert. Dass die Trafficzahlen "bescheiden" sind, liegt naemlich daran, dass hier datenkomprimiert uebertragen wird. Vielleicht ist dir schon mal aufgefallen, dass beim Laden der Forumshauptdatei nur ca. 20 KB im Schnitt uebertragen wird - die Datei ist in Wirklichkeit ca. 10 mal so gross.
Ich bin mir dessen bewußt das ich mich hier wahrscheinlich ein bisschen weit aus dem Fenster lehne, aber ich frage mich ob das trotzdem viel besser ist als andere Datenbank-basierte Foren. Ihr wißt alle das ich wirklich noch viel lernen muß, aber das ist eine Sache die ich nicht verstehen kann.
Natuerlich kann man das auch alles mit einer Datenbank machen. Aber du hast hoffentlich Verstaendnis dafuer, dass wir nicht unbedingt alles so machen wie "man" es macht, sondern dass wir hier auch ein bischen rumprobieren wollen. Hier geht es um XML-orientierte Datenverarbeitung. Vielleicht machen wir es spaeter mal anders. Aber jetzt ist es eben halt so wie es ist. Und es wird auch kein "Board" angeschafft, nur weil dieses Forum ein paar Macken hat (alle anderen haben auch Macken - man sieht sie nur meist nicht, weil kaum Traffic herrscht, oder es wird nicht drueber geredet, weil es keine Selbstbezueglichkeitskultur in dem betreffenden Forum gibt).
Manchmal glaube ich das zuviele komplexe Prozesse auf dem Server durchgeführt werden und diser so immer sehr langsam, oder gar überlastet ist. Und ich hatte gedacht dass das bei Speicherung in einer Datenbank erheblich reduziert werden kann!
Vielleicht solltest du dir einfach mal klar machen, dass dieser Server mehr Traffic hat als die Server mancher Major-Company. Trotzdem haben wir keinen 6-7stelligen Betrag uebrig, um uns mit 64-Bit-Parallelverarbeitung, 16 Prozessoren und atomsicheren Rechnern auszustatten. Wir bitten dies aufrichtig zu entschuldigen.
Aber jetzt höre ich lieber auf bevor Ihr mich steinigt;)
Ach, da liegen ja nur kleine Kieselsteinchen rum - das lohnt ja gar nicht ;-)
viele Gruesse
Stefan Muenz-
Sup!
Meinst Du nicht, man könnte ein Grundstück bekommen, daß nahe eines Glasfaserbackbonecrossbars liegt, und darauf dann, unter einer 10 Meter Betondecke, den Serverraum für den Self-Server errichten?
Ich weiss natürlich nicht, wieviel ein 13 Meter tiefes Lock, ein 10*10 Meter grosser Raum und 1000 m³ Beton kosten... aber das kann ja nicht so teuer sein, oder?
*scnr*
Gruesse,
Bio
-
Sup!
erman,
Ich weiss natürlich nicht, wieviel ein 13 Meter tiefes Lock,
ein 10*10 Meter grosser Raum und 1000 m³ Beton kosten...
aber das kann ja nicht so teuer sein, oder?wie schön, daß Du wegen <I> die Manpower für das Buddeln kostenlos zur
Verfügung stellen möchtest - das ist wirklich äußerst großzügig von Dir.Viele Grüße
Michael
-
-
Hallo Andreas
Multipliziere die Datenmenge mal 10, dann hast du in etwa den tatsaechlichen Wert. Dass die Trafficzahlen "bescheiden" sind, liegt naemlich daran, dass hier datenkomprimiert uebertragen wird. Vielleicht ist dir schon mal aufgefallen, dass beim Laden der Forumshauptdatei nur ca. 20 KB im Schnitt uebertragen wird - die Datei ist in Wirklichkeit ca. 10 mal so gross.
OK, das vergaß ich natürlich, dann sieht dass tatsächlich direkt ganz anders aus!
Natuerlich kann man das auch alles mit einer Datenbank machen. Aber du hast hoffentlich Verstaendnis dafuer, dass wir nicht unbedingt alles so machen wie "man" es macht, sondern dass wir hier auch ein bischen rumprobieren wollen.
Natürlich habe ich das, und ohne wäre das Forum auch nicht das was es ist!
Hier geht es um XML-orientierte Datenverarbeitung. Vielleicht machen wir es spaeter mal anders. Aber jetzt ist es eben halt so wie es ist.
Da frage ich mich mal wieder ob XML rein objektiv gesehen dafür nicht sher viel auwendiger ist als eine Datenbank, aber ich hab das schon verstanden, und will Euch da auch gar nicht reinreden, es interessiert mich halt warum bei dem hohen Aufkommen und "stark" beschränkten Hardware Recourcen gerade einen solch rechenintensiven Weg geht, aber wie gesagt, es ist lediglich ein Verständnisfrage(aus Interesse), keine Kritik da ich der letzte bin der sowas kompetent beurteilen könnte!
Und es wird auch kein "Board" angeschafft, nur weil dieses Forum ein paar Macken hat
Das ist ja auch Dein gutes Recht, und vollkommen in Ordnung, solange Ihr nicht nur aus falschem Eifer (wie z.B. MSIE... Einstellung macher Leute), sondern aus Eurer tatsächlichen Überzeugung begründet auf Euren Kompetenzen (und auch uns allen nutzenden Interesse solche Dinge auszuprobieren...) geschieht!
Vielleicht solltest du dir einfach mal klar machen, dass dieser Server mehr Traffic hat als die Server mancher Major-Company.
Doch, das war mir (vielleicht nicht in diesem Umfang) klar, aber daher ja auch meine Frage warum Ihr ein so rechenintensives Forum betreibt!(wobei mich gerne Korrigieren kannst wenn diese Aussage nicht korrekt ist!)
Trotzdem haben wir keinen 6-7stelligen Betrag uebrig, um uns mit 64-Bit-Parallelverarbeitung, 16 Prozessoren und atomsicheren Rechnern auszustatten. Wir bitten dies aufrichtig zu entschuldigen.
Erhlich gesagt komisch dass niemend entsprechendes(reicht ja vieleicht auch ein 5-Stelliger Betrag fürs erste) in seinem Rechenzentrum zur Verügung stellt, aber das ist ein anderes Thema.
Und ich will nochmal betonen, och will hier nichts kritisieren, da mir das mit meiner Kompetenz(noch) nicht zusteht! Ich interessiere mich nur sehr dafür und wüßte gerne warum Ihr Euch so und nicht anders entschieden habt!
Viele Grüße
Andreas-
Hallo Andreas
Da frage ich mich mal wieder ob XML rein objektiv gesehen dafür nicht sher viel auwendiger ist als eine Datenbank, aber ich hab das schon verstanden, und will Euch da auch gar nicht reinreden, es interessiert mich halt warum bei dem hohen Aufkommen und "stark" beschränkten Hardware Recourcen gerade einen solch rechenintensiven Weg geht...
Die Daten sind gar nicht so viel, jedenfalls für den Server ein Klacks. Wie schnell er wirklich ist, kannst du sehen, wenn du mal die Suche anschmeisst. Obwohl wir da indexsequentielle Suche in Groessenordnungen von ueber 100 MB betreiben, geht das ruckzuck. Die Suche allerdings soll dann auch mal in eine richtige Datenbank "irgendwann", und die Daten aus dem Forumsarchiv sollen darin auch indiziert werden. Das Forum selber ist dagegen kein so wahnsinnig irrer Datenbestand. Dass es bei hoher Frequentierung manchmal so langsam wird, liegt vermutlich an dem, was den Forums-Code so "schoen" macht - naemlich an dem fein verteilten, modularen Konzept. Das viele Einbinden anderer Module, die wiederum andere Module einbinden, ist zweifellos Programmierung State of the Art, aber diese Art der Programmierung scheint heutige Rechner doch verdammt stark zu belasten. Ein "schlampig" programmiertes Forum wie das alte Matt-Wright-Forum ist locker 100mal schneller. Aber Performanz ist eben nicht die hoechste Tugend hier: wichtiger sind und saubere Konzepte bei der Datenhaltung und bei der Software-Entwicklung.
Erhlich gesagt komisch dass niemend entsprechendes(reicht ja vieleicht auch ein 5-Stelliger Betrag fürs erste) in seinem Rechenzentrum zur Verügung stellt, aber das ist ein anderes Thema.
SELFHTML ist eben kein Tennis-Star und kein Pop-Star - da koennen wir mit unserm Sponsor-Angebot mehr als zufrieden sein ;-)
viele Gruesse
Stefan Muenz
-
-
Hi Stefan,
Multipliziere die Datenmenge mal 10, dann hast du in etwa den
tatsaechlichen Wert. Dass die Trafficzahlen "bescheiden" sind,
liegt naemlich daran, dass hier datenkomprimiert uebertragen wird.äh, mit einer solchen Aussage wäre ich denn doch _sehr_ vorsichtig.
Unsere Firma, die mod_gzip seit ein paar Wochen in einer neuen Server-
farm einsetzt, liefert bevorzugt HTML-Seiten aus, welche mit ziemlich
schauerlichem, von einer black box generierten HTML3.2-Code voller
Tabellen ohne die Möglichkeit zur Verwendung von CSS 100-200 kB pro
Seite groß sind und durch mod_gzip um Faktoren bis 25 komprimiert wer-
den können. Dies sind auch die größten Dateien unseres Produkts, und
sie machen als MIME-Typ den größten Anteil des gesamten Traffic aus.
Nach Deiner Logik würde ich also einen enormen Faktor einsparen können,
auch wenn der wahrscheinlich eher bei 10 als bei 25 liegen dürfte ...
würde man schätzen.Aber trotzdem reduziert mod_gzip die Menge der ausgelieferten Inhalte
(also das, was der Webalizer mißt) nur um einen Faktor knapp unterhalb
von 3! Die nicht komprimierten, weil nicht komprimierbaren Dokumente
(GIF, aber in unserem Falle auch CSS und JavaScript sowie alles unter
halb eines Schwellwertes, wo sich die Komprimierungswirkung gegenüber
dem CPU-Aufwand nicht mehr lohnt) machen in der Summe verglichen mit
den komprimierten HTML-Seiten doch eine ganze Menge aus.Und was tatsächlich an Traffic über die Leitung geht (also was der Provider
leisten muß), das ist noch mal erheblich viel mehr. Denn jeder HTTP-Zugriff
beinhaltet ja u. a. zwei HTTP-Header (vom Client und vom Server), die zu-
sammen etwa 600-800 bytes ausmachen. Das Apache-Log zählt diese aber nicht
mit. (Man kann mod_gzip so konfigurieren, daß es den Response-Header zur
Ausgabegrößer addiert und damit dem Webalizer wenigstens korrekte Zahlen
über das ausgesandte Volumen 'unterschiebt'; der eingehende Traffic wird
aber immer noch in der Rechnung fehlen, welche Du für das Komprimierungs-
verhältnis aufgestellt hast.)
Wenn Du jetzt noch die Verpackung auf niederen Ebenen (TCP/IP-Header) mit-
zählst, wirst Du herausfinden, daß ein HTTP-Request (Frage plus Antwort)
selbst ohne Daten einen Grund-Overhead von fast einem KB hat.
Wir messen auch den Traffic auf der Leitung (um selbige zu dimensionieren)
und haben diese Zahlen mal mit den Webalizer-Zahlen verglichen ...Bei der Ausliederung einer 200-KB-Datei ist das noch vernachlässigbar.
Wird diese auf 20 KB komprimiert, dann macht es schon 5 % aus. Verglichen
mit der Übertragung eines kleinen Markierungspfeil-GIF von gerade mal 100
Byte sind es aber 1000%! Es gibt also praktisch keine "kleinen" Bildchen.Und noch schlimmer sind diejenigen Zugriffe, die der Webalizer überhaupt
nicht zählt - diejenigen mit Statuscode 304. Der Server liefert 0 Bytes
an Nutzinformation aus - aber trotzdem geht ein KB über die Leitung.
Und das sind _viele_ Zugriffe! Selbst beim Forum mit seinem dynamischen
Inhalt weist der Webalizer 20% an 304-Cache-Validations aus; bei SelfHTML8
sind es über 40%. Diese Quote hängt natürlich u. a. auch von den Browser-
Einstellungen der Benutzer ab.Wie sagte schon Churchill: "Glaube keiner Statistik, die Du nicht selbst
gefälscht hast". In diesem Sinne:
http://www.schroepl.net/projekte/mgzta/mgzta.html
Ich gehe davon aus, daß mod_gzip für das Self-Portal mehr Ersparnis bringt
als bei dem dort beschriebenen Server, aber Faktor 4 für den effektiven
Traffic wäre schon eine sehr starke Leistung. Ich rechne eigentlich mit
weniger, auch wenn der Dateien-Mix des Portals sich für die Komprimierung
wirklich gut eignet.Ich möchte mit diesem Posting den Effekt von mod_gzip nicht klein reden.
Im Gegenteil: Der psychologische Effekt ist sicherlich höher als der meß-
bare, weil man die Wirkung bei den großen Dateien mehr spürt als die Nicht-
Wirkung bei den kleinen.
Aber bei Gesamt-Traffic-Zahlen, wie sie beispielsweise für Primekom rele-
vant wären, sollte man nicht zu enthusiastisch sein.Dennoch würde ich den Einsatz von mod_gzip besonders bei SelfHTML8 (was
bisher m. E. unkomprimiert angeboten wird und _viel_ Traffic produziert)
befürworten - im Moment sind die Webalizer-Zahlen wegen des nur sporadi-
schen Einsatzes von mod_gzip untereinander gar nicht vergleichbar. Schal-
tet das mal ein und beobachtet, wie der Traffic herunter geht, die Zahl
der Hits aber nicht ...Viele Grüße
Michael-
Hallo Michael,
Unsere Firma, die mod_gzip seit ein paar Wochen in einer neuen Server-
farm einsetzt, liefert bevorzugt HTML-Seiten aus, welche mit ziemlich
schauerlichem, von einer black box generierten HTML3.2-Code voller
Tabellen ohne die Möglichkeit zur Verwendung von CSS 100-200 kB pro
Seite groß sind und durch mod_gzip um Faktoren bis 25 komprimiert wer-
den können. Dies sind auch die größten Dateien unseres Produkts, und
sie machen als MIME-Typ den größten Anteil des gesamten Traffic aus.
Nach Deiner Logik würde ich also einen enormen Faktor einsparen können,
auch wenn der wahrscheinlich eher bei 10 als bei 25 liegen dürfte ...
würde man schätzen.
Aber trotzdem reduziert mod_gzip die Menge der ausgelieferten Inhalte
(also das, was der Webalizer mißt) nur um einen Faktor knapp unterhalb
von 3!Schauerlicher HTML-Code zeichnet sich ja auch vor allem dadurch aus, dass immer wieder was anderes angegeben wird. Normalerweise sind Kompressionsraten auch nicht so hoch wie hier im Forum. Aber guck dir mal die Forumshauptdatei an: die Wiederholung des Thread-Subjects in jedem Posting-Eintrag ist ja geradezu ein Festessen fuer den ZIP-Algorithmus!
Das mit dem Faktor 10 bezog sich auch nur auf die Forumshauptdatei. Die anderen Sachen, die noch uebertragen werden, haben natuerlich einen viel geringeren Faktor. Isg. hatten wir frueher ca. 25, bis zu 30 GB im Monat, die fuer das Forum drauf gingen. Jetzt sind es um die 20. Insofern hast du natuerlich Recht.
Dennoch würde ich den Einsatz von mod_gzip besonders bei SelfHTML8 (was
bisher m. E. unkomprimiert angeboten wird und _viel_ Traffic produziert)
befürworten - im Moment sind die Webalizer-Zahlen wegen des nur sporadi-
schen Einsatzes von mod_gzip untereinander gar nicht vergleichbar. Schal-
tet das mal ein und beobachtet, wie der Traffic herunter geht, die Zahl
der Hits aber nicht ...Jo, das stimmt, das werden wir auch noch einrichten. Es sollte zunaechst nur mal mit dem Forum begonnen werden, um zu testen, ob alles problemlos funktioniert und nicht wieder die Probleme auftauchen, die wir letztes Jahr mal mit den statischen gzips und entsprechenden htaccess-Anweisungen hatten. Da ich diesmal bislang keine einzige Fehlermeldung der Art "ich seh nur Zeichenmuell im Browserfenster" bekommen habe, wuerde nichts dagegen sprechen, die Loesung auch fuer SELFHTML einzusetzen.
viele Gruesse
Stefan Muenz-
Hi Stefan,
Aber guck dir mal die Forumshauptdatei an: die
Wiederholung des Thread-Subjects in jedem Posting-
Eintrag ist ja geradezu ein Festessen fuer den ZIP-
Algorithmus!Die von mir genannten Dateien mit den Komprimierungsfaktoren von 25 und mehr sind noch viel schrecklicher - riesige Tabellen mit tonnenweise HTML-Formatierungen, also unerschütterlich immer dasselbe, und das bei mehr als 100 Zeilen und mehr als 10 Spalten.
Da ich diesmal bislang keine einzige Fehlermeldung
der Art "ich seh nur Zeichenmuell im
Browserfenster" bekommen habe, wuerde nichts
dagegen sprechen, die Loesung auch fuer SELFHTML
einzusetzen.Eine solche Fehlermeldung wirst Du mit mod_gzip m. E. nie bekommen, weil der ja die explizite Aufforderung durch den Client als Voraussetzung verlangt. (Deshalb bekommen M$IE-Clients, welche "HTTP/1.1 verwenden" abgeschaltet haben, unkomprimierte Seiten.)
Mit dem direkten Versand von gzipped-Seiten dagegen schon - nämlich genau dann, wenn der Client das nicht versteht, der Server das aber nicht abgefragt hat.Was allerdings passieren kann, ist, daß bestimmte MIME-Typen in bestimmten Browsern nicht verarbeitet werden können. Das betrifft beispielsweise die Kombination von JavaScript (via <script src="">) bzw. CSS (via <link>) mit Netscape 4.
Leider kann mod_gzip keine 'AND'-Regeln beim Filtern, so daß man sich entscheiden muß, entweder CSS oder Netscape 4 auszuschließen.
Christian hat sich angesichts des kleinen Marktanteils von Netscape 4 entschlossen, diesen (d. h. alle HTTP/1.0-Requests, auch die meines Skin) von der Komprimierung auszunehmen.Viele Grüße
Michael-
Moin
Christian hat sich angesichts des kleinen Marktanteils von Netscape 4 entschlossen, diesen (d. h. alle HTTP/1.0-Requests, auch die meines Skin) von der Komprimierung auszunehmen.
Warum benutzt du in deinem Skin dann nicht einfach HTTP/1.1-Requests? Da mir die Kosten für das Online-Lesen des Forums langsam zu hoch wurden, hab ich mir auch was (in PHP) gebastelt, was die Hauptdatei und alle Postings lokal ablegt. Die Verwendung von HTTP/1.1 bringt dann nicht nur komprimierte Daten (was meinem Modem sehr entgegenkommt :) sondern auch gleich noch Keep-Alive als Bonus. Weitere Probleme beim Umstieg auf 1.1 gibt es nicht, da das Chunked-Encoding dass der Indianer sonst ganz gerne benutzt, von mod_gzip abgefangen wird, wie du ja schonmal in einem anderen Thread angemerkt hast.
--
Henryk Plötz
Grüße aus Berlin-
Hi Henryk,
Warum benutzt du in deinem Skin dann nicht einfach HTTP/1.1-Requests?
Da mir die Kosten für das Online-Lesen des Forums langsam zu hoch
wurden, hab ich mir auch was (in PHP) gebastelt, was die Hauptdatei
und alle Postings lokal ablegt. Die Verwendung von HTTP/1.1 bringt
dann nicht nur komprimierte Daten (was meinem Modem sehr entgegenkommt
:) sondern auch gleich noch Keep-Alive als Bonus. Weitere Probleme
beim Umstieg auf 1.1 gibt es nicht, da das Chunked-Encoding dass der
Indianer sonst ganz gerne benutzt, von mod_gzip abgefangen wird, wie
du ja schonmal in einem anderen Thread angemerkt hast.Ich benutze libwww, wie das alle Perlianer tun. Und das kann - in allen
Versionen, die älter sind als 21. Dezember 2001, nur HTTP/1.0.
Ob diese nagelneue Version neben HTTP/1.1 auch schon Content-Encoding
kann, habe ich noch nicht ausprobieren können - und bei meinem Provider
müßte ich es auch erst mal installiert kriegen.Mein Skin filtert den Inhalt so stark (auf ca. 5-30%), daß dies die
fehlende Komprimierung ungefähr ausgleich.Viele Grüße
Michael
-
-
-
-
Moin, ihr zwei!
Multipliziere die Datenmenge mal 10, dann hast du in etwa den
tatsaechlichen Wert. Dass die Trafficzahlen "bescheiden" sind,
liegt naemlich daran, dass hier datenkomprimiert uebertragen wird.äh, mit einer solchen Aussage wäre ich denn doch _sehr_ vorsichtig.
"Mein" eingesetzter mod_gzip verpackt die komprimierten Seiten mit durchschnittlich etwa 85-90%. Die gesamte Traffic-Einsparung über alle ausgelieferten Dateien kommt auf etwa 33%. Und dabei handelt es sich um eine doch relativ grafisch angehauchte Seite.
Es gibt ja auch die Möglichkeit, mittels mod_gzip ein extra Logfile auszugeben und darüber mit einem Extra-Statistikprogramm dieses auswerten zu lassen. Das Ergebnis ist ungefähr so aufgebaut wie die Webalizer-Statistik, nur eben bezogen auf komprimierte und gesamt ausgelieferte Seiten. Das Tool heißt IIRC mgstat.
Gibts das auf teamone.de schon?
- Sven Rautenberg
-
Hi Sven,
Es gibt ja auch die Möglichkeit, mittels mod_gzip
ein extra Logfile auszugeben und darüber mit einem
Extra-Statistikprogramm dieses auswerten zu lassen.
Das Tool heißt IIRC mgstat.mgstat macht genau das alles _nicht_, was ich in meinem vorherigen Posting geschrieben habe - genau wie der Webalizer auch.
Beide beziehen sich nur auf den Content der Seiten.Deshalb mußte ich mir ja selbst eines bauen ... (siehe den gesetzten Link)
Viele Grüße
Michael
-
-
-
-
-
-
-
hallo,
jaja, ich bin ja schon dabei, kann auch mal paar Tage dauern, bis ich die ganze Texte ins richtige Regal eingestapelt habe. Also warte mal noch paar Tage und wenn es dann immernoch fehlt, erinnere mich nochmal.
Mein Beitrag hier ist kein Blödsinn,
ah wirklich nicht?!?
ich könnte das fast glauben, wenn ... ja wenn es es einen Archivar geben würde. Den gibt es aber hier nicht.
grüße
thomas
-
-