Kategorien
Misc Statistik Wordpress

Kleinvieh macht auch Mist

In einer Vorlesung haben wir gelernt, dass 20% aller Aufrufe in Programmen Sprünge sind und die Top10 der Aufrufe zusammen 96% aller aufgerufenen Befehle ausmachen. Das kann man auch für PHP/Wordpress mittels APD herausfinden (auf einem höheren Level). Sortiert nach der Anzahl der Aufrufe sieht man, dass eben auch Kleinvieh Mist macht. Ich frage mich, ob man da nicht massiv optimieren kann. So oft wie strlen und mysql_fetch_object aufgerufen werden, dass kann nicht normal sein.

Hier die Aufrufe nach Anzahl der Calls sortiert:

         Real         User        System             secs/    cumm
%Time (excl/cumm)  (excl/cumm)  (excl/cumm) Calls    call    s/call  Memory Usage Name
--------------------------------------------------------------------------------------
 15.1  0.16  0.16   0.13  0.13   0.01  0.01  4414   0.0000    0.0000            0 mysql_fetch_object
 12.6  0.11  0.11   0.11  0.11   0.01  0.01  4123   0.0000    0.0000            0 strlen
  6.7  0.07  0.07   0.06  0.06   0.00  0.00  2002   0.0000    0.0000            0 substr
  7.2  0.07  0.07   0.07  0.07   0.00  0.00  1711   0.0000    0.0000            0 preg_replace
  2.0  0.02  0.11   0.02  0.09   0.00  0.00  1674   0.0000    0.0000            0 cachedfilereader::read
  3.0  0.02  0.09   0.03  0.09   0.00  0.00  1664   0.0000    0.0000            0 cachedfilereader::seekto
  4.7  0.04  0.04   0.04  0.04   0.01  0.01  1084   0.0000    0.0000            0 str_replace
  1.3  0.01  0.01   0.01  0.01   0.00  0.00   670   0.0000    0.0000            0 array_slice
  3.0  0.03  0.03   0.03  0.03   0.00  0.00   670   0.0000    0.0000            0 func_get_args
  1.9  0.02  0.02   0.02  0.02   0.00  0.00   670   0.0000    0.0000            0 merge_filters
  1.1  0.01  0.18   0.01  0.16   0.00  0.01   663   0.0000    0.0000            0 apply_filters
  1.6  0.02  0.02   0.02  0.02   0.00  0.00   624   0.0000    0.0000            0 mysql_num_fields
  3.2  0.02  0.02   0.03  0.03   0.00  0.00   575   0.0000    0.0000            0 mysql_fetch_field
  2.4  0.01  0.01   0.02  0.02   0.00  0.00   534   0.0000    0.0000            0 date
  3.8  0.04  0.04   0.03  0.03   0.00  0.00   533   0.0000    0.0000            0 strstr
  1.1  0.01  0.01   0.01  0.01   0.00  0.00   315   0.0000    0.0000            0 defined
  0.2  0.00  0.10   0.00  0.09   0.00  0.00   303   0.0000    0.0000            0 get_settings
  0.7  0.01  0.01   0.01  0.01   0.00  0.00   286   0.0000    0.0000            0 is_array
  0.2  0.00  0.02   0.00  0.01   0.00  0.00   212   0.0000    0.0000            0 smiliescmp
  0.0  0.00  0.01   0.00  0.01   0.00  0.00   160   0.0000    0.0000            0 backslashit

Noch beeindruckender, die Top20 beim Schreiben eines Artikels:

         Real         User        System             secs/    cumm
%Time (excl/cumm)  (excl/cumm)  (excl/cumm) Calls    call    s/call  Memory Usage Name
--------------------------------------------------------------------------------------
 51.5  3.75  3.75   1.54  1.54   0.11  0.11  60622   0.0000    0.0000            0 intval
 11.0  0.94  0.94   0.33  0.33   0.02  0.02  14911   0.0000    0.0000            0 preg_replace
  9.1  0.59  0.59   0.27  0.27   0.02  0.02  10017   0.0000    0.0000            0 str_replace
  3.0  0.22  0.22   0.09  0.09   0.01  0.01  4157   0.0000    0.0000            0 strstr
  3.0  0.24  0.24   0.09  0.09   0.00  0.00  3994   0.0000    0.0000            0 strlen
  2.3  0.13  0.13   0.07  0.07   0.00  0.00  2023   0.0000    0.0000            0 substr
  0.6  0.05  0.25   0.02  0.11   0.00  0.00  1674   0.0000    0.0000            0 cachedfilereader::read
  0.8  0.02  0.15   0.02  0.08   0.00  0.00  1664   0.0000    0.0000            0 cachedfilereader::seekto
  0.9  0.09  0.10   0.03  0.04   0.00  0.00  1431   0.0000    0.0000            0 merge_filters
  3.2  0.26  0.26   0.10  0.10   0.00  0.00  1431   0.0000    0.0000            0 func_get_args
  0.8  0.03  0.03   0.02  0.02   0.00  0.00  1431   0.0000    0.0000            0 array_slice
  0.8  0.04  1.91   0.03  0.81   0.00  0.05  1423   0.0000    0.0000            0 apply_filters
  1.0  0.03  0.03   0.03  0.03   0.00  0.00  1047   0.0000    0.0000            0 mysql_fetch_object
  0.8  0.06  0.06   0.03  0.03   0.00  0.00   987   0.0000    0.0000            0 is_array
  1.4  0.04  0.04   0.05  0.05   0.00  0.00   669   0.0000    0.0000            0 count
  0.3  0.05  0.05   0.01  0.01   0.00  0.00   471   0.0000    0.0000            0 defined
  0.3  0.02  0.26   0.01  0.12   0.00  0.01   459   0.0000    0.0000            0 get_settings
  0.4  0.13  0.13   0.01  0.01   0.00  0.00   420   0.0000    0.0000            0 sprintf
  0.7  0.07  0.07   0.02  0.02   0.00  0.00   363   0.0000    0.0000            0 preg_split
  0.2  0.03  1.55   0.01  0.64   0.00  0.04   361   0.0000    0.0000            0 wptexturize

15 Antworten auf „Kleinvieh macht auch Mist“

Tja … das mysql_fetch_object kommt aus einer einzigen Zeile in der wp-db.php. Wird andauernd für jede Zeile einer Datenbankabfrage ausgeführt. Dem ist schwer entgegenzuwirken, da nun mal alle WordPressfunktionen das ganze in dem Format brauchen.

Und ein „WordPress nano“ gibt es schon hier: lightpress.org. Läuft schneller als das Original ;-)

Ich hab ja schon mal vor einiger Zeit angedeutet, dass es sich meiner Vorstellung entzieht wofür ein Blog, und sei es auch so komplex wie dieses System hier, für die Darstellung einer einzigen Seite eine Anzahl Queries im mittleren zweistelligen Bereich benötigt. Mindestens die Hälfte davon laufen wohl für Funktionalitäten unter der Haube und könnten bestimmt leicht reduziert werden wenn das Datenmodell schlauer wäre, die andere Hälfte dient dann wohl zur Seitendarstellung und könnte sicherlich auch stark optimiert werden.

Abstraktion und Optimierung stehen sich bei der Modellierung einer Anwendung immer gegenüber, und je nach Art der Anwendung sollte man trotzdem nicht allzu weit vom Mittelweg abweichen. Hinzu kommt noch, dass PHP so ziemlich die langsamste Webtechnologie ist, und aufgrund fehlender Typisierung und anständiger Fehlermechanismen geht für ein halbwegs stabiles Produkt gleich nochmal eine gute Menge Rechenaufwand drauf, weil man das selbst irgendwie einbauen muss.

*läster*

Man merkt vielleicht ich bin kein besonders großer Fan von diesem Ding ;-) Noch dazu weil ich nicht sehe wohin der ganze Aufwand des Programmes fließt, Sebbi sagte einmal für einen durchschnittlichen Seitenaufruf wird knapp ein Megabyte Skript geparst und verarbeitet. Das kanns ja wohl nicht sein. Noch dazu sehen wirklich alle Seiten die mit WordPress laufen irgendwie gleich aus. Mag am kreativen Mangel der Theme-Designer liegen, spricht aber trotzdem nicht unbedingt für das Produkt an sich.

Okay ich geh jetzt mal was essen. Flame me, if you can :twisted:

Stimmt schon. Bei WordPress läuft da im Hintergrund ziemlich viel ab, was man nicht merkt oder eigentlich auch selten gebraucht wird. Im Prinzip ist ja einfach nur Text aus einer Datenbank, der einfach nur angezeigt werden muss und fertig. Deshalb gibt es ja auch Lightpress, das alles anders macht.

Wie auch immer … im Prinzip hat PHP alles was eine Skriptsprache braucht und mit Version 5 auch so ziemlich alles andere. Ob man es mag ist eine andere Sache, Python ist noch recht interessant, Perl ist einfach nur krank und Java für Webseiten? Nunja … da muss erst noch eine mich überzeugende Lösung kommen bevor ich das anfasse ;-)

Was hast du gegen Java? Es ist sicherlich out-of-the-box nicht so gut für Webanwendungen geeignet, aber auch PHP lebt nur durch seine Erweiterungen. Dafür ist es klar spezifiziert, man kann sich als Entwickler sicher sein dass Sprachkonstrukte und Klassenfunktionalität auch nach zwei Minor-Versionen noch erhalten sind, und es ist verflucht schnell. Ich hänge damit jede geparste oder interpretierte Skriptsprache ab, inklusive Perl und Python.

Allerdings die Schuld dass Java nicht stärker im Web vertreten ist sehe ich bei Sun, JSP, der ASF und nicht zuletzt bei den Providern. Jemanden zu finden der für bezahlbares Geld einen Servletcontainer hostet ist fast unmöglich. Und sicherlich ist PHP wesentlich populärer weil man damit mal einfach eben draufloslegen kann, auch wenn man nicht so viel Ahnung von Programmieren und Softwaredesign hat. So sehen die meisten Projekte dann ja auch aus.

Danke für die Info über lightpress – vielleicht kann man das ja mal gebrauchen, aber eigentlich bin ich über google hierher gekommen, weil ich nach einer Text-DB-basierten Version von WordPress gesucht hatte *g* Sowas soll’s ja geben und ich hoffe mal, dass die auch etwas flinker als das Original ist. Aber selbst wenn nicht – Hauptsache, ich brauche keine mySQL-DB, die ja bekanntlich nicht (immer) in den preiswerten Hostingpaketen integriert ist. Gerade wenn man ein Blog nur als kleinen Zusatz zu einer Webseite integrieren möchte, ist eine SQL-DB einfach nur Ballast …

Ich bin mir nicht sicher, ob es für WordPress eine derartige Erweiterung gibt. Allerdings gibt es Blogsoftware, die ihre Daten nicht in einer Datenbank ablegen. Z.B.: Blojsom, Blosxom, MovableType und Pivot. Vielleicht klappt es ja mit dem ein oder andere für dich.

Hoster mit Skriptsprachen, aber ohne Datenbank? Wo gibt es denn so etwas? :-)

Es soll solche Leute geben, die für eine zusätzliche Datenbank nochmal schön auf die Rechnung draufpacken. Ist zwar nicht mehr zeitgemäß, aber es gibt schon noch kleine Hosting-Pakete bei denen keine Datenbank angeboten wird.

Hat WordPress denn keine SQLite-Unterstützung?

WordPress verwendet eine etwas eigentümliche (und alte) Klasse zur Abstraktion der Datenbankzugriffe. Neuere Versionen davon unterstützen verschiedene andere Datenbanksysteme, aber die aktuell verwendete eben nur MySQL. Allerdings gibt es eine Mailingliste in der eventuell mehr Informationen darüber zu finden sind, ob und wie andere Systeme unterstütz werden oder das geplant ist …

Interessante Architektur. Man fügt eine Abstraktionsschicht ein, die nur mit einem einzigen, unterliegenden System arbeiten kann. Verdichten sich da erneut meine Theorien über WordPress?

(Noch zwei!)

Aber! Ein kleines bis mittelschweres aber:

Will ich’s besser machen? Fürs erste eigentlich nur selber und infolgedessen auch anders.

Microsoft hat ja auch sehr großen „Erfolg“ mit dem „Produkt“ und dessen Neuauflagen SE (Same Errors), Me (More errors) und XP (expensive).

dumdidum … eintausendeins :crazy:

Auf der Suche nach einer sqlite-Version von WordPress bin ich mal wieder hier vorbei gekommen *g* Ich hatte kürzlich irgendwo auf der WordPress-Seite einen Link zu einer solchen Version entdeckt, mir diese gezogen, bekomme sie aber bisher nicht zum Laufen (übrigens die Version, die Sebbi am 6.9.2006 hier verlinkt hat). Auf jeden Fall gibt es einige Lösungen mit WordPress und SQLite, z.B. hier: http://wiki.wordpress.org/?pagename=MultiBlog wird auch ein solcher Versuch angesprochen. Interessant könnte auch die WordPress-Alternative Serendipity sein, weil das System mehrere Datenbankformate unterstützt.

Wegen der Frage, was ich für einen Hoster verwende: größtenteils Strato ;) Das PowerWeb A hat aktuell alles mögliche, nur eben keine mySQL-DB, die wird in dem Paket allerdings ab nächsten Monat mit allerhand anderen verbesserten Eigenschaften für 1 Euro mehr auch dabei sein. Man kann dort bei Strato zwar bereits seit Mitte des Jahres einen SQLite-Blog einrichten, dummer Weise liegen die Scripte allerdings im cgi-bin, welches ich jahrelang für Bots gesperrt hatte und Google will dadurch bedingt dort nicht mehr rein. Da kann man die robots hundert mal anpassen …

Ok, man muss einfach nur mal die Fehlermeldungen richtig lesen – ich kann sqlite-basierte Datenbanken in meinem Strato-Paket nicht zum Laufen bringen, das geht erst ab den viel zu teuren Premium-Paketen :'( Intern bieten allerdings auch die kleineren PowerWeb-Pakete diese Unterstützung irgendwie für vorgefertigte Features an, eben nur nicht für selbst installierte Systeme.

Kommentare sind geschlossen.