• 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

Profiling in CI

SeKrebs

New member
Gleich vorweg: Mehr als der Grundgedanke existiert nicht :D

Ich dachte mir, dass es praktisch sei, wenn man innerhalb einer CI-Umgebung (welche das ist, ist erstmal egal) Profiling-Ergebnisse anzeigen lassen könnte, um mögliche Bottlenecks frühzeitig zu erkennen. Vielleicht sieht das jemand ähnlich?

So mal lose meine Gedanken dazu
  • Mir ist bisher kein Streßtest-/Profiling-Framework bekannt, das dazu genutzt werden kann
  • Ich befürchte, die Datenmenge könnte ziemlich fies werden
  • Der Build dauert auffällig länger (ausser man hat kurze Tests, aber die sind vermutlich wenig hilfreich ;))
 

ice-breaker

New member
neija Profiling ist ja abhängig von dem was du testen möchtest, ein richtiges Plugin ist mir dafür nicht bekannt.
Aber irgendein Hudson-Plugin konnte für Junit-Tests "Profiling" nutzen, es hat sich einfach gemerkt wie schnell jeder Test durchgelaufen ist und das kann man sich dann in einer Historie ansehen, genau ist das natürlich nicht, eher ein "Poor Man's Profiler".

Aber warum man echtes Profiling in Tests machen wollen würde versteh ich nicht, das Auswerten muss doch auch wieder manuell passieren, da kann ich es doch auch gleich auf meinem Rechner haben.
 

SeKrebs

New member
neija Profiling ist ja abhängig von dem was du testen möchtest, ein richtiges Plugin ist mir dafür nicht bekannt.
Klar, dachte da auch eher an so eine Umsetzung, wie es zZ mit dem Coverage gemacht wird: Irgendein Tool erzeugt eine HTML Ausgabe und der CI-Server karrt das dann nur irgendwohin, wo es auf der Plattform angezeigt werden kann.
Aber warum man echtes Profiling in Tests machen wollen würde versteh ich nicht, das Auswerten muss doch auch wieder manuell passieren, da kann ich es doch auch gleich auf meinem Rechner haben.
Wenn ich mit jenkins-php.org anschaue: Genauso gut könnte man die API, Coverage, ... auch lokal machen :) Auch der Mess- bzw Copy&Paste-Detektor macht (zZ) nichts anderes, als den aktuellen Status wieder geben, was man dann manuell auswerten muss. Ok, man liest ne Liste durch und behebt die Fehler, is kein Drama :D

Wie gesagt war das erstmal nen Schnellschnuss-Gedanke ohne Wertung über Sinn, oder Umsetzbarkeit. Ich könnte mir aber schon vorstellen, dass man "Tests" ähnlich den Unit-Tests schreiben könnte, wobei die Assertions sowas wie "geschätzter Aufwand" entsprechen ("Taktzyklen" oder sowas, anstelle von "Zeit" wär schon cooler :D). Zusammen mit einem Graphen, der Durchschnittswerte auf einer Zeitleiste einträgt... ? Das wäre dann schon etwas, wie "Dauer eines Unittest", bloß dass man mehrere Iterationen haben möchte und die Laufzeit selbst höher liegen sollte.

Wieso denk ich darüber eigentlich nach? Angefangen bei
PHP:
function startsWith_withSubstr ($needle, $haystack) {
    return substr($haystack,0 , strlen($needle)) === $needle;
}
function startsWith_withStrncmp ($needle, $haystack) {
    return strncmp($needle, $haystack, strlen($needle));
}
Zweite Variante ist schätzungsweise 20% schneller, aber (ist ja nur eine kurze Funktion) auf denkbar niedrigem Niveau. Anders herum wäre so eine Änderung schnell gemacht und ohne weiteren Folgen. Wenn nun so eine generische Funktion sehr häufig aufgerufen wird, kann das die Gesamtperformance schon beeinflussen (wenn auch nicht nicht "merklich", das beginnt erst ab 20% :D). Nur: Wie findet man solche Stellen, bzw wie kann man sicher stellen, dass Änderungen tatsächlich langfristig etwas bringen?
Und da kam mir eben die Profiles in den Sinn, vor allem auch, weil sie darstellen können, wie oft eine Funktion/Methode aufgerufen wird. Wenn da dann eine Zahl wie "135.000" auftaucht, macht es womöglich schon Sinn es sich etwas näher anzuschauen :)

Dieses Beispiel ist mE auch durchaus real: Einige Autoloader-Implementierungen, die so zur Zeit überall ein wenig sprießen, setzen darauf, dass man ein Namespace und Pfad angibt. Beim Laden der Klasse muss nun geprüft werden, zu welchem (registrierten) Namespace die Klasse gehört, was immer wieder der Vergleich mit dem Anfang eines Strings bedeutet.
 
Zuletzt bearbeitet:

ice-breaker

New member
Also wenn ich dich richtig verstehe willst du zu jedem UnitTest einen Profiling-Report anlegen, diese dann alle zusammenfassen um darauf aufbauend Bottlenecks beheben zu können?
Hmm, das könnte ziemlich schwierig werden die unterschiedl. Anzahl an Aufrufen bestimmter Methoden durch Komponenten die mehr Tests als andere benötigen zu normalisieren, da habe ich aktuell keine Idee.

Müsste aber eigentlich mit angemessenem Aufwand realisierbar sind, Xdebug kann ja Performance-Profile von PHP-Aufrufen generieren, da 1 UnitTest = 1 PHP-Aufruf ist müsste man nur nach jedem Test die Daten einsammeln und am Schluss alles aufbereiten und auswerten (z.B. alle PHPUnit-Methoden entfernen :D)
 

SeKrebs

New member
Also wenn ich dich richtig verstehe willst du zu jedem UnitTest einen Profiling-Report anlegen, diese dann alle zusammenfassen um darauf aufbauend Bottlenecks beheben zu können?
Hmm, das könnte ziemlich schwierig werden die unterschiedl. Anzahl an Aufrufen bestimmter Methoden durch Komponenten die mehr Tests als andere benötigen zu normalisieren, da habe ich aktuell keine Idee.
Mein Ursprungsgedanke war eher ein Framework, dass "so wie" PHPUnit (ursprünglich nicht "mit" PHPUnit ;)) typische, möglichst aufwendige ("worst-case") Szenarien idealerweise mehrfach durchspielt und aufzeichnet (XML?). Wer es dann hübsch aufbereitet, ist erstmal zweitrangig.

Wenn man solche Tests ähnlich feingranular, wie bei PHPUnit, zulässt, sollte man sie vermutlich eh nur 1 mal die Woche höchstens ausführen :D

Schade, dass man XDebugs Profiling nicht innerhalb von Skripten steuern kann :(

Anmerkung: Das Ganze kann man auch auf den Speicherverbrauch übertragen :)
 
Zuletzt bearbeitet:
Oben