Unter Ubuntu kann man vnstat einfach mit dem Paketmanager installieren. Danach muss man das Netzwerkinterface, welches überwacht werden soll, hinzufügen.

sudo apt-get install vnstat
sudo vnstat -u -i

Von nun an Zeichnet vnstat auf, wie viel Traffic über die angegebene Schnittstelle verschickt oder empfangen wird. Etwas später kann man sich dann den verbrauchten Traffic anzeigen lassen:

david@ubuntu-server:~$ vnstat
Database updated: Mon Mar 15 18:50:01 2010

	eth0

	   received:       1.09 GB (68.7%)
	transmitted:     507.82 MB (31.3%)
	      total:       1.58 GB

	                rx     |     tx     |  total
	-----------------------+------------+-----------
	yesterday     16.37 MB |   74.81 MB |   91.19 MB
	    today      4.15 MB |   49.71 MB |   53.86 MB
	-----------------------+------------+-----------
	estimated         5 MB |      62 MB |      67 MB

Mit den Optionen –months –days –hours kann man sich dann die jeweiligen Zusammenfassungen anzeigen lassen.

Da ich gern eine tägliche Zusammenfassung per Mail haben wollte, habe ich mir noch ein Shellscript geschrieben, welches mir täglich eine Übersicht des verbrauchten Traffics schickt. So hat man mit vnstat ein einfaches, aber ausreichendes Traffic Monitoring installiert. Zusätzlich könnte man sich noch das vnstat PHP frontend installieren.

Warum nutze ich GIT:

• Die Geschwindigkeit:
  Da das gesamte Repository lokal gespeichert ist, sind die üblichen Arbeitsschritte wesentlich schneller als bei vielen anderen Versionsverwaltungen.
• Offline Arbeiten
  Durch das lokale Repository kann man wunderbar Offline arbeiten. Wenn man dann später wieder online ist, kann man alle Änderungen einfach in  ein anderes Repository schieben.
• Einfaches Taggen und Branching
  Natürlich gibt es auch bei GIT Konflikte, aber das Erstellen von Branchs und Tags ist SEHR einfach.
• Jedes Repository ist ein Backup
  Mit GIT macht man keinen Checkout eines neuen Repositories sondern ein Clone, so hat man mit jedem neuen Repository ein komplettes Backup/eine komplette Kopie des Repositories. Bei einem Ausfall des “Hauptrepositories” kann man so sehr schnell auf ein anderes Repository umstellen.
• Commits einfach Vorbereiten
  Git hat eine sogenannte Staging Area der man alle Änderungen für den nächsten Commit hinzufügen kann, wenn man nicht alle Dateien oder einzelne Datei Commiten möchte.

Weitere Gründe findet man hier.

Erste Schritte mit GIT:

Nun zu meinem kleinen Tutorial

Installation:

Unter Linux reicht es das Paket “git-core” zu installieren. Für Mac OS gibt es hier einen Installer und für Windows hier.

Einstellungen:

Als erstes muss man seinen Namen und die Emailadresse einstellen:

git config --global user.name "<Benutzername>"
git config --global user.email "<Email>"

Erstes Repository:

Nachdem wir uns mit GIT bekannt gemacht haben, können wir unser erstes Repository erstellen. Ich nehme einfach ein vorhandenes Projekt und führe git init aus:

david@ubuntu-server:~$ cd /home/david/project/
david@ubuntu-server:~/project$ git init
Initialized empty Git repository in /home/david/project/.git/

Jetzt fügt man einfach alle Dateien hinzu und macht den ersten commit.

david@ubuntu-server:~/project$ git add .
david@ubuntu-server:~/project$ git commit -m "initial commit"
[master (root-commit) 25c342d] initial commit
 5234 files changed, 502420 insertions(+), 0 deletions(-)
 create mode 100644 Readme
 create mode 100644 apps/admin/config/adminConfiguration.class.php
 create mode 100644 apps/admin/config/app.yml
...

Jetzt ändern wir etwas und zeigen an, was die Unterschiede sind:

david@ubuntu-server:~/project$ vim Readme
david@ubuntu-server:~/project$ git status
# On branch master
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#	modified:   Readme
#
no changes added to commit (use "git add" and/or "git commit -a")
david@ubuntu-server:~/project$ git diff Readme
diff --git a/Readme b/Readme
index a40145f..5c72d5b 100644
--- a/Readme
+++ b/Readme
@@ -1 +1,2 @@
+
 A Readme TestFile
david@ubuntu-server:~/project$ git commit -m "Readme File" Readme
[master 15563d6] Readme File
 1 files changed, 1 insertions(+), 0 deletions(-)

Mit git status sieht man also die geänderten Dateien, mit git diff die Unterschiede und mit git commit commitet man die Änderungen. Da GIT keine Dateien sondern Inhalte verwaltet muss man jede Änderung vor einem Commit hinzufügen, sowohl bei neuen Dateien als auch von bereits verwalteten Dateien.

Wie geht es nun weiter? Git kann natürlich noch viel mehr als nur commits und Unterschiede anzeigen. Viele weitergehende Informationen findet ihr im opensource Buch “Pro GIT” oder in folgenden Tutorials auf meinem Blog.

Das einfachste Verhalten ist wohl das Timestampable Behavior. Stellt man dieses Verhalten in seiner schema.yml ein

article:
  actAs:
    Timestampable:

wird automatisch ein Feld created_at und updated_at erstellt. Wenn man nun ein Artikel erstellt speichert Doctrine automatisch das Erstellungsdatum, so wie das Datum der letzten Änderung. Mit weiteren Einstellungen kann man den Namen der Felder verändern, die Speicherung ausschalten oder das Format bestimmen.

Ein weiteres Verhalten ist das Versionable Behavior. Mit Hilfe dieses Templates kann man zum Beispiel eine einfache Versionierung seiner Blogartikel umsetzen. Hierfür passen wir den actAs Bereich unserer schema.yml wie folgt an:

article:
  actAs:
    Timestampable:
    Versionable:
      versionColumn: version
      className: %CLASS%Version

Nun erstellt Doctrine eine neue Tabelle namens article_Version. Wenn man nun einen Artikel ändert, wird das alte Artikel-Objekt in der Tabelle article_Version abgespeichert und mit einer Versionsnummer versehen. In der Anwendung kann man dann einfach auf ältere Versionen zugreifen.

Für unsere Blogartikel wären außerdem noch Suchmaschinen optimierte und vom Menschen lesbare URLs interessant. Dafür brauchen wir eine eindeutige Überschrift, was man aber nicht immer hat. Auch hierfür gibt es ein Behavior namens Sluggable. Sluggable erstellt aus zuvor angegebenen Feldern eindeutige Slugs (hängt notfalls Zahlen an das Ende und ersetzt Leerzeichen mit Bindestrichen) und speichert diese ab. Diese Slugs kann man dann als eindeutige Identifizierung für die Blogartikel benutzen. Wir passen also wieder unsere schema.yml an:

article:
  actAs:
    Timestampable:
    Versionable:
      versionColumn: version
      className: %CLASS%Version
    Sluggable:
      fields: [title]

Auch hier legt Doctrine ein neues Feld namens Slug an und speichert dort eine Eindeutige Zeichenkette ab. Natürlich gibt es auch hier noch weitere Konfigurationsmöglichkeiten.

Nun möchten wir unsere Blogartikel noch einfach durchsuchbar machen, ohne weitere Bibliotheken wie Apache Lucene bzw Zend Lucene zu nutzen. Auch hierfür gibt es wieder ein Verhalten namens Searchable. Also passen wir wieder unsere schema.yml an:

article:
  actAs:
    Timestampable:
    Versionable:
      versionColumn: version
      className: %CLASS%Version
    Sluggable:
      fields: [title]
    Searchable:
      fields: [title, article]

Nun legt Doctrine eine Tabelle article_index an und speichert dort ausgewählte Keywords ab. Indiziert werden hier Wörter die im title oder article Feld häufig vorkommen. Später kann man dann mit dem ArticleTable Objekt nach einem Eintrag suche. Dieses Behaviors bietet noch viele weitere Konfiguartions- bzw Anpassungsmöglichkeiten.

Es gibt noch ein paar weitere Core Behaviors, wie I18n, NestedSet, Geographical oder SoftDelete, welche sehr individuell konfiguriert werden könne. Auch die hier gezeigten Behaviors verfügen noch über viele weitere Einstellungsmöglichkeiten, welche man in der Doctrine Documentation nachlesen kann.

Durch den Einsatz dieser Templates kan man beim Erstellen des DB-Layouts und beim Arbeiten mit dem DatenObjekten viel Zeit sparen, da ein Großteil der Arbeit von Doctrin automatisch gemacht wird.

Meinen alten Server hatte ich gekündigt und einen Neuen bei HostEurope bestellt. Dort habe ich nun einen virtuellen Linux Server und ein extra Webpack für meine Emailaccounts. Meine Internetseiten laufen also auf dem Vserver und meine Mails auf einem von HostEurope verwalteten Mailserver (bleibt mir als viel Konfigurationsaufwand erspart). Ich hoffe mit dieser Wahl bleibt mir ein neuer Serverwechsel erst einmal erspart, zumindest bis jetzt bin ich sehr zufrieden mit dem Wechsel.

Da ich derzeit wenig Zeit habe selbst Artikel zu schreiben, versorge ich euch einfach mit ein paar interessanten Links zu anderen Blogs:

Zum einen wäre da der Artikel “Dateidownload via PHP mit Speedlimit und Resume” auf phpgangsta.de oder die GIT 101 Präsentation von Scott Chacon.
Außerdem war ich auf der Suche nach einem Online Quelltext Editor, welcher Syntax Highlighting für verschiedene Sprachen kann. Gefunden habe ich EditArea.

Und last but not least gab es eine neues PHP Update und ein neues Symfony Update.

Die Wichtigste Anforderung an den Server um Symfony 2.0 zu installieren, ist PHP 5.3, da dies nicht in den aktuellen Ubuntu Paketquellen enthalten ist. Eine gute und einfache Anleitung zum installieren von PHP 5.3 findet man auf denkeinfach.de.

Nach dem ich PHP 5.3 installiert hatte, habe ich mir einen neuen Ordner auf meinem Webserver erstellt (alle Kommandos per SSH) und per GIT die Sandbox kopiert:

mkdir /var/www/sf2
cd /var/www/sf2
git clone git://github.com/symfony/symfony-sandbox.git ./

Danach die Rechte für cache und logs gesetzt:

chmod 777 hello/logs
chmod 777 hello/cache

Dann habe ich mir einen Vhost auf das web Verzeichnis gesetzt, zum testen kann man es aber auch direkt öffnen. Als erstes sollte man die Datei check.php öffnen um zu prüfen, ob man alle Voraussetzungen erfüllt.

http://<server_url>/<web_pfad>/check.php

Hier sollten möglichst viele Voraussetzungen grün sein, rote Felder im Pflichtteil sollte man beseitigen. Danach kann man seine erste Symfony 2.0 Anwendung im Browser starten:

http://<server_url>/<web_pfad>/hello/world

http://<server_url>/<web_pfad>/index_dev.php/hello/world

Eine weitere Demoanwendung findet man hier. Und den oft zitierten Geschwindigkeitsvergleich hier und einen anderen hier.
Auch wenn sich Symfony 2.0 noch in “HIGHLY EXPERIMENTAL” Stadium befindet, kann man es in der Sandbox wenigstens testen. Bleibt also bis Late 2010 zu warten, dem geplanten release Zeitraum.

Da wäre zum einen die Slideshow von Matthew Weier O’Phinney über Zend Framework im zusammenspeil mit Symfony, worüber ich auch schon hier geschrieben habe.

Dann gibt es noch zwei schöne Vorträge über Doctrine 2/Doctrine Migrations von Jonathan Wage und Dennis Benkert (Der einzige deutsche Redner?).

Im Symfony Project Blog gibt es eine Zusammenfassung des ersten Tags. Und zu guter Letzt eine der besten Zusammenfassungen (auf Deutsch): symfony-live-2010-tag-1-doctrine-1-2-training und symfony-live-2010-tag-2

PS: Hier noch der Twitter Tag: #sflive2010

Die Funktionsweise eines Profilers lässt sich am besten anhand eines Beispiels/Tutorials erklären. Also fangen wir an:

Unter Ubuntu lässt sich Xdebug sehr einfach installieren:

sudo apt-get install php5-xdebug

Danach ist Xdebug installiert und automatisch aktiviert, nun müssen wir nur noch den Profiler in der php.ini aktivieren. Wenn man den Profiler in der globalen php.ini aktiviert, wird jedes ausgeführt PHP Skript aufgezeichnet, deshalb kann es sinnvoll sein, die Einstellung in einer htaccess oder lokalen php.ini zu setzen, oder die Einstellung xdebug.profiler_enable_trigger zu nutzen. Da ich auf einem Testserver Arbeite, aktiviere ich den Profiler in der globalen php.ini (folgendes in der php.ini hinzufügen):

xdebug.profiler_enable=1
xdebug.profiler_output_dir="/tmp/xdebug"
xdebug.profiler_output_name="trace%s"

Mit den Einstellungen haben wir den Profiler aktiviert, danach müssen wir natürlich den Apache neustarten (evtl. reicht auch ein reload):

sudo /etc/init.d/apache2 restart

Jetzt müssen wir nur noch eine Seite (natürlich von dem konfigurierten Server) im Browser öffnen und das Profiling beginnt. Nach dem Aufruf finden wir in dem oben angegebenen Verzeichnis ein Datei mit dem Namen der eben Aufgerufenen Seite (trace_name_der_datei).

Den Inhalt der Datei muss man natürlich nicht Zeile für Zeile lesen und einen Graphen auf Papier malen, sondern auch hierfür gibt es ein Tool. Das bekannteste ich wohl KCacheGrind (Linux KDE), oder MacCallGrind (wer hätte es gedacht: Mac OS). Betriebssystem unabhängig gibt es noch WebGrind, ob man damit aber auch große CallGrinds analysieren kann weiss ich nicht. Falls ich noch ein Betriebssystem vergessen habe, solltet ihr einfach mal Google fragen (Stichwort: WinCacheGrind)! Meiner aktuellen Betriebssystemsituation geschuldet, stelle ich euch hier erstmal nur MacCallGrind vor. KCacheGrind zeige ich euch dann in einem späteren Beitrag, WinCacheGrind müsst ihr euch selbst angucken.

Ich habe folgendes Skript auswerten lassen:

<?php
  test();
  test();
  test();
  test();
  test();
  test();
  test();
  test();
  test();
  function test(){
    $i = 1;
    while($i < 10000) {
      $i++;
      echo "test";
      usleep(100);
    }
  }
?>

Das ganze sieht im MacCallGrind dann so aus (Einfach die erzeugten Dateien öffnen):

Nun kann man genau gucken wo die Ausführungszeit der Anwendung verschwindet, welche Funktion wie oft aufgerufen wird und wie lange die Ausführungen der einzelnen Funktionen dauern. Mit KCacheGrind kann man dann noch ein paar weitere Auswertungen anfertigen, aber dazu in einem späteren Beitrag mehr. Sonst ist MacCallGrind größtenteils selbsterklärend.

Meiner Meinung nach kann man so gute Analysen der eigenen Software machen, um Performance Engpässe schon bei der Entwicklung aufzuspüren und zu einer ordentlichen Softwareanalyse gehört es einfach dazu.

Wenn man das Zend Framework als Komponenten Framework sieht, ist der Schritt nicht groß, es als Bibliothek in einer Symfony Anwendung zu nutzen. Anders rum macht es für mich aus den oben genannten Gründen wenig Sinn. Das Integrieren des ZFs ist eigentlich spielend einfach, muss man doch nur den Autoloader an geeigneter Stelle instanziieren. Ob man dazu gleich ein neues Projekt starten sollte weiss ich nicht so recht. Ich habe einfach mal ein kleines Tutorial dazu geschrieben (Symfony Version 1.4):

Ich gehe davon aus, dass ihr bereits ein Symfony Projekt angelegt habt, sonst sollte ihr euch hier schlau machen. Ich habe in meinen Projekten die Symfony Dateien immer als svn Checkout unter “lib/vendor/symfony” liegen. Das Gleiche mache ich nun mit dem Zend Framework und checke die aktuelle Version aus:

svn co <ZF_SVN_URL> ./lib/vendor/zf

Um aus dem Branch 1.10 zu verwednen, kann man diese Adresse nutzen. Wenn man die Dateien geladen hat, bearbeitet man “config/ProjectConfiguration.class.php” und fügt folgende Zeilen in der setup Funktion hinzu:

public function setup()
{

  ... bereits vorhandener Quelltext ...

  // diese Zeilen hinzufügen
  //ZendFramework integration
  $zf_path = sfConfig::get('sf_lib_dir').'/vendor/zf/library';
  set_include_path($zf_path.PATH_SEPARATOR.get_include_path());
  require_once($zf_path.'/Zend/Loader/Autoloader.php');
  $loader = Zend_Loader_Autoloader::getInstance();
  $loader->registerNamespace('Namespace_');
}

Als erstes wird der Pfad des ZF Verzeichnisses gespeichert und der Includepfad gesetzt. Dann wird der Autoloader geladen, instanziiert und der Namespace registriert.
Man könnte diesen Quelltext auch in einer ApplicationConfiguration hinzufügen, dann könnte man das ZendFramework aber auch nur in dieser Application verwenden. Jetzt muss man nur noch einen Clear Cache machen und alles sollte funktionieren:

 ./symfony cc

Nun kann man in seiner Anwendung einfach auf die Klassen des Zend Frameworks zugreifen.

Um die Verfügbarkeit einer Internetseite unter hohen Belastungen zu testen, kann man einen Lastgenerator benutzen. Dieser generiert viele Anfragen gleichzeitig und simuliert so ein hohes Benutzeraufkommen. Apache ab ist ein konstruierter Lastgenerator, welcher nicht versucht einen realistischen Nutzer vorzutäuschen, sondern viele Anfragen an eine konkrete Seite schickt.

Ein konkreter Test mit Apache ab ist relativ einfach und sieht wie folgt aus:

macbook:~ david$ ab -n 200 -c 50 http://test.webserver/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking test.webserver (be patient)
Completed 100 requests
Completed 200 requests
Finished 200 requests

Server Software:        Apache/2.2.12
Server Hostname:        test.webserver
Server Port:            80

Document Path:          /
Document Length:        927 bytes

Concurrency Level:      50
Time taken for tests:   22.955 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Total transferred:      243400 bytes
HTML transferred:       185400 bytes
Requests per second:    8.71 [#/sec] (mean)
Time per request:       5738.652 [ms] (mean)
Time per request:       114.773 [ms] (mean, across all concurrent requests)
Transfer rate:          10.36 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   2.0      1       6
Processing:  1026 5446 2558.8   5007   12242
Waiting:     1025 5432 2554.1   4918   12194
Total:       1029 5448 2558.0   5013   12243

Percentage of the requests served within a certain time (ms)
  50%   5013
  66%   5494
  75%   5937
  80%   6548
  90%  10424
  95%  11114
  98%  11738
  99%  12195
 100%  12243 (longest request)

Dieser Befehl hat 200 Anfragen ausgeführt, von denen maximal 50 gleichzeitig verschickt wurden. Es wurden 8.71 Anfragen pro Sekunde geschickt. Eine Anfrage dauerte ca. 114.773 ms. Die Statistiken geben noch Auskunft über das übertragene Datenvolumen, Übertragungsdauer und Erreichbarkeit.

Mit Apache ab kann man relativ einfach und schnell Lasttests durchführen, aber einen echten Nutzer simulieren kann man damit nicht.

• Grundkonzepte
  (Architektur, ER, EER)
• Datenmodelle und Datenbanksprachen
  (RDB, relationale Algebra, OODB, SQL)
• Entwurfsfragen
  (Normalisierung, Entwurf)
• Mehrnutzerbetrieb
  (Transaktionen, Nebenläufigkeit, Sicherheit)

Mit diesen Schwerpunkten ist es für eine Einführungsvorlesung oder die praktische Arbeit eines Webentwicklers bestens geeignet. Durch die Zusammenfassungen am Ende eines Kapitels und die vielen praxisnahen Beispiel schaffen es die Autoren einen einfachen Einstieg in das theoretische Hintergrundwissen für Datenbanksysteme zu liefern. Durch die Wiederholungsfragen und Übungen zu jedem Kapitel kann man gleichzeitig prüfen, ob man den Stoff verstanden hat. Für Praktiker ist vor allem das Kapitel Entwurfsfragen interessant, dadurch kann man schon beim nächsten Datenbankentwurf Fehler vermeiden, welche einem sonst erst später auffallen.

Das Buch aus dem Pearson Verlag ist ca. 560 Seiten stark und empfehlenswerte Lektüre sowohl für Studenten, als auch für Praktiker.