Kategorien
Computer MySQL Tutorials

[:en]Profiling with MySQL[:de]Profiling mit MySQL

[:en]Whenever you encounter a query slower than you expected, and you’re sure you’ve done everything in your power to ensure your tables are properly optimized and indexed, you might want to profile it. MySQL has an inbuild profiler, which allows you to see very detailed for what part of the query how much time has been spend.

To use it, follow these steps:

(1) Activate the profiler.

Since the profiler is deactivated by default we first have to start it.

[sql]SET profiling = 1;[/sql]

(2) Execute your query.

(3) Find out the query id for profiling.

[sql]SHOW PROFILES;[/sql]

It will return you something like this:

[sql]
Query_ID | Duration | Query
———+———–+———————–
… | … | …
29 | 0.0006200 | SHOW STATUS
30 | 0.3600000 | SELECT (your query here)
… | … | …
[/sql]

Now you know the query id is 30.

(4) Profile the query.

[sql]SHOW PROFILE FOR QUERY 30; // example [/sql]

This will return you the details, which might look like this:

[sql]
Status | Duration
——————————–+——————-
starting | 0.000010
checking query cache for query | 0.000078
Opening tables | 0.000051
System lock | 0.000003
Table lock | 0.000008
init | 0.000036
optimizing | 0.000020
statistics | 0.000013
preparing | 0.000015
Creating tmp table | 0.000028
executing | 0.000602
Copying to tmp table | 0.000176
Sorting result | 0.000043
Sending data | 0.080032
end | 0.000004
removing tmp table | 0.000024
end | 0.000006
query end | 0.000003
freeing items | 0.000148
removing tmp table | 0.000019
closing tables | 0.000005
logging slow query | 0.000003
cleaning up | 0.000004
[/sql]

In this example, most of the time was actually spend sending the data from the server back to the client. Maybe try narrowing down the amount of data you get from the query. Maybe raise your query cache. Maybe do something different – its entirely up to your database, server and needs what to make of this result. But now you know where to look!

[:de]Manchmal begegnet man einer SQL-Abfrage, welche langsamer ist als erwartet. Man weiß genau, alles wurde getan, dass die Tabellen optimiert und sauber indexiert sind. Und dennoch ist die Abfrage zu langsam.

Hier hilft Profiling.

MySQL verfügt über einen eingebauten Profiler, der es ermöglicht, sehr detailliert zu tracen, für welchen Bestandteil einer Abfrage die Datenbank wie lange genau gebraucht hat.

Um den Profiler zu verwenden, geht man wie folgt vor:

(1) Einschalten des Profilers.

Per Default ist der Profiler deaktiviert, daher muss man ihn erst starten.

[sql]SET profiling = 1;[/sql]

(2) Ausführen der eigentlichen Abfrage.

(3) Identifizieren der Abfrage-ID.

[sql]SHOW PROFILES;[/sql]

Dieses Kommando wird in etwa folgendes zeigen:

[sql]
Query_ID | Duration | Query
———+———–+———————–
… | … | …
29 | 0.0006200 | SHOW STATUS
30 | 0.3600000 | SELECT (your query here)
… | … | …
[/sql]

Jetzt weiß man, die Abfrage-ID ist 30.

(4) Profiling der Abfrage.

[sql]SHOW PROFILE FOR QUERY 30; // example [/sql]

Dies zeigt die Details der Abfrage.

[sql]
Status | Duration
——————————–+——————-
starting | 0.000010
checking query cache for query | 0.000078
Opening tables | 0.000051
System lock | 0.000003
Table lock | 0.000008
init | 0.000036
optimizing | 0.000020
statistics | 0.000013
preparing | 0.000015
Creating tmp table | 0.000028
executing | 0.000602
Copying to tmp table | 0.000176
Sorting result | 0.000043
Sending data | 0.080032
end | 0.000004
removing tmp table | 0.000024
end | 0.000006
query end | 0.000003
freeing items | 0.000148
removing tmp table | 0.000019
closing tables | 0.000005
logging slow query | 0.000003
cleaning up | 0.000004
[/sql]

In diesem Beispiel wurde die meiste Zeit der Abfrage damit verbracht, das Ergebnis an den Client zurückzusenden. Vielleicht sollte man die Ergebnismenge reduzieren, oder ggf. den Query Cache erhöhen. Vielleicht geht man aber auch ganz anders vor, hier sollte man von Fall zu Fall prüfen, was sinnvoll und möglich ist.

Aber dank dem Profiling weiß man nun, wo man suchen muß!

Kategorien
Computer Tutorials

[:en]Firebug: logging features[:de]Firebug: Logfunktionen

[:en]Many developers think of Firebug as the mother of all web tools. There’s a reason for it, because Firebug contains sophisticated tools to do nearly everything you need being a web developer, starting with little css experiments, debugging complex jscript-applications, profiling of web pages and many more.

Not commonly known is how to create your own logs using JScript.

For example, …
[javascript]
console.log(‚Hello World!‘);
[/javascript]
prints exactly this in your Firebug console.

You can refine this, since most of you distinguish informations, warnings, errors and debug output.

[javascript]
console.debug(‚Debug‘);
console.info(‚Information‘);
console.warn(‚Warning‘);
console.error(‚Error‘);
[/javascript]

Debugging variables can be helped, too.

[javascript]
var banana = 1.234;
var orange = "Test";
console.log("my %a has the value %d", orange, banana);
[/javascript]

If you have the need to group log output, just do it like this:

[javascript]
console.group(‚myGroup‘);
console.info(‚Info1‘);
console.debug(‚What did I want to know?‘);
console.groupEnd();
[/javascript]

Even more features, p.e. timing values, stacks and so on, are documented here.

By the way:
Most of these features have already found their way into the debugger used by Google Chrome!

[:de]Viele Entwickler betrachten Firebug als die Mutter aller Web-Tools. Diese Ansicht ist durchaus begründet, denn Firebug umfassst mächtige Werkzeuge, mit welchen man so ziemlich alles machen kann, was man als Webentwickler so täglich braucht, angefangen von kleineren CSS-Experimenten bishin zum Debuggen von komplexen JScript-Anwendungen sowie dem Profiling von Webseiten.

Was nicht ganz so bekannt ist, man kann sogar über den Firebug aus JScript heraus Debug-Logs generieren.

Beispielsweise gibt…
[javascript]
console.log(‚Hallo Welt!‘);
[/javascript]
…genau diesen Text in der Konsole aus.

Das kann man noch etwas verfeinern, denn schließlich unterscheidet man Infos, Warnings, Errors und Debugs!
[javascript]
console.debug(‚Debug‘);
console.info(‚Information‘);
console.warn(‚Warnung‘);
console.error(‚Fehler‘);
[/javascript]

Und auch die Ausgabe von Variablen kommt nicht zu kurz:
[javascript]
var banane = 1.234;
var orange = "Test";
console.log("Mein %a hat den Wert %d", orange, banane);
[/javascript]

Ästheten können auch Gruppen bilden, welche in der Konsole sauber dargestellt werden:
[javascript]
console.group(‚meine Gruppe‘);
console.info(‚Info1‘);
console.debug(‚Was ich wissen wollte…‘);
console.groupEnd();
[/javascript]
Über noch mehr Möglichkeiten dieser Funktionen, wie z.B. Zeitwerte, Stacks u.s.w kann man sich hier auf der Seite von Firebug informieren.

Übrigens:
Die meisten dieser Funktionen sind mittlerweile auch im Debugger des Google Chrome verfügbar!

Kategorien
Computer Tutorials

[:en]DOS: creative WAIT command[:de]kreatives WAIT-Kommando für DOS

[:en]Maybe you’ve encountered this before: there is no direct way to add a simple command like WAIT x seconds in DOS. While forging an easy solution for a simple task, I’ve found a nice, create way of solving this:

[php]
PING 1.1.1.1 -n 1 -w 25000 >nul
[/php]

Yes, indeed. The PING-command is used to wait.

A few additional explanations:

  • The IP adress 1.1.1.1 refers to your first network device/card, so this adress should in most cases be available to your system.
  • The additional parameter -n 1 sets the numbers of pings to 1.
  • The parameter -w is the wait duration, keep in mind these are miliseconds, so the value 25000 actually stands for 25secs.
  • >NUL pipes the standard output stream to the null-device, so every entries or responses to this stream are accepted and forgotten.

Of course, usually I try to avoid using a WAIT-operation in scripts at all, and this ain’t a very exact technique. It simply does the job for most tasks where a WAIT-command might be required.

[:de]Vielleicht standen Sie auch mal vor dieser Thematik: Es gibt keinen direkten Weg, ein einfaches WAIT-Kommando in DOS zu stricken. Während ich an einer Lösung für eine kleine Aufgabe arbeitete, stolperte ich über einen sehr kreativen Weg, dies zu lösen:

[php]
PING 1.1.1.1 -n 1 -w 25000 >nul
[/php]

Ja, genau. Das PING-Kommando kann als WAIT-Alternative verwendet werden!

Ein paar ergänzende Erklärungen:

  • Die IP-Adresse 1.1.1.1 verweist auf das erste Netzwerk-Device/Karte, daher sollte diese Adresse in den allermeisten Fällen für ein System verfügbar sein.
  • Der Parameter -n 1 setzt die Anzahl der Ping-Versuche auf 1.
  • Der zweite Parameter -w steht für die Wartezeit. Bitte beachten Sie, dass hier die Angabe in Millisekunden erfolgt, sodass der im Beispiel verwendete Wert 25000 tatsächlich 25 Sekunden entspricht.
  • >NUL routet den Datenstrom aus dem Output in das sogenannte Null-Device, damit wird jede Eingabe oder Antwort dieses Streams akzeptiert und weggelöscht.

Natürlich versuche ich immer, WAIT-Operationen in Programmen und Scripts zu vermeiden, aber manchmal hilft es doch, gerade beim Testen. Außerdem ist dies kein sehr exakter Ansatz, hier sollte man also nicht mit einer Atomuhr nachmessen. Dennoch ist dieser kreative Ansatz eine kleine, aber feine Lösung, falls man doch mal um ein WAIT nicht herumkommt…!

Kategorien
Fundstücke Tutorials

[:en]visualizing sorting algorythms[:de]Visualisierung von Sortierverfahren

[:de]Die Entwicklung von Sortierverfahren mag zwar für Nicht-Entwickler etwas wie schwarze Magie wirken, ist aber für einen Entwickler Grundwissen.

Eine gute, Coffescript-basierte Seite, welche dieses doch manchmal relativ abstrakte Thema on-thy-fly visualisiert, kann hier gefunden werden:

http://visualsort.appspot.com

[:en]The development of sorting algorythms may look for non developers a little bit like black magic, but it should be basic knowledge for a coder.

A nice, coffescript-based page visualizing that sometimes very dry topic can be found here:

http://visualsort.appspot.com

Kategorien
Computer PHP Tutorials

[:de]Modultests mit PHPUnit[:en]Unittests with PHPUnit

[:de]Eine kleine private Exkursion in die Tiefen einer OpenSource-Gemeinde hat mir mal wieder vor Augen gehalten, wie man sich das Coder-Dasein durch die Verwendung von Modultests („UnitTests“) vereinfachen kann. Nicht jeder benutzt sie, jeder sollte. In der PHP-Programmierung ist die ideale Software hierfür PHPUnit.

Die Software wird im GitHub verteilt, ist gut dokumentiert, weit verbreitet (guckt mal in viele größere Klassen rein, man stolpert oft über den einen oder anderen Testordner) und genießt hohes Ansehen bei Entwicklern. Die Software ist auch im PEAR und kann darüber installiert werden (ein paar Dependencies gibt es für zusätzliche Funktionen).

An einem einfachen Beispiel möchte ich die grundsätzliche Verfahrensweise demonstrieren. Angenommen, in einem PHP-Projekt gibt es irgendwo eine Funktion, welche den Ostersonntag eines Jahres bestimmt. Der Einfachheit halber nennen wir sie easter($jahr). So eine Funktion könnte beispielsweise eingebunden sein, wenn es um die Errechnung von verschiedenen Feiertage geht – somit könnte sie eine gewisse Kritikalität im Projekt innehaben. Wie testet man nun so eine Funktion mit PHPUnit?

Ich steige hier mal mitten in PHPUnit ein:

[php]
require_once ‚includes/functions.php‘;

class EasterTest extends PHPUnit_Framework_TestCase {
public function testEasterOk() {
$easter2011 = easter(2011);
$this->assertEquals($easter2011, gmmktime(0,0,0,4,24,2011));
}

public function testEasterFalse() {
$easter2011 = easter(2011);
$this->assertNotEquals($easter2011, gmmktime(0,0,0,12,24,2011));
}
}
[/php]

Zuerst habe einen Verweis auf das PHP-Script (hier: functions.php), in welcher die Funktion easter($Jahr) enthalten ist. Dann generiere ich eine Klasse („EasterTest“), welche PHPUnit erweitert. In dieser Klasse sind zwei Tests abgelegt:

  • Ein Gutfall (ist der 24.4.2011 Ostern?)
  • Ein Schlechtfall (ist der 24.12.2011 Ostern?)

Jetzt kommt der trockene theoretische Teil…
Hier geht es nicht etwa darum, das Ergebnis zu finden – das hat man ohnehin schneller mit einem Blick auf dem Kalender. Vielmehr ist es Ziel, das Ergebnis der Funktion mit einem definierten „Wunschergebnis“ zu vergleichen. Ich weiß, dass der 24.04. dieses Jahr der Ostersonntag ist… und ich weiß, dass es der 24.12. definitiv nicht ist.

PHPUnit – wie auch fast alle andere Software in diesem Umfeld – arbeitet mit „Assertions“ (Behauptungen). Es gibt eine Sammlung von einfachen Funktionen, welche solche Assertions in verschiedenen Konstrukten ermöglichen – angefangen von Vergleichsoperationen wie die im Beispiel verwendeten assertEquals und assertNotEquals über False/True-Varianten, Array-Prüfern und einigem anderen.

Ist dies viel Arbeit?
Bitte urteilt selbst.. ein einfacher Test ist fix geschrieben. Nicht schwer, oder?

Zurück zur Praxis.
Wie kann man nun die Tests auswerten? Am einfachsten über die Shell. Und hier ist es nun wirklich egal, ob man sich in einer Dosbox, Bash oder wo auch immer aufhält.

[shell]
D:\htdocs\>phpunit EasterTest.php
PHPUnit 3.5.11 by Sebastian Bergmann.

..

Time: 0 seconds, Memory: 3.75Mb

OK (2 tests, 2 assertions)
[/shell]

PHPUnit kann auch andere Output-Formate, beispielsweise das TAP-Format („Test Anything Protocol“), JSON, XML und andere.

[shell]
D:\htdocs\>phpunit –tap EasterTest.php
TAP version 13
ok 1 – EasterTest::testEasterOk
ok 2 – EasterTest::testEasterFalse
1..2
[/shell]

Wenn ich nun in einem Test einen Fehler habe, sieht das so aus (ich habe hierfür den Test 1 so verändert, dass die Behauptung lautet, der 23.04.2011 wäre Ostersonntag – ist aber in Wirklichkeit der Samstag davor):

[shell]
D:\htdocs\>phpunit –tap EasterTest.php
TAP version 13
not ok 1 – Failure: EasterTest::testEasterOk

message: ‚Failed asserting that <integer:1303516800> matches expected <integer:1303603200>.‘
severity: fail
data:
got: 1303516800
expected: 1303603200

ok 2 – EasterTest::testEasterFalse
1..2
[/shell]

Wenn ich nun – wann und warum auch immer – an der eigentlichen Funktion wieder mal arbeite, dann habe ich weiterhin meine gespeicherten Tests. Wenn diese mir also Mist zurückgeben, ist entweder mein Test falsch (eher unwahrscheinlich), oder meine veränderte Funktion ist nicht ok… und genau darum geht es hier. Modultests wie dieser hier machen den Code deutlich stabiler und nachträgliche Arbeiten, Erweiterungen etc. erheblich einfacher.

Und wenn es mal Bugs gibt… schreibt einen Test und fixt dann den Bug!

[:en]A little private encounter with the community of an open source project opened my eyes, how good and easy life as a coder is if you’re working with unit tests. Not everybody uses them, but everybody should. For php programming the ideal software for this is PHPUnit.

The software can be obtained from GitHub verteilt, is well documented, widely used and very popular. It is also in the PEAR project and can be installed using the PEAR installer (it has some dependencies for additional features).

To demonstrate the basic procedural manner I’ll use a simple example. Imagine… somewhere within a php project there is a function, which returns easter sunday given any year. To make things easy, we’ll name it easter($year). Such a function could be used for determining holidays and therefore could have a certain criticality. How can this be tested with PHPUnit?

Let’s delve into code:

[php]
require_once ‚includes/functions.php‘;

class EasterTest extends PHPUnit_Framework_TestCase {
public function testEasterOk() {
$easter2011 = easter(2011);
$this->assertEquals($easter2011, gmmktime(0,0,0,4,24,2011));
}

public function testEasterFalse() {
$easter2011 = easter(2011);
$this->assertNotEquals($easter2011, gmmktime(0,0,0,12,24,2011));
}
}
[/php]

First there is a link to the script containing the easter-function (here: functions.php). Then I generate a new class („EasterTest“), which extends PHPUnit. In this class there are two basic tests:

  • A positive test (24.4.2011, is this easter sunday?)
  • A negative test (24.12.2011, is this easter sunday?)

Now to the boring theoretical part…
The solution isn’t the aim here – one glance at a calender should help you way better. The goal is, to compare the functions result with a defined result. I know for sure, that this years easter sunday is on 24.04. (as long as my calendar isn’t lying!) … und I know for sure, 24.12. ain’t somewhere near easter.

PHPUnit – like many other software products around unit testing – works with „assertions“. There is a library of simple functions for assertions in different constructs – for comparisms (like the here used assertEquals and assertNotEquals), arrays, bools and so on.

How much work is it?
Please decide for yourself. An easy test should be coded within less than five minutes. Not too difficult, ain’t it?

Back to work.

How can you now run those tests? Easiest way: use your shell (whatever, either Dos, Bash or anything else php runs on).

[shell]
D:\htdocs\>phpunit EasterTest.php
PHPUnit 3.5.11 by Sebastian Bergmann.

..

Time: 0 seconds, Memory: 3.75Mb

OK (2 tests, 2 assertions)
[/shell]

PHPUnit can express itself using different output formats, for example TAP („Test Anything Protocol“), JSON, XML and some more.

[shell]
D:\htdocs\>phpunit –tap EasterTest.php
TAP version 13
ok 1 – EasterTest::testEasterOk
ok 2 – EasterTest::testEasterFalse
1..2
[/shell]

Now… how does it look like if there is an error? To test this I slighly changed my first test and assumed, 23.04.2011 is easter sunday – in reality it is the saturday.

[shell]
D:\htdocs\>phpunit –tap EasterTest.php
TAP version 13
not ok 1 – Failure: EasterTest::testEasterOk

message: ‚Failed asserting that <integer:1303516800> matches expected <integer:1303603200>.‘
severity: fail
data:
got: 1303516800
expected: 1303603200

ok 2 – EasterTest::testEasterFalse
1..2
[/shell]

If I return coding on the easter-function in the far future, then I still have my unit tests and can run them whenever I like (or whenever I need!). If the tests then return errors, either my tests are wrong or my function is (guess what is more likely). And this is what this is all about. Unit testing makes your code stronger and additions much easier.

And…if you encounter bugs… just write a test first and then fix it!