Smarty - sehr lange Ladezeit

[Schrödi]

Hallo zusammen,

ich habe ein Problem bezüglich Smarty und der Ladezeit:


included templates & config files (load time in seconds)
index.tpl (35.60371) (total)
test.conf [setup] global (7.45915)
header.tpl (7.73908)
footer.tpl (7.40543)


Der Auszug in blau stammt aus der Smarty Debug Konsole und bezieht sich auf das bei Smarty beigelegte Demo.

Das Scipt läuft auf einem IIS 6.0 Server unter php 5.

Die Ladezeiten sind katastrophal, jedoch nur in Verbindung mit Smarty. Den Server benutze ich schon etwas länger; selbst geschriebene Scripte, teilweise auch mit großen Datenabfragen (>25000 Datensätzen) und entsprechenden Berechnungen laufen problemlos und das sogar mit 'relativ' guten Zeiten.
Auch JPGraph habe ich am laufen und füttere das Ding mit vielen Daten -> Auch die Grafikerstellung und Berechnung läuft gut.

Deshalb fällt es mir schwer eine Erklärung dafür zu finden.


Hat schon jemand Erfahrungen mit Smarty bzw. der Kombination Smarty - IIS gesammelt?

Kennt vielleicht jemand ein php basierendes Tool um alle wichtigen Eigenschaften des Servers auf Geschwindigkeit zu testen?
Wichtig hierbei ist mir die Generierung von Dateien durch php (Smarty Cache Geschw.), sowie das Lesen und Abarbeiten von Dateien (Smarty parse Geschw.)


Gruß Schrodi

 

[Radhad]

Windows & PHP ist ja (noch) kein gutes Paket, gerade was die Performance betrifft. Da Smarty eine Template Engine auf einer Template Engine (PHP selbst) ist, könnte es durchaus sein, dass das parsen von Dateien unter Windows einfach schlecht umgesetzt ist und daher die extrem langen Zeiten zustande kommen.

 

[Schrödi]

Hi,

habe jetzt Template_Lite ausprobiert, das läuft ohne Probleme, somit sollte der Server auch problemlos laufen.
Soweit ich mich jetzt eingelesen habe ist temp_lite lediglich ein abgespecktes smarty.

Warum läuft das eine jetzt sehr gut, und das andere absolut besch***?

Die Demos der Templates sind sehr klein gehalten und sollten folglich kein Performanceunterschied aufweisen.

 

[Radhad]

Ich frage mich ja generell, wozu soll man Smarty einsetzen, PHP ist für den gleichen Kram gedacht und entwickelt worden ...


Smarty hat einen rieeeeesigen Rattenschwanz - es ist total aufgebläht, wahrscheinlich auch schlecht / unsauber programmiert. Und dann halt die Kombination WIndows/PHP, wo eh nicht so viel Power vorhanden ist wie unter Linux/PHP auf dem gleichen Rechner, ich denke da kommt einiges zusammen.

Diese andere Template-Engine verwendet wahrscheinlich nur die selbe Syntax wie Smarty, dürfte aber besser programmiert sein und sicherlich auch einige wenig bis selten benutzte Funktionen einfach nicht implementiert haben. Dadurch muss die Template-Engine auch nicht so viel überprüfen und ist somit schneller & erzeugt auch nicht so eine hohe Last auf dem Server.

 

[Schrödi]

Tools ála Smarty sollen die saubere Trennung zwischen Design und Code vereinfachen. Mann mus z.B. die Funktionen nicht selbst entwickeln, sondern kann die mehr oder weniger flexiblen Funktionen von Smarty und Co. nutzen.

Ich werde mich jetzt jedenfalls daran machen Template_Lite in der Praxis zu testen. Dann kann ich auch für mich entscheiden, ob solch ein Template System praiktisch, oder nur ein Griff ins Klo ist.

Zu Microsofts IIS:
Ich würde einiges dafür geben, eine halbwegs gescheite Linuxmaschine nutzen zu können. Ist mir leider nicht gegeben (FirmenIntranet). Deshalb muss ich mit dem leben, was mir gegeben wird.

Zu den selten benutzten Funktionen:
Beide TL Systeme die ich mir jetzt angeschaut habe basieren auf Plugins und somit bis auf die Hauptfunktionen relativ individuell und performancebezogen angepasst werden.

Lange Rede - kurzer Sinn, Smarty ist für mich gestorben.
Ich werde mich jetzt unter dem Motto 'Probieren geht über Studieren' an Template Lite wagen. Wenn gewünscht folgt später auch noch ein Fazit.

 

[Radhad]

Tools ála Smarty sollen die saubere Trennung zwischen Design und Code vereinfachen. Mann mus z.B. die Funktionen nicht selbst entwickeln, sondern kann die mehr oder weniger flexiblen Funktionen von Smarty und Co. nutzen.

Das ist immer das Hauptargument von Smarty-Verfechtern, aber genau dafür ist PHP selbst auch gedacht. Das geht mit den Boardmitteln, ohne eine langsame Parser-Schicht zu implementieren.

Das 2. beliebte Argument ist: der Designer muss kein PHP lernen. Dafür lernt er aber die gleichen Befehle in der Smarty-Script-Sprache - also kann er auch eben die paar Befehle (echo, if, else, foreach, for reichen in 99% völlig aus) in PHP lernen, das macht gar keinen Unterschied. PHP selbst ist eine Template Sprache für HTML, man muss sie nur richtig dafür einsetzen!

 

[Schrödi]

Ich wollte jetzt keine Diskussion beginnen, wie sinnvoll ein solches System ist.
Dazu habe ich gar nicht das Hintergrundwissen. Ich beschäftige mich jetzt erst seit ein paar Tagen mit Smarty. und deshalb bin ich auch kein Smarty Verfechter. Ich wollte lediglich meinen Horizont erweitern.
Wozu php im allgemeinen fähig ist, ist mir schon klar. Damit beschäftige ich mich nun schon seit mehreren Jahren, in denen ich mehrere große Pojekte zum Laufen gebracht habe.

Damit möchte ich auch nun zu meinem Fazit kommen.

Ich muss sagen, dass unter bestimmten Bedingungen Smarty einige Vorteile und Vereinfachungen bietet (z.B. erspart man sich das Ertellen eigener Klassen und Funktionen bezüglich HTML Generierung).
Dass man dann kein php mehr können muss sehe ich nicht so. schließlich muss man die Smarty Variablen ja auch füttern.
Auch bin ich der Meinung, dass die Trennung von HTML und PHP sauberer von statten geht, als ohne Smarty & Co., ...

... jedoch (jetzt kommen die Nachteile) nur auf Kosten der Überichtlichkeit der Dateistruktur. Wenn man die Tennung wiklich sauber halten möchte, benötigt man doppelt so viele Dateien. Auch wenn man hier wirklich Ordnung hält, schränkt dies die Übersichtlichkeit enorm ein.
Die Performance geht in die Knie. Nachdem ich ein paar Daten berbeitet hatte und auch Datenbankabfragen mit eingebunden habe steigerte dies die Wartezeit enorm. (Linux Server haben hier vielleicht nicht so viele Probleme, aber wie schon gesagt kamm man ich die Rahmenbedingungen nicht immer aussuchen).
Das größte Manko sehe ich in der Inkompatibilität mit Javascript (oder auch anderen Client basierten Scriptsprachen). Hier gibt es zwar mehrere Möglichkeiten Javascript einzubinden, jedoch nur auf sehr umständlichen Möglichkeiten.
Weil ich u.a. auch viel mit Javascript -> Ajax arbeite, habe ich ab diesem Punkt endgültig die Templatesysteme begraben.

Wie auch immer. Eine Erfahrung war es wert und ich weiß jetzt auch was diese Syteme leisten können oder auch nicht