DER Zeitfresser

Hmm, das ist ja höchst interessant und sollte nicht sein, .... außer vielleicht es ist eine Stellungsfrage. An welcher Stelle in der Pluginliste steht dieses Plugin und mit welchen Optionen? Und das im Vergleich. Bei mir: "Smarty Nein Nix Nix Nein" und es steht am Ende der Liste vor dem letzten, dem entryproperties Plugin und macht nicht solche Zicken.

Gibt es Plugins die jenes aber nicht dieses Blog, oder vice versa hat?
Gibt es deaktivierte (hidden) Plugins und wenn dann welche mit Unterschieden?

Außerdem glaube ich (auf die Schnelle) man könnte das Plugin noch optimieren...

1,39 sec ist nicht optimal aber doch schon wesentlich besser als 3-4-5 Sekunden, oder?

das hielte ich für eher unbedeutend... jedenfalls nicht in diesem Maße.

Vielleicht könnte es am SVG und seiner transformation per CSS zu tun haben. Ersetze das doch einfach mal durch ein simples < und > so wie es die ohne Smarty Option auch macht.

Ich bastele inzwischen an einer Optimierung, die vielleicht innere Requests begrenzen kann.

Altes Leder halt.. ?

Lederhosen-Saga

von Börries von Münchhausen

Es war ein alter schwarzbrauner Hirsch,
Großvater schoss ihn auf der Pirsch,
Und weil seine Decke so derb und dick,
Stiftete er ein Familienstück.
Nachdem er lange nachgedacht,
Ward eine Hose draus gemacht –
Denn Geschlechter kommen, Geschlechter vergehen,
Hirschlederne Reithosen bleiben bestehen.

Er trug sie dreiundzwanzig Jahr,
Eine wundervolle Hose es war!
Und als mein Vater sie kriegte zu Lehen,
Da hatte die Hose gelernt zu stehen,
Steif und mit durchgebeulten Knien
Stand sie abends vor dem Kamin –
Schweiß, Regen, Schnee – ja, mein Bester:
Eine lederne Hose wird immer fester!

Und als mein Vater an die Sechzig kam,
Einen Umbau der Hose er vor sich nahm.
Das Leder freilich war unerschöpft,
Doch die Büffelhornknöpfe warn dünn geknöpft
Wie alte Groschen, wie Scheibchen nur –
Er erwarb eine neue Garnitur.

Und dann allmählich machte das Reiten
Ihm nicht mehr den Spaß wie in früheren Zeiten.
Besonders der Trab in den hohen Kadenzen
Ist kein Vergnügen für Exzellenzen,
So fiel die Hose durch Dotation
An mich in der dritten Generation.

Ein Reiterleben in Niedersachsen –
Die Gaben der Hose warn wieder gewachsen!
Sie saß jetzt zu Pferde, wie aus Guss,
Und hatte wunderbaren Schluss,
Und abends stand sie mit krummen Knien
Wie immer zum Trocknen am Kamin.

Aus Großvaters Tagen herüber klingt
Eine ferne Sage, die sagt und singt,
Die Hose hätte in jungen Tagen
Eine prachtvolle grüne Farbe getragen,
Mein Vater dagegen – ich weiß es genau –
Nannte die Hose immer grau

Seit Neunzehnhundert ist sie zu schaun
Etwa wie guter Tabak: braun!
So entwickelte sie, fern jeder engen Geize,
Immer neue Ästhetische Reize
Und wenn mein Ältester einst sie trägt,
Wer weiß, ob sie nicht in Blaue schlägt!

Denn fern im Nebel der Zukunft schon
Seh` ich die Hose an meinem Sohn.
Er wohnt in ihr, wie wir drin gewohnt,
Und es ist nicht nötig, dass er sie schont,
Ihr Leder ist ganz unerschöpft
Die Knöpfe nur sind wieder durchgeknöpft,
Und er stiftet, folgend der Väter Spur,
Eine neue Steinnussgarnitur.

Ja Geschlechter kommen, Geschlechter gehen,
Hirschlederne Reithosen bleiben bestehen.

JA, geh/rad ruhig mal an die Luft... Morgen ist ein neuer Tag und dann kannst du etwas weiter herumexperimentieren, denn entrypaging 1.72 ist unterwegs. ? Es wäre doch Schade um all die Mühe!

Ops, entrypaging 1.73 ist online. ?

Was es bzw sein Vorgänger macht, ist im Falle von Smarty AN einen doppelten Durchlauf der Datenbankanfragen zu vermeiden. Es hätte(?) ja sein können das es signifikanten Einfluß hat.

Wenn das durch Tests geklärt ist müssen wr weiter suchen, was diesen idle auslöst. Es gibt noch die Möglichkeit die erweiterten Plugin DB request zu überpüfen auf multilingual, categorytemplates und entryproperties. Oder abzuchecken ob mit der entrycat in relation zur entries Tabelle alles in Ordnung ist, bzw ob es überhaupt an der Schnelligkeit der einzelönen order erweiterten DB Abfragen liegt. Irgend etwas muss den entscheidenden Unterschied ausmachen der zu dieser Wartezeit führt. Wartezeit kann ja auch heißen, das etwas länger dauert, oder hakt, oder zuviel Arbeit hat... jedenfalls könnte es vielleicht interessant sein ob die time Synchronisation richtig läuft (siehe auch history hickups).

Jedenfalls darf das nicht sein und gehört herausgefunden was es auslöst!

Hört sich gut an! Und - Beat - 1-2s ist doch schon sehr viel besser als 4.5s, oder?
Macht doch mal ein Beispiel dafür, vielleicht braucht jemand anderes auch so ein Spielzeug.

Apropos Spielzeug,
Ich habe gestern und heute an der (Spartacus) Plugin Synchronsation geflickt und glaube, dass das dringend mal ausprobiert werden sollte! ?

Einmal auf "Seitenleisten-Plugins installieren" klicken (das reicht schon) und danach einmal nach "Plugins updaten" checken.
Jetzt sollten alle locationtype = 'local' sidebar plugins korrekt als sidebar plugins ausgezeichnet sein und alle in version und upgrade_version gleichermaßen bestückt sein, wenn kein sidebar update in der Warteschlange vorliegt.
PhpMyAdmin SQL Tab;

SELECT * FROM `styx_pluginlist` WHERE class_name LIKE 'serendipity_plugin%' AND pluginlocation = 'local' 

Beide 1ner, bzw insbesondere sidebarlogo mit 'event' sind falsch. Einmal über Spartacus löschen und Klickprozedur wiederholen. Danach der Gegencheck mit der SQL Anweisung.

Es geht um die 4 nebeneinanderliegenden Felder 7,8,9,10: version | upgrade_version | plugintype | pluginlocation.

Beispiel serendipity_plugin_archives  | ..... | 1.4 | 1.4 | sidebar | local | ... |

Ich weiß nicht warum du da überhaupt die Biene zusätzlich als sidebar plugin hast, vielleicht mal ausprobiert und vergessen?? Oder versteckt? Die Biene gehört wie freetag, staticpage, statistics zu den gekoppelten Plugins, d.h. das sidebar Plugin liegt mit im event plugin Ordner. Ebenso gibt es noch Plugins die zwar einzelne Ordner haben, aber durch eine Abhängigkeit verbunden sind. Trotzdem sollte ein sidebar Plugin in plugintype auch als solches ausgewiesen werden. Insofern würde ich auch die Biene einmal komplett deinstallieren und dann neu installieren. Das sidebar Plugin ist Statistik und (eher) wertlos! (und hält den ganzen Laden auf!) Wir wollen ja die Biene als Schnellfeuerwaffe gegen Spambots.

Dein 2. Kommentar scheint einem Missverständnis aufgesessen zu sein. Feld 2, 3 und 4 (class_name, plugin_class, pluginPath) beschreiben die möglichen Konditionen des eben ausgeführten, sowie noch eine ungenannte weitere. Davon ist zur Erkennung ob es sich tatsächlich um ein Seitenleisten Plugin handelt eigentlich nur class_name wichtig. Zur Erkennung ob es 'local' vorhanden ist, siehe 1. Feld (plugin_file) und 10. Feld pluginlocation. Sehr wahrscheinlich sind die 4 also im class_name eben die Seitenleisten Plugins der gekoppelten event Plugins (in pluginPath) die du irgendwann einmal installiert hattest und "vielleicht" sogar aktiviert, oder versteckt sind, oder deaktiviert aber nicht physikalsch gelöscht sind (was ja angesichts ihres gekoppelten Zustandes auch völlig ok ist).

"Über Spartakus löschen" meint via Backend/Plugins anklicken und löschen. Richtig?

?

Das sieht jetzt gut aus! Komisch allerdings ist, dass ich ja nicht irgendwie remote herumgespielt hätte, sondern nur hier auf blog.doku einmal Event Plugins installieren getriggert habe. Das war es schon. Warum das praktisch gleich zu beatblog ist kann eben nur sein wenn du dort ebenso schon tätig gewesen bist. Die Reihenfolge ist etwas merkwürdig, aber vielleicht ist dort doch nicht alles haargenau so wie hier. Warum stehen bei beiden eigentlich eventwrapper und bee sidebar? Hattest du sie nach der Blog Installation ausprobiert und aus der Liste wieder gelöscht? Oder ist das eine Folge der Übernahme der db Daten?

Bei den entrypaging Ausgaben wundert mich eben folgendes. Hier auf doku wird unter Wartung - Plugin Zombies das entrypaging event und das Biene event Plugin angezeigt, obwohl beide ja valide installiert sind. Das darf eigentlich nicht sein, so dass ich annehme, dass beide eine falsche bzw keine Einstellung im upgrade Feld haben. Da das auf beatsblog anders aussieht, würde ich dich bitten dort einmal auf Plugins Zombies zu checken.

So soll das sein. Genau!

Also fehlt hier nur der Nachtrag der upgrade_version in der local Variante. Die Frage ist, warum es dort nicht drinnen ist. Ich nehme aber stark an, dass es aufgrund der developer Versionen und der lokalen dev Updates über FTP passiert ist, also nichts, was in einem normalen System geschehen kann. Bitte check auch noch mal

SELECT class_name,version,upgrade_version,plugintype,pluginlocation FROM `styx_pluginlist` WHERE class_name LIKE '%spamblock_bee'

auf beiden Blogs. Es müsste ähnlich aussehen wie bei entrypaging.

Nochmal zum "Zeitfresser" ...  Blogs mit wenig bzw keinen zugeschalteten Extras wie Sidebar Comment, Mediatheks und History Abfragen usw. und keinen bis sehr reduziert ablaufenden event hooks usw. sind natürlich an sich schon schnell genug und können sich locker im 30-50 ms Bereich der Content-Zusammenstellung bewegen.

Hier - bei einem anderen Anbieter - ist, finde ich, schön und nachvollziehbar erklärt, warum der, dem Apachen vorgeschaltete, Nginx cache auf hostech so schön schnell ausliefern kann. Laut Chrome sind es auf Eintrags-Einzelseiten unter ~500ms gegenüber ~2,0s auf Manitu, also nur ein Viertel. Er reduziert die Warteschleife der Zusammenstellung durch einen vorgehaltenen Cache. Vielleicht kann man ja Manitu dafür begeistern lernen. (Und damit ist, nur zu Feststellung, nicht der Varnish Cache gemeint, der viele Probleme mitbringt und m.E. nicht zu empfehlen ist.)

https://www.hosteurope.de/faq/webserver-dedicated/allgemeines-webserver/nginx-cache/