• Jeder User im Forum verpflichtet sich zur Akzeptanz und zur Einhaltung dieser Regeln:
    1. Umgangston
      Ein angemessener höflicher Umgangston, ohne Beleidigungen, Beschimpfungen und aggressive Postings ist für jedes Mitglied Pflicht.
    2. Beiträge
      Jedes Mitglied sollte sich bemühen nur sinnvolle Beiträge zum Thema zu posten. Dabei ist unbedingt vorher zu prüfen, ob das Thema vorher schon einmal diskutiert wurde und daher fortgesetzt werden kann
      • Suchfunktion benutzen!
      • offizielle Doku lesen!
    3. Haftung
      Jeder Beitragsersteller übernimmt die alleinige Verantwortung seiner Inhalte.
    4. Werbung
      Wir erlauben keine Beiträge, Signaturen, Private Nachrichten oder eMails an Benutzer, die Werbung enthalten. Ausgenommen
      sind Stellengesuche /-angebote, welche ausschließlich im Forum "Stellengesuche" veröffentlicht werden dürfen.
    5. Verstöße
      Regelwidrige Beiträge sollten dem Team gemeldet werden. Nach deren Überprüfung werden wir schnellstmöglich
      entsprechend handeln.
    6. Authorität
      Den Anweisungen der Team-Mitglieder (Administratoren und Moderatoren) sind in diesem Forum Folge zu leisten.
      Bei Fragen oder Beschwerden bitte an diese wenden.
    Wir möchten Euch darauf aufmerksam machen, dass es bei Verstößen gegen einen oder mehreren der oben genannten
    Punkte dem Team frei steht entsprechend zu handeln. Dies kann z.B. das Löschen eines Beitrags, das Ausschliessen bzw.
    Sperren von Mitgliedern oder aber lediglich eine Verwarnung sein.

    In diesem Zusammenhang sollte erwähnt werden, dass das Forum automatisch die IP-Adresse jedes Beitrag-Erstellers
    speichert. Bei schweren Vergehen, behalten wir es uns vor, die IP-Adresse zur Strafverfolgung weiterzugeben.
  • Willkommen im Zend Framework Forum

    ZF1 Zend Framework 1 + ZF2 Zend Framework 2

    Das Zend Framework Forum ist seit 2006 die erste Anlaufstelle für Zend Framework Entwickler in Deutschland. Mit über 70.000 Beiträgen und einer steigenden Nutzerzahl bietet das Forum hilfreiche Themen und ZF-Tutorials für professionelle Entwickler, fortgeschrittene Programmierer sowie Zend Framework Einsteiger.
    Wenn dies Dein erster Besuch in der Zend Framework Community ist, lies bitte zuerst die Hilfe - FAQ durch. Du musst Dich registrieren, bevor Du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um die Registrierung zu starten. Du kannst auch jetzt schon Beiträge lesen. Hier im Forum findest Du die Zend Framework Hilfe, die Du suchst!

    Grüße an alle Zend Framework Entwickler. Das Team vom Zend Framework Forum!

    Drupal Agentur

Zf Performance

christian1987

New member
Hallo,

ich weiß nicht, ob ich hier richtig bin. Habt ihr schonmal die Performance eurer zf Anwendung untersucht? Ich mache das mit xdebug und WinCacheGrind.

Frage: Wie lange dauert bei euch so das bootstrapping eurer Anwendung? Bei mir liegt der Wert bei 305ms und das bereitet mir etwas Sorgen.

Folgende Komponenten werden in meiner Application.ini konfiguriert:

- MVC
- Modules
- Layouts
- View
- Database
- L10N
- I18N
- Cachemanager
- Logging
- ViewHelper
- Controller Plugins

Zweite Frage: Ich hatte mir einen View_Helper geschrieben, der bei einem DATETIME aus der Db den Wert, basierend auf der Locale, entsprechend zurückgibt. Für große Tabellen in der View (modified und created timestamps) hat das doch ziemlich gedauert, weswegen ich mir sicher bin, dass der View Helper schlecht ist. Vielleicht nicht unbedingt schlecht, aber das berechnen des korrekten Datums dauert halt etwas. Gibt es vielleicht bessere Wege, um das zu realisieren?

PHP:
class Foo_View_Helper_Date extends Zend_View_Helper_Abstract
{
    public function date($date)
    {      
        $date = new Zend_Date($date);
        $output = $date->get(Zend_Date::DATETIME_MEDIUM);
        return $output;
    }
}
Pls, wie geht das? :'(


--Christian

P.S.: Vielleicht sollte ich noch erwähnen, dass ich auf einer virtuellen Maschine entwickle. Host ist ein Intel Core Duo 6400 ~2,13Ghz und 4 Gb DDR2 800.
 
Zuletzt bearbeitet:

flod

New member
Ich habe die Erfahrung leider machen müssen, das Zend Date vorallem bei mehreren Schleifendurchläufen echt lahm ist.

Oft habe ich zb bei Datums Vergleichen, das Datum vor der schleife in den Unix Timestamp umgewendelt und mit diesem dann verglichen statt zb in der Schleifen jedesmal das Zend Date Object zubenutzen.
 

Kaiuwe

Super-Moderator
Ich hatte mir einen View_Helper geschrieben, der bei einem DATETIME aus der Db den Wert, basierend auf der Locale, entsprechend zurückgibt. Für große Tabellen in der View (modified und created timestamps) hat das doch ziemlich gedauert, weswegen ich mir sicher bin, dass der View Helper schlecht ist. Vielleicht nicht unbedingt schlecht, aber das berechnen des korrekten Datums dauert halt etwas. Gibt es vielleicht bessere Wege, um das zu realisieren?
Verwende nicht „Zend_Date“ für einfache Datumsausgaben/-formatierungen, denn hier liegt der Flaschenhals. Verwenden lieber die PHP-eigene „DateTime“-Klasse oder, in Zeiten von PHP 5.3 und höher, die „intl“-Erweiterung. (in ZF2 ist die „Zend_Date“-Komponente verworfen und es werden nur noch die beiden genannten PHP-eigenen Funktionen verwendet.)
 

Kaiuwe

Super-Moderator
Ich habe die Erfahrung leider machen müssen, das Zend Date vorallem bei mehreren Schleifendurchläufen echt lahm ist.
Richtig erkannt. Das liegt aber daran, dass die Klasse alles selbst und unabhängig löst. Ist aber in den neueren PHP-Versionen nicht mehr nötig.
Oft habe ich zb bei Datums Vergleichen, das Datum vor der schleife in den Unix Timestamp umgewendelt und mit diesem dann verglichen…
Ist doch in PHP schon alles da: „DateTime object comparison
 

Kaiuwe

Super-Moderator
ich weiß nicht, ob ich hier richtig bin. Habt ihr schonmal die Performance eurer zf Anwendung untersucht?
Sicher und vor allem schon vor ein paar Jahren!

Wie lange dauert bei euch so das bootstrapping eurer Anwendung?
Ist irrelevant und kaum zu vergleichen, denn es ist doch schon von Anwendung zu Anwendung, auf gleichem System, ganz unterschiedlich.

Bei mir liegt der Wert bei 305ms und das bereitet mir etwas Sorgen.
Musst du nicht.

Vielleicht sollte ich noch erwähnen, dass ich auf einer virtuellen Maschine entwickle. Host ist ein Intel Core Duo 6400 ~2,13Ghz und 4 Gb DDR2 800.
Auf dem Live-System sieht es ganz anders aus!


Suche eher nach den auffälligsten Flaschenhälsen im Code und versuche zu analysieren, wo das Problem liegt. Und bitte nicht sofort einen Cache einsetzen, denn das ist oft nur die Bekämpfung des Symptoms, aber nicht die Beseitigung der Ursache.
 
Zuletzt bearbeitet:

crash

New member
Zwei Vorschläge zur Optimierung:
- Byte-Code-Cache
- application.ini beim Deployment in eine application.php umwandeln (Merging/Lesen der Ini dauert u.U. lange)

Ansonsten wenn du schon geprofiled hast müsstest du doch sehen, was genau lange dauert. Das muss dann optimiert werden.
 

christian1987

New member
Hallo,

vielen Dank für die Antworten.

@kaiuwe: Danke für den Hinweis. Ich werde den ViewHelper entsprechend umbauen und IntlDateFormatter benutzen.

@crash: Wäre es nicht noch schneller, einfach die Instanz von Zend_Application zu cachen?

Zwei Sachen sind mir noch aufgefallen:

- Der Autoloader benötigt beim erstmaligen einbinden einer Datei recht lange, wegen dem Lookup. Macht es Sinn, benötigte Resourcen manuell einzubinden?
- Das rendern der Breadcrumb und der Navigation dauert relativ gesehen auch etwas, da ich dafür den Partial-Helper (setPartial(...)) benutze. Hier würde sich sicherlich ein Cache anbieten, in dem ich das gerenderte HTML vorhalte.
- Ich benutze Data-Object-Mapper. Das hydrieren und somit die Erstellung der Objekte bereitet mir ebenfalls etwas Sorgen:

PHP:
class Acl_Model_Mapper_Resource extends Foo_Model_Mapper_Abstract
{
    /**
     * name
     *
     * @var string
     */
    protected $_name = 'Resource';
    
    /**
     * namespace
     *
     * @var string
     */
    protected $_namespace = 'Acl_Model_';
}
PHP:
abstract class Foo_Model_Mapper_Abstract
{
    ...
    protected function _hydrate(Foo_Db_Table_Row $row)
    {
        $model = $this->_namespace . $this->_name;
        return new $model($row->toArray());
    }
    ....
}
Würde es Sinn machen auf Hydratoren zu verzichten und das Zend Framework anzuweisen, Zend_Db_Table_Rows automatisch in StdClass() Objekte umwandeln zu lassen? Diese Idee ist bestimmt nicht gut, aber ich wollte nur mal fragen.

PHP:
$model->getId(); // So funktioniert es jetzt
$row->_id; // So könnte es funktionieren
Noch eine kleine Frage: Würde es Sinn machen eine RamDisk zu erstellen und die Applikation komplett im Arbeitsspeicher laufen zu lassen?


Lg,

--Christian
 
Zuletzt bearbeitet:

Kaiuwe

Super-Moderator
- Das rendern der Breadcrumb und der Navigation dauert relativ gesehen auch etwas, da ich dafür den Partial-Helper (setPartial(...)) benutze. Hier würde sich sicherlich ein Cache anbieten, in dem ich das gerenderte HTML vorhalte.
Die Ursache ist doch bestimmt nicht die Methode zum Rendern eines Partial-Skriptes, sondern eher das Finden der aktiven Seite im Navigations-Container. Oder?
Und wenn du einen Zwischenspeichern verwenden möchtest, dann müsste für jede Seite der Anwendung, einmal für die Brotkrümelnavigation und einmal für das Menü, das erstelle HTML gespeichert werden, denn immerhin ist Navigation dynamisch.

Ich benutze Data-Object-Mapper. Das hydrieren und somit die Erstellung der Objekte bereitet mir ebenfalls etwas Sorgen:
Was heißt hier Sorgen? Was dürfen wir darunter verstehen?


Mal eine grundsätzliche Frage: Versuchst du jetzt nur zu optimieren, damit es auf deinem Entwicklungssystem gut aussieht? Oder gibt es konkrete Probleme auf dem Live-System?
 
Zuletzt bearbeitet:

christian1987

New member
Die Ursache ist doch bestimmt nicht die Methode zum Rendern eines Partial-Skriptes, sondern eher das Finden der aktiven Seite im Navigations-Container. Oder?
Und wenn du einen Zwischenspeichern verwenden möchtest, dann müsste für jede Seite der Anwendung, einmal für die Brotkrümelnavigation und einmal für das Menü, das erstelle HTML gespeichert werden, denn immerhin ist Navigation dynamisch.
Ja genau, es ist das finden der aktiven Seite. Findest Du es schlimm, das Menu und die Breadcrumb für jede Seite einzeln zu cachen? In der Applikation geht es um ein Administrationsbackend, indem das Menu statisch ist. Ich benutze dafür eine XML-Datei (Die lasse ich schon cachen). Allzuviele Seiten wird es nicht geben.

Was heißt hier Sorgen? Was dürfen wir darunter verstehen?
Sorgen bereitet es mir, für jede Zeile aus der Tabelle die _hydrate Methode aufzurufen. Also der Map-Vorgang an sich. Aber wie gesagt, die Idee ist mit Sicherheit quatsch.

Mal eine grundsätzliche Frage: Versuchst du jetzt nur zu optimieren, damit es auf deinem Entwicklungssystem gut aussieht? Oder gibt es konkrete Probleme auf dem Live-System?
Die Applikation befindet sich momentan in der Entwicklung (es geht um meine Bachelor-Arbeit). Konkrete Probleme gibt es derzeit nicht. Ich möchte aber die Zeit nutzen und es gleich ordentlich bauen. In der schriftlichen Ausarbeitung möchte ich später unter dem Punkt Qualitätssicherung u.a. auch auf die Performance eingehen. Darüber hinaus habe ich mich noch nie mit der Performance einer Zf-App auseinandergesetzt, finde das Thema aber sehr spannend und lerne gerne dazu. ;)



--Christian
 
Zuletzt bearbeitet:

Kaiuwe

Super-Moderator
Ja genau, es ist das finden der aktiven Seite. Findest Du es schlimm, das Menu und die Breadcrumb für jede Seite einzeln zu cachen? In der Applikation geht es um ein Administrationsbackend, indem das Menu statisch ist.
Dynamisch im dem Sinne, dass das HTML auf jeder Seite deiner Anwendung anders aussieht, da die CSS-Klasse immer für die aktive Seite gesetzt wird.
Wenn es nicht so viele Seiten in der Navigation sind, ist doch fraglich, ob der Aufwand lohnt.

Ich benutze dafür eine XML-Datei (Die lasse ich schon cachen).
Entweder du verwendest den vorgeschlagenen Weg von crash oder du verzichtest gleich auf das XML und schreibst einfach ein PHP-Array: (Beispiel)
PHP:
// application/configs/navigation.php

return array(
    array(
        'label' => 'Foo',
        …
);

Sorgen bereitet es mir, für jede Zeile aus der Tabelle die _hydrate Methode aufzurufen. Also der Map-Vorgang an sich. Aber wie gesagt, die Idee ist mit Sicherheit quatsch.
Wann wird die Methoden aufgerufen? Sofort, wenn eine Datenbankabfrage erfolgt ist oder erst wenn das Ergebnis in der Anwendung selbst benötigt wird?

Die Applikation befindet sich momentan in der Entwicklung (es geht um meine Bachelor-Arbeit). Konkrete Probleme gibt es derzeit nicht. Ich möchte aber die Zeit nutzen und es gleich ordentlich bauen. In der schriftlichen Ausarbeitung möchte ich später unter dem Punkt Qualitätssicherung u.a. auch auf die Performance eingehen. Darüber hinaus habe ich mich noch nie mit der Performance einer Zf-App auseinandergesetzt, finde das Thema aber sehr spannend und lerne gerne dazu. ;)
Performance muss aber richtig beleuchtet werden. Stichwort: „Premature optimization“ (aus der mir möglichen Sicht, verfällst du gerade genau diesem)
 
Oben