Traffic Monitoring mit vnstat
Viele Internetnutzer haben mittlerweile eine Trafficflatrate und müssen sich über das verbauchte Transfervolumen keine Gedanken machen, aber im Wohnheim, bei Servern oder UMTS Verträgen sind Trafficbeschränkungen noch gang und gäbe. Da ich gern informiert sein wollte, wie viel Traffic mein Server verbraucht habe ich mir vnstat installiert.
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.
Einstieg in GIT? Warum?
Verfasst von David unter GIT, Webentwicklung am 11. März 2010
In der Webentwicklung ist der Umstieg auf GIT ein echter Trend. Vor einem Monat gab Fabien Potencier den Wechsel von svn zu GIT in der Entwicklung der neuen Symfony Version bekannt, CakePHP hat den Wechsel genauso wie phpBB schon vor einer ganzen Weile gemacht. Als Weitere wären da auch noch PHPUnit oder RubyOnRails. Dieser Trend hat natürlich auch mich interessiert, weshalb ich mein neues Projekt gleich mit GIT aufgesetzt habe. Am Anfang braucht man natürlich etwas Starthilfe, weil GIT vom Ansatz her anders als Subversion ist, aber diese Hilfe findet man in den zahlreichen Tutorials schnell.
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.
Ein Blick auf Doctrine Core Behaviors
Beim Planen einer Datenbank/des Modells für eine Internetseite trifft man immer wieder auf Objekte (aus dem Modell) mit Gemeinsamen Eigenschaften/Verhalten. Plant man einen Blog hat man zum Beispiel ein Klasse für Artikel und eine für Kommentare, beide verfügen wahrscheinlich über Attribute wie created_at und updated_at. Für solche Gemeinsamen Eigenschaften gibt es in Doctrine so genannte Templates/Behaviors. Ich möchte hier nicht erklären wie man Templates selbst schreibt, sondern viel mehr zeigen welche Core Behaviors Doctrine bereitstellt.
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.
Serverumzug fast fertig
In letzter Zeit habe ich wenig von mir hören lassen. Diese Zeit habe ich für meinen Serverumzug genutzt.
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.
Symfony 2.0 Preview Release testen
Nach dem Symfony 2.0 auf der Symfony Live 2010 vorgestellt wurde, kann man es sich nun auch selbst runterladen und die Preview Version testen.
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.
Symfony Live 2010
Seit gestern findet in Paris Symfony live 2010 statt. Ich konnte mich leider nicht auf den Weg nach Paris machen, um an der Konferenz teilzunehmen (Muss ich noch bis Oktober auf den Symfony Day Cologne warten). Da es vielen sicher genauso geht, habe ich mal ein paar Informationen zusammen gesammelt, welche ich euch natürlich nicht vorenthalten möchte.
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
Xdebug – PHP Profiler
Heute möchte ich euch wieder ein Tool vorstellen, mit dem man die Performance seiner PHP Anwendung testen kann bzw. die Performance-Engpässe in der Anwendung aufspüren kann. Xdebug wird von vielen als Debugger in der Entwicklungsphase genutzt, bietet aber auch einen Profiler. Viele kennen Profiler nur aus Kriminalserien im Fernsehen, aber ein Entwickler sollte damit auch ein Tool zur Performance-Analyse von Anwendungen in Verbindung bringen. Profiler aus dem Fernsehen erzeugen Täterprofile anhand von operativen Analysen, ähnliches macht ein Software-Profiler auch, er erzeugt Softwareprofile anhand operativer Analysen.
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.
Letzte Kommentare