mir ist das kiffer.net im Moment zu langsam, ich will daher mal versuchen, ob ich die Inhalte der Freds nicht komplett cachen kann.

da ich nur den Produktions-Server habe, wirds mal wieder lustig...

wieviel das Cachen genau bringt, vermag ich nicht zu sagen, aber es könnte reichlich sein.

zwei kleine Nachteile stehen bereits fest:
- offtopic, editieren und weitere Links werden dann IMMER angezeigt, egal ob man das darf oder nicht
- wenn jemand seinen Namen ändert, wird das erst übernommen, wenn jemand wieder in einem Fred postet oder wenn ich den Cache komplett erneuere

das würde dann immer nachts so gegen 5 passieren, wenn am wenigsten los ist. alle Cache-Einträge, die älter als 24 Stunden sind, würden dann erneuert.

ok, also bitte keine Sorgen machen, falls hier in den nächsten Stunden mal was nicht läuft. ich seh zu, dass es möglichst zu keinen Ausfällen kommt.

täausch ich mich, oder ist alles schon ordentlich schneller geworden ?

also jetzt im Moment find ich es gerade deutlich langsamer...
das wird aber vermutlich daran liegen, dass der Cache jetzt erstmal gefüllt werden muss. bei vielen älteren Freds, an den sich ja selten was ändert, muss das aber nur einmal passieren. spätestens beim ersten Auto-Update wird das erledigt sein.

naja, bei mir ist es wirklich schnelle wie z.B. gestern.

es sind bereits 11,5 MB im Cache, insgesamt 175 Fred-Seiten.

also ich hatte bisher keine probleme von wegen langsamkeit, nagut, ich hab auch DSL....ich weiss ja nicht wieviel upstream (oderwieauchimmerdasheisst?!) der server hat.

Doch Doch... irgedndwas ist schneller...
jetzt konnte ich sogar endlich mein pic hochladen... warum es vorher geklappt hat weiss ich nicht...

Also... mehr davon... ich brauch den Speed.

bei mir lahmts voll ... und editieren geht grad nicht hille ... also ihc hab editiert und naja es hat sich nix geändert

wow, das ist doch was.... mir ist eben aufgefallen, dass es wirklich (zumindest bei mir) jetzt auch langsamer geht... ausserdem werden edits gar nicht angezeigt, und dieser Pfeil "Ab hier neue Posts" ist auch nicht mehr da.

Und jetzt ist alles verdammt langsam...

und aus irgendeinen grund ist mein wallpaper keine Tapete mehr...

huh?

und ausserdem ist gerade dein post verschwunden, hille! *wunder*

holla, was ist denn nun? so lahm wie nie zuvor..
-edit-
ok

wir sind alles elendige scheiß chatter und sollten uns jetzt mal ein wenig zurückhalten und uns entspannt nach hinten lehnen ... ein wenig im forum lesen und unsere kritik einfach mal der wand vor uns erzählen und uns statt dessen gekonnt einen finger in die nase stecken


*nasebohr* ... hille macht des schon





edit: lasst uns ein wenig lustige sms schreiben

es wird alles zunehmen wieder schneller !

...

bei mir läd die seite nur zur hälfte und reloaded sich dann automatisch so das sie komplett ist kurz danach (2 sec) läd die seite aber erneut, ist dann wieder unvollständig, dann wieder vollständig und so weiter ...

ist das ein problem deren fehler bei mir zu finden ist oder gibt es da einen anderen grund ?

ps: vieleicht hilfreich. win2k mit ie 6.0.28

bei mir läd die seite nur zur hälfte und reloaded sich dann automatisch so das sie komplett ist kurz danach (2 sec) läd die seite aber erneut, ist dann wieder unvollständig, dann wieder vollständig und so weiter ...

das müsste an Deinem Browser liegen...

win2k mit ie 6.0.28

inzwischen warnen sogar spiegel.de und die Computer-Bild...

zurück zum Thema:
ich hatte gestern 3 verschiedene Methoden ausprobiert, aber da sie alle nicht den wesentlichen Vorteil gebracht haben, den ich mir erhofft hatte, hab ich das Caching wieder komplett abgestellt. vielleicht tüftel ich irgendwann mal wieder dran rum...

btw. weiß jemand, ob und wie man eine gz-komprimierte Daten zusammensetzen kann?
hatte die Daten für's Cachen nämlich komprimiert in die Datenbank gegeben, nur musste ich dann wieder dekomprimieren und erneut komprimieren, was natürlich nicht effektiv war... und unkomprimiert mussten zuviele Daten aus der Datenbank geholt werden.

wenn ich sie aber komprimiert speichern könnte und dann in komprimierter Form mit den komprimiertem Rest der einzelnen Seiten kombinieren und ausgeben könnte, dann könnte es doch ganz gut klappen.

mh zu dein problem kann ich dir leider nicht helfen.

ich kann nur was feststellen und das is, dass der "neue posting-"balken wech is. vielleicht ist das ja gewollt aber ich wollts mal gesagt haben... *g

ist gewollt. war für die Cache-Funktion notwendig. evtl. kommt er daher auch wieder.

so, funzt nun.
sorry @ lano, lag doch am kiffer.net, ein Browser-Wechsel ist bei Dir trotzdem dringend erforderlich...


versuche bitte mal ein jeder, dieses meinige Post zu löschen.
angeblich geht das nämlich...

angeblich geht das nämlich...

nö, geht nicht...

kommt eine weiße Seite, oder?
ich werd da die Tage das Fehler-Skript hintersetzen, und es mit einem Strafkick von 5 Minuten belegen...

da wird man doch bestimmt fuer gekickt hille *g*

Hi Hille,

ich komm zwar aus der MS-Ecke (und bin auch nicht davon abzubringen. "I love .net" *g*), aber HTMLCompression ist Clientseiteig ja gleich.
Wie Du das Deinem Server beibringen kannst weiß ich nicht - sollte aber kein Problem sein (unter Apache wird es wohl mod-gzip brauchen ?!).

Ich muss dazusagen, dass ich nicht genau weiß, was das Problem ist. Ich hatte zwar ab und an eine recht langsame Verbindung und sehr lahme Antwortzeiten - Ich dachte aber, dass dies am Provider liegt.. Nunja - dem ist wohl nicht so.
Da die größten Verzögerungen beim Speichern eines Posts auftreten (zumindest bei mir) denke ich, dass es ein Problem mit der Datenbank ist - es sei denn, Du untermimmst sonst noch irgendwelche Aktionen beim Speichern(tausende eMails verschicken oder ähnliches)... Letzteres sollte z.B. auch asynchron gehen und damit den Server nicht sooo belasten.


Kompression:
Es gibt verschiedene Kompressionsverfahren, die die verschiedenen Browser akzeptieren. Die teilen Dir im Header normalerweise mit, welche Arten das sind.
gzip und deflate sind am weitesten verbreitet. gzip kann imho mittlerweile jeder.

Grundsätzlich tut's erst unter HTTP 1.1, da erst hier das Feld "Accept-Encoding" definiert ist. Ein paar Browser haben aber auch schon in Version 1.0 das Feld mitgegeben - so z.B. Netscape Communicator 4.07 (oder 4.08 oder sowas in der Richtung)
Netscape 4 kann dabei nur gzip. Allerdings mit einigen verheerenden Fehlern (wie nicht anders gewohnt bei NC4) - so dass ich hier darauf verzichten würde.

IE, Opera und Mozilla hatten auch so Ihre Probleme und Problemchen. Beim IE konnte es vorkommen, dass die ersten paar Bytes gefehlt haben und bei Opera ging Anfangs gar nichts...Weswegen viele(ich z.B. *g*) auch wieder auf HTMLCompression verzichtet haben...


Wenn Du nicht verzichten willst, dann empfehle ich, nur auf HTTP1.1-Anfragen und auch nur bei ausdrücklicher Anforderung mit komprimiertem Inhalt zu Antworten.. Der Webserver sollte sowas auch automatisch können.
Du musst dadurch Deine Daten jedenfalls auch dekomprimieren können, falls eine Anfrage nicht diesem Fall entspricht (das wäre aber mit aller Wahrscheinlichkeit ein eher geringerer Teil der Anfragen..)




Um aber mal Deine Problematik von anderer Seite aufzugreifen:

Der einfachste "Cache" dürfte sich wohl nichtmal richtig Cache nennen ;) Es ist eher eine "Erleichterung" für Dich, für den (PHP?-)Interpreter und damit auch für den Webserver.
Das parsen von XML-Daten mit XSL(T)-Strukturen ist in der Regel (je nach Parser) sehr schnell(teilweise sogar spezialisiert) - zudem kann(und sollte demnach auch) die XSL-Datei gechached werden. (Mein Hauptgeschäft sind Intra-/Extranets und da kann ich den Browser vorgeben. Daher überlasse ich die Parser-Aufgabe oft sogar dem Client, der dann auch die XSL-Datei clientseitig cached... Ich muss dann nur noch die XML-Daten übertragen)


Vorteile:
- Du erstellst (dynamisch) eine eher einfache XML-Struktur(Sie sollte einfacher sein, sonst bringts nicht viel*g*). Teilweise kannst Du dies schon "in" der Datenbank machen. So gibts es für den MS-SQLServer extra Add-Ins und Befehle nur dafür.
Dadurch kann man oft schon sehr viel Zeit sparen.
- Du musst nicht darauf verzichten, dass "editieren", "löschen", "ontopic/offtopic" nur beim berechtigten User aufgeführt wird.
- Wenn Du's geschickt anstellst (ich weiß ja nicht wie es momentan läuft), dann musst Du auch nicht auf eine google-Indizierung verzichten (z.B. wg. dämlichen Querystrings)


Bei der Datenübertragung hast Du dadurch allerdings nur wenig gewonnen (ausser vielleicht die Einsparung einiger Umbrüche zwischen den Tags - was manchmal schon enorm sein kann*g*)
Beim Aufbau der Seiten kann es dagegen eklatant werden(wie gesagt - ich weiß nicht, was Du momentan machst). Wenn Dein Perfomrance-Problem das Zusammensetzen der Daten ist (wie so oft), dann kann XML schon der richtige Gedanke sein. Denn auch das Cachen von XML-Strukturen ist (von der Logik her) etwas einfacher wie bei zusammengesetzten HTML-Dateien, da Du trotzdem für jeden User etwas "extra" machen kannst und an solchen Stellen nicht umdenken musst...
So könntest Du z.B. die Seiten, auf denen sich nichts mehr/kaum noch was ändert als XML-Datei als solches im Dateisystem ablegen und dadurch Deine Datenbank "erleichtern". Nachteil ist, dass die Posts darin eine andere Funktion zum editieren brauchen. Es lohnt sich aber in vielen Fällen (Je nach Datenbank und Datenbankaufbau).

So kann man sehr einfach auch nur Teile einer Datei Cachen (z.B. Alle Posts, aber nicht die Werbung, nicht die Who's Online-Liste und auch nicht die Liste der letzten Posts)



Wenn Dir der allgemeine Aufbau der Seiten zu langsam ist:
Durch einen vergrößertem Einsatz von CSS könntest Du einiges mehr rausholen. Es kann natürlich sein, dass ein paar (vornehmlich ältere) Browser dann nur noch Schrott anzeigen. Keine Ahnung, welche Browser Du unterstützen willst...?!

Ich seh z.B. folgendes:
<table class=balken3 style="background-color:green;border-left-style:solid;
border-left-color:#333333;border-left-width:1px;"><tr>
</td></tr></table>

Dies ist zum einen nicht ganz korrekt (TD geht nicht auf; wobei es keinem Browser was ausmachen sollte), aber zum anderen könnte es massiv vereinfacht werden. Durch das fehlende TD könnte es sein, dass ein paar Browser (Netscape Communicator 4 war so einer) viel länger für's Rendern brauchen...


Noch einfacher und schneller wird es, wenn Du erst gar nicht auf eine Tabelle zufgreifen würdest. Ist aber auch eine Browserfrage.
Tabellen verbrauchen einen haufen Speicher, da immer gleich eine handvoll Objekte zwingend enthalten sind. Auch ist das Texthandling etwas anders und das Rendern von Tabellen dauert somit länger als für andere Objekte.

<div class="balken3"></div>

mit angepasster balken3-Klasse wäre ein Ausweg. Noch besser wäre es natürlich, wenn Du die vorherige oder die darauffolgende Tabelle so anpasst, dass Du die Zeile gar nicht mehr brauchst...Aber das ist ja klar.




Naja - will ja nix schlechtes sagen. Ich find das k.net Klasse und kurze Unterbrechungen sind da eher Nebensache

Ciao,.. didge (ehemaliger MVP)

Ich versteh nur Bahnhof

Aber Respect an Didge, davon hätt ich ich auch gern mehr Ahnung! Bring mir mal was bei, ich üb dafür mit Dir Klavierspielen.

Problem ist, ich hab grad mehrere, eigentlich Grundverschiedene Themen aufgegriffen:
1xTransportprotokoll(HTTP), 4xDatenformat(XML, XSL(T), HTML, CSS), 1xDatenbank, Browserunterschiede, (Web-)Serverunterschiede.

Deswegen erscheint's wohl auch etwas umfangreicher als es eigentlich ist. Wie so oft *g*.


Daher: Frag doch einfach ;) Ich kann ja mit ner Gegenfrage anfangen: Warum hättest Du gerne mehr Ahnung und warum ist es nicht so (in der Regel kennt man sich etwas mit den Sachen aus, die man gerne gut kennen würde..) ?


Ach ja: Klavier-Spielen ist nicht so mein Ding - vielleicht ein anderer Ausgleich ;)

Ich hab nicht mehr Ahnung, weil dieses Feld einfach sooooo groß ist, daß ich nicht weiß, wo ich anfangen sollte!?
Dann mach ich meist doch andere Sachen, von denen ich mehr verstehe und deshalb komm ich nicht in die Gänge.
Bin zwar kein Vollidiot was Rechner angeht, da ich sehr viel im Zusammenhang mit Musik mit Computern arbeite, aber diese ganze Programmiergeschichte ist ein Buch mit sieben Siegeln für mich!
Als anderen Ausgleich könnte ich Dir noch Skateboard fahren anbieten, davon versteh ich was... Sonst kann ich nix!

@didgeedoo
sehr nett, aber es ist leider in Bezug auf die Geschwindigkeitsprobleme nichts dabei, was mir neu wäre. trotzdem danke!
die Komprimierung wird z.B. je nach Browser in verschiedenen Methoden bzw. gar nicht angeboten.

in der älteren Version vom kiffer.net kam das Layout sogar aus einer gecachten .js Datei, evtl. führ ich das wieder ein.

die Skripte sind ohnehin so ausgelegt, dass der Content vom Layout getrennt ist, ich hab bloss erst eine Layout-Datei.

hatte das Layout auch schon komplett auf CSS umgestellt, aber irgendwas hatte mich genervt, weiß heute nicht mehr, was...

<table class=balken3 style="background-color:green;border-left-style:solid; border-left-color:#333333;border-left-width:1px;"><tr> </td></tr></table>

das jedoch scheint tatsächlich ein Verplaner zu sein, den ich dringend abschalten sollte...

zurück zum Problem, an dem meine Idee für einen Cache krankt:

das Problem ist jedoch, dass ich einen Teil des auszugebenden Contents bereits komprimiert habe und ihn direkt mit dem noch zu komprimierenden Content zusammenfügen und dann gemeinsam ausgeben möchte. ich habe also den komprimierten $inhalt1 und den unkomprimierten $inhalt2, die beide zusammen komprimiert ausgegeben werden sollen. Quelle: SMS an Tux

das problem ist, das man eine crc32 prüfsumme zurücksenden muss beim "manuellem" senden einer gzip komprimierten seite.
wenn man es nun so wie hille macht und $inhalt1 (die beiträge des themas) und $inhalt2 (rest) einzeln komprimiert und dann zusammenfügen, dann hat man zwei verschiedene crc32 prüfsummen ($inhalt1 + $inhalt2).
da $inhalt1 aber nur komprimiert vorliegt und hille die daten logischerweise nicht nochmal dekomprimieren will, müsste man die crc32 prüfsumme von $inhalt1 + $inhalt2 "kombinieren" ... dazu fällt mir aber keine lösung ein :/

----

edit:
und nach dem absenden fiel mir die lösung ein.
einfach den unkomprimierten text in einem extra feld in der tabelle speichern und ihn dann php intern mit $inhalt2 (unkomprimiert) ergänzen um die crc32 prüfsumme zu bilden.

Vielleicht hab ich Dich ja nun halbwegs verstanden

einfach den unkomprimierten text in einem extra feld in der tabelle speichern und ihn dann php intern mit $inhalt2 (unkomprimiert) ergänzen um die crc32 prüfsumme zu bilden

Also ich glaube nicht, dass Du einfach $inhalt2 einzelnd komprimieren und an $inhalt1 anhängen kannst. Gut, gehen tut das schon, aber was kommt dabei raus *g*?

Ich kann mich -wie immer- nicht ausdrücken. Vielleicht so:
compress($inhalt1 + $inhalt2) != compress($inhalt1) + compress($inhalt2)

Und das zu -lass mich nicht lügen- fast 100%. Damit ist natürlich auch die Checksumme eine andere...
Vielleicht hast Du mit rar ganz gute Chancen, damit auch das mit etwas Zusatzaufwand funktioniert - aber so richtig überzeugt bin ich davon nicht.. Mal ganz abgesehen davon ist rar für Compressed HTML kaum von Nutzen.

das Problem ist jedoch, dass ich einen Teil des auszugebenden Contents bereits komprimiert habe und ihn direkt mit dem noch zu komprimierenden Content zusammenfügen und dann gemeinsam ausgeben möchte.

Daher wirst Du nur äusserst schwer drum rumkommen, den Inhalt unkomprimiert zu Cachen.
Einzigste Alternative die mir einfällt ist, am Ende wieder alles zu entpacken, die Inhalte zusammenzufügen und die Site entweder wieder unkomprimiert zu versenden oder nachträglich nochmals zu komprimieren. Das ist aber gleichzeitig Deine Anfangsproblematik und wirklich nicht sehr effektiv ;)

didge

Und das zu -lass mich nicht lügen- fast 100%.

Sagen wir mal ganze 100%
Aber das wird Hille auch klar sein, da bin ich mir zu fast 100% sicher

Sagen wir mal ganze 100%

Da bin ich mir nicht mehr ganz so sicher. Ich gaube mal gelesen zu haben (meine Schwester hat einen entfernten Freund und dessen Oma kannte mal ...)

Mit rar könnte es echt funktionieren. Man kann (manchmal) auch aus nicht vollständig übertragenen rar-Archiven schon Teile extrahieren. Das deutet darauf hin, dass es eben doch nach der Logik funktionieren müsste.
Allerdings würde dies auch bedeuten, dass jede enthaltene Datei(in dem Fall) einzelnd komprimiert und die Ergebnisse danach zusammengefügt wurden - was wiederum ein mehr als erhebliches sinken der Kompressionsrate zur Folge hätte.

Das Hille sowas weiß denk ich doch auch - es stand aber im Raum.