Page 5 of 7

Re: Footnotes

Posted: Tue May 05, 2015 8:26 pm
by wsim123
cmb wrote:
wsim123 wrote:Man solte beide Versionen abstimmen.---
Ja. Das steht auch für CMSimple_XH 1.7 zur Diskussion.
wsim123 wrote:Das verzögerte Scrollen ist auch bei normalen Ankern zb mit oben umrahmtem DIV mit Index so. Es hängt auch von der Netzanbindung ab(Tageszeit).
Wenn die Verzögerung von der Netzanbindung ab hängt, dann ist ziemlich sicher ein Reload der Seite involviert.
Das langsame Neuladen könnte man evtl. durch ein Cachen ähnlich
https://github.com/mvdkleijn/funky_cache , das es für mehrere Cmsse angepasst gibt, beseitigen.

Re: Footnotes

Posted: Tue May 05, 2015 9:21 pm
by cmb
wsim123 wrote:
cmb wrote:
wsim123 wrote:Das verzögerte Scrollen ist auch bei normalen Ankern zb mit oben umrahmtem DIV mit Index so. Es hängt auch von der Netzanbindung ab(Tageszeit).
Wenn die Verzögerung von der Netzanbindung ab hängt, dann ist ziemlich sicher ein Reload der Seite involviert.
Das langsame Neuladen könnte man evtl. durch ein Cachen ähnlich
https://github.com/mvdkleijn/funky_cache , das es für mehrere Cmsse angepasst gibt, beseitigen.
Der funky_cache ermöglicht serverseitiges Caching. Das Scrollen auf einer Seite erfolgt aber i.d.R. ausschließlich auf dem Client, und Netzwerkverzögerungen kann man mit serverseitigem Caching auch nicht beheben. Wenn die Scriptausführung auf dem Server zu langsam ist, dann würde ich empfehlen erst einmal zu messen wie lange das Script auf dem Server braucht. Normalerweise sollten das maximal ein paar hundert Millisekunden sein, was i.d.R. verkraftbar ist. Solche Messungen lassen sich mit den Entwicklertools (F12) moderner Browser gut bewerkstelligen.

Re: Footnotes

Posted: Wed May 06, 2015 8:14 am
by wsim123
wsim123 wrote:
cmb wrote:
wsim123 wrote:Man solte beide Versionen abstimmen.---
Ja. Das steht auch für CMSimple_XH 1.7 zur Diskussion.
wsim123 wrote:Das verzögerte Scrollen ist auch bei normalen Ankern zb mit oben umrahmtem DIV mit Index so. Es hängt auch von der Netzanbindung ab(Tageszeit).
Wenn die Verzögerung von der Netzanbindung ab hängt, dann ist ziemlich sicher ein Reload der Seite involviert.
Das langsame Neuladen könnte man evtl. durch ein Cachen ähnlich
https://github.com/mvdkleijn/funky_cache , das es für mehrere Cmsse angepasst gibt, beseitigen.
------------------------------

Ich bin mit Glasfaser angebunden und das Laden von HTML-Seiten und auch das springen in Ankern geht da bltzschnell. Es liegt irgendwie auch am Cmsimple und könnte durch cachen u.ä. ganz stark verbessert werden. Wozu dient das Nachladen überhaupt ? Ausserdem würde ein blitzschnelles Laden das CMS stark aufwerten !!! Ich habe das mal anderweitig praktisch angeschaut.

Re: Footnotes

Posted: Wed May 06, 2015 12:14 pm
by cmb
wsim123 wrote:Ich bin mit Glasfaser angebunden und das Laden von HTML-Seiten und auch das springen in Ankern geht da bltzschnell.
Gut. :) Weiter oben hattest halt geschrieben: "Es hängt auch von der Netzanbindung ab(Tageszeit)."
wsim123 wrote:Ausserdem würde ein blitzschnelles Laden das CMS stark aufwerten !!!
Ja klar. Aber die serverseitige Verarbeitungszeit sollte bei CMSimple_XH weit weniger ins Gewicht fallen als bei größeren Systemen, die auch noch auf eine Datenbank zugreifen. Ich setze das Thema mal auf die Roadmap; für mich hat es aber keine hohe Priorität, aber vielleicht für andere.

Re: Footnotes

Posted: Thu May 07, 2015 6:54 pm
by wsim123
cmb wrote:
wsim123 wrote:Ich bin mit Glasfaser angebunden und das Laden von HTML-Seiten und auch das springen in Ankern geht da bltzschnell.
Gut. :) Weiter oben hattest halt geschrieben: "Es hängt auch von der Netzanbindung ab(Tageszeit)."
wsim123 wrote:Ausserdem würde ein blitzschnelles Laden das CMS stark aufwerten !!!
Ja klar. Aber die serverseitige Verarbeitungszeit sollte bei CMSimple_XH weit weniger ins Gewicht fallen als bei größeren Systemen, die auch noch auf eine Datenbank zugreifen. Ich setze das Thema mal auf die Roadmap; für mich hat es aber keine hohe Priorität, aber vielleicht für andere.
Ich möchte nur daruf hinweisen dass das vergleichbare Dokuwiki jetzt so ein Cache-Plugin für geladene Seiten standardmässig hat. Mediawiki steht in Amsterdam ganz im Cache. Wenn ich eine private Installation von Gpeasy betrachte, so ist die über doppelt so schnell im Zugriff.
Ein großer Fortschritt wäre es schon einen Wrapper zu schreiben, der einen Index anlegt und dann aus der content.htm mehrere temp-dateien anlegt, die die Hauptäste wiederspiegeln, aus denen gelesen wird. Die könnte man ja nach Größe auch im Speicher halten und zyklisch aktualisieren usw. Man muss das nur anpacken.

Re: Footnotes

Posted: Thu May 07, 2015 7:26 pm
by cmb
wsim123 wrote:Ein großer Fortschritt wäre es schon einen Wrapper zu schreiben, der einen Index anlegt und dann aus der content.htm mehrere temp-dateien anlegt, die die Hauptäste wiederspiegeln, aus denen gelesen wird. Die könnte man ja nach Größe auch im Speicher halten und zyklisch aktualisieren usw.
Requestübergreifend im Speicher halten? Das dürfte bei den wenigsten Shared-Hosting Webspaces möglich sein.

Die Indizierung des Content wurde vor längerem bereits diskutiert, und steht auf der Roadmap für XH 1.7.
wsim123 wrote:Man muss das nur anpacken.
Ja. Allerdings muss man mit beschränkten Ressourcen auch haushalten, sprich Prioritäten setzen. Und das Lesen des gesamten content.htm ist, gemäß meinen Messungen, nicht unbedingt ein besonderes Problem bzgl. der Performance (und die Performance im Allgemeinen ist kein besonderes Problem von CMSimple_XH).

Re: Footnotes

Posted: Fri May 08, 2015 9:36 am
by wsim123
cmb wrote:
wsim123 wrote:Ein großer Fortschritt wäre es schon einen Wrapper zu schreiben, der einen Index anlegt und dann aus der content.htm mehrere temp-dateien anlegt, die die Hauptäste wiederspiegeln, aus denen gelesen wird. Die könnte man ja nach Größe auch im Speicher halten und zyklisch aktualisieren usw.
Requestübergreifend im Speicher halten? Das dürfte bei den wenigsten Shared-Hosting Webspaces möglich sein.

Die Indizierung des Content wurde vor längerem bereits diskutiert, und steht auf der Roadmap für XH 1.7.
wsim123 wrote:Man muss das nur anpacken.
Ja. Allerdings muss man mit beschränkten Ressourcen auch haushalten, sprich Prioritäten setzen. Und das Lesen des gesamten content.htm ist, gemäß meinen Messungen, nicht unbedingt ein besonderes Problem bzgl. der Performance (und die Performance im Allgemeinen ist kein besonderes Problem von CMSimple_XH).
.....................................................................................................................................
Man kann durchaus messen, dass bei größeren Seiten die HTML-Dateien oben aus dem Baum schneller geladen werden als ganz unten aus dem Baum. Bei vielbeschäftigten Webservern ist das spürbar. Cmsimple ist natürlich nicht ganz langsam.
Es gibt noch eine bessere Alternative als Indizieren. Man könnte alle html-Dateien aus der content.htm in einzelne temp-Dateien auslesen. Bei einer Änderung der content.htm muss man dann gleich die entsprechende temp-datei aktualisieren.
Man könnte diese - bzw innerhalb einer gewissen Zeitspanne aufgerufene - im Cache halten und von dort absenden.
Bei Getsimple hat mal jemand ein plugin gestrickt, dass alle Dateien aus der xml-Datei ausliest und ins root kopiert.
Bei Änderungen musste man das vorher per Knopfdruck rückgängig machen(ich habe das meiste als Testversion laufen).
Das ganze mal als eine Anregung für ein schnelles Gesamtkonzept - sonst werden nur die anderen besser.....

Re: Footnotes

Posted: Wed May 13, 2015 11:57 am
by Holger
Nur mal so am Rande...

... vielleicht auch eine ganz interessante Möglichkeit für diesen Zweck, inkl. Mehrfachreferenzen usw.:
http://ckeditor.com/addon/footnotes

Demo:
http://demo.gridlight-design.co.uk/cked ... notes.html

LG
Holger

Re: Footnotes

Posted: Wed May 27, 2015 3:36 pm
by wsim123
wsim123 wrote:
cmb wrote:
wsim123 wrote:Ein großer Fortschritt wäre es schon einen Wrapper zu schreiben, der einen Index anlegt und dann aus der content.htm mehrere temp-dateien anlegt, die die Hauptäste wiederspiegeln, aus denen gelesen wird. Die könnte man ja nach Größe auch im Speicher halten und zyklisch aktualisieren usw.
Requestübergreifend im Speicher halten? Das dürfte bei den wenigsten Shared-Hosting Webspaces möglich sein.

Die Indizierung des Content wurde vor längerem bereits diskutiert, und steht auf der Roadmap für XH 1.7.
wsim123 wrote:Man muss das nur anpacken.
Ja. Allerdings muss man mit beschränkten Ressourcen auch haushalten, sprich Prioritäten setzen. Und das Lesen des gesamten content.htm ist, gemäß meinen Messungen, nicht unbedingt ein besonderes Problem bzgl. der Performance (und die Performance im Allgemeinen ist kein besonderes Problem von CMSimple_XH).
.....................................................................................................................................
Man kann durchaus messen, dass bei größeren Seiten die HTML-Dateien oben aus dem Baum schneller geladen werden als ganz unten aus dem Baum. Bei vielbeschäftigten Webservern ist das spürbar. Cmsimple ist natürlich nicht ganz langsam.
Es gibt noch eine bessere Alternative als Indizieren. Man könnte alle html-Dateien aus der content.htm in einzelne temp-Dateien auslesen. Bei einer Änderung der content.htm muss man dann gleich die entsprechende temp-datei aktualisieren.
Man könnte diese - bzw innerhalb einer gewissen Zeitspanne aufgerufene - im Cache halten und von dort absenden.
Bei Getsimple hat mal jemand ein plugin gestrickt, dass alle Dateien aus der xml-Datei ausliest und ins root kopiert.
Bei Änderungen musste man das vorher per Knopfdruck rückgängig machen(ich habe das meiste als Testversion laufen).
Das ganze mal als eine Anregung für ein schnelles Gesamtkonzept - sonst werden nur die anderen besser.....
-----------------------------------------------------------------------------------------------------
Ich habe den Ansatz einer einfachen wenn auch nicht finalen Lösung zum Chaching gefunden.

http://www.askapache.com/hacking/speed- ... ntrol.html (Caching with both mod_expires + mod_headers) und http://www.helicontech.com/ape/doc/mod_expires.htm . Zumindest lässt sich das Nachladen so beschleunigen. Das könnte man in das nächste Update einbauen, das doch wohl bis Jahresende erscheint ? meine htaccess :
Options +FollowSymlinks
RewriteRule ^post/([0-9]+)?/?([0-9]+)?/?$ /index.php?p=$1&page=$2 [QSA]
ExpiresActive On
ExpiresDefault A300
Header set Cache-Control "max-age=500"
Header append Cache-Control "proxy-revalidate"
und endlich...auch bei Strato....

Re: Footnotes

Posted: Wed May 27, 2015 8:53 pm
by cmb
wsim123 wrote:Ich habe den Ansatz einer einfachen wenn auch nicht finalen Lösung zum Chaching gefunden.

http://www.askapache.com/hacking/speed- ... ntrol.html (Caching with both mod_expires + mod_headers) . Zumindest lässt sich das Nachladen so beschleunigen.
Okay, clientseitiges Caching ist natürlich auch eine Option.
wsim123 wrote:Header set Cache-Control "max-age=500"
Also maximal für etwa 8 Minuten. Das hilft natürlich nur, wenn der Besucher die gleiche Seite beim selben Besuch mehrfach aufruft. Aber gut, dafür gehen Änderungen auch nicht unter.
wsim123 wrote:ExpiresDefault A300
Das sind, soweit ich es überblicke, aber nur noch 5 Minuten.
wsim123 wrote:Das könnte man in das nächste Update einbauen, das doch wohl bis Jahresende erscheint ?
Zumindest bisher haben wir ganz bewusst keine .htaccess im Installationsverzeichnis ausgeliefert. Bei einer Erstinstallation vielleicht kein großes Problem, aber bei Updates muss immer wieder nachgearbeitet werden, da viele Webmaster dort auch sehr individuelle Einstellungen vornehmen. Ein weiteres Problem ist, dass mod_rewrite. mod_expires und mod_headers vorausgesetzt werden; was passiert, wenn eines der Module nicht verfügbar ist – ich vermute ein "500 Internal Server Error" (also leeres Browserfenster).

Aber eigentlich sehe ich auch keinen besonderen Grund überhaupt eine .htaccess auszuliefern. Die kann sich der Webmaster doch selbst erstellen – nach Bedarf und Möglichkeiten.

Evtl. auch interessant: ein Prototyp eines Caching Plugins.