Wann Auslastung geringer. txt oder sql?

[sanz]

Hallo Jungs,

mir stellt sich gerade die Frage, was ein Server mehr auslastet.
Die Struktur und alles basierend auf einer Textdatei/Ini zu basieren statt auf einer mysql Datenbank oder halt auf mysql. Sagen wir, wir haben 5000 Einträge .. und pro Seiten aurruf 5 mysql abfragen bzw zugriffe auf die txt. Bei ca 10.000 Besuchern am Tag,

Was macht mehr Sinn, es geht hier NUR um die Auslastung des Servers! Nicht um die komplexität oder so.

Viele Grüße,
saNz

[lazydog]

Das sind etwas wenig Angaben. Wie ist die DB-Struktur, oder auch diejenige der Dateien? Was heisst schon 5000 Einträge? 5000 mal eine Ziffer ist z.B irrlevant, da sie bei beiden Varianten als Ganzes eingelesen werden können. 5000 Blobs hingegen sind natürlich relevant, das dürfte dann etwa gleich vielen Dateien entsprechen und erfahrungsgemäss braucht das Öffnen von Dateien relativ viel Ressourcen.
Aber wie schon gesagt, fehlen noch sehr viele Angaben, um das beurteilen zu können.
Und um 10'000 Besucher pro Tag ist wahrscheinlich sehr optimistisch geschätzt.

[sanz]

USERID und IPAdressen, soll die DB bzw die TXT enthalten.
und zwar bei jedem Aufruf, gucken ob IPadresse schon vorhanden ist und wenn nicht der userid anrechnen.
10.000 Besucher ist relativ pessimistisch, und nicht optimistisch. Reichen nun die Daten für eine Unterteilung? Kann man bei diesen Angaben sagen, mysql ist hierbei viel CPU intensiver als das öffnen, lesen und schreiben in Dateien?

[lazydog]

Bei so wenig Daten könnte die Speicherung in einer Datei möglicherweise effizienter sein, da sie, wie schon gesagt, als Ganzes in einen Array eingelesen werden können.
Aus vielen anderen Gründen - v.a. Datenintegrität - würde ich aber trotzdem eine DB emfehlen.

[Chriz]

Du merkst schon, dass du versuchst eine Datenbank nachzubauen, ueber den Umweg PHP und ohne eine Chance der Skalierung. Du schliesst Komplexitaet aus, genau das ist aber der springende Punkt. Und ob es schneller ist, hundertausende Zeilen einer Text-Datei zu durchsuchen als eine Datenbank zu verwenden, wage ich zu bezweifeln, denn die Datenbank kann deine Eintraege indexieren, sie im Cache halten, sortieren, gruppieren, zuordnen. All das muesstest du nachprogrammieren.

Im Zweifelsfall wuerde ich immer auf die Datenbank zurueckgreifen und der Performance-Verlust der anfangs moeglicherweise bei Verwendung der DB auftreten koennte (da noch wenige Eintraege) ist ungleich kleiner als der, der spaeter auftritt, wenn die Datei auf abertausende Eintraege angewachsen ist

[litterauspirna]

Ich greife iegentlich prinzipiell nur noch auf DBs zurück,bis auf kleine Ausnahmen!

Das einzige wo eine DB mal in die Knie gehen kann ist wenn du zum Beispiel alle Kategorien und Unterkategorien in eine Tabelle schreibst und sie wie ein Baum darstellen willst,da man da auf eine Rekursion zurück greifen muss und wenn da eine sehr Tiefe Baumtiefe vorhanden ist und ein gleichzeitig hoher Zugriff besteht dann rauchts schon mal in der DB!

Mann kann natürlich noch auf Nested Sets (oh graus) zurück grefien, aber das hat wieder einen Nachteil, wenn die Baumstruktur oft verändert wird ist das keine gute Lösung, eigentlich dann auch dafür nicht brauchbar!

Ansonsten sind DBs immer besser finde ich weil da nicht die ganze Arbeit PHP aufgebrummt wird sondern einen großen Teil MySql übernimmt,also der Sql Server!

[Griffith]

USERID und IPAdressen, soll die DB bzw die TXT enthalten.
und zwar bei jedem Aufruf, gucken ob IPadresse schon vorhanden ist und wenn nicht der userid anrechnen.
10.000 Besucher ist relativ pessimistisch, und nicht optimistisch. Reichen nun die Daten für eine Unterteilung? Kann man bei diesen Angaben sagen, mysql ist hierbei viel CPU intensiver als das öffnen, lesen und schreiben in Dateien?

In welcher Form sollen sie diese Daten enthalten?

Ist es eine Logdatei?

z.B. pro Aufruf:
* timestamp (4 Byte)
* userid (4 Byte)
* ip (4 Byte bei IPv4)

Dann könntest du einfach pro Seitenaufruf 12 Byte anhängen.
Und auf eine beliebiege Datensatznummer per Seek zugreifen.

Suchst du in einer Logdatei nach einem bestimmten Timestamp wird dafür kein Index benötigt, weil die Timestamps bereits geordnet gespeichert werden (es sei denn dein Server reist durch die Zeit :>).

Wie man in einer geordneten Liste den gesuchten Wert am schnellsten findet, kann man in einem anderen Thread besprechen. Das geht z.B. durch ständiger Halbierung des Suchintervalls.

Möchtest du in der Logdatei auch nach Userid oder IP suchen?
Dann brauchst du einen Index. Den in PHP per Hand nachzubasteln ist Unsinn. Hier ist eine Datenbank der einzig sinnvolle Weg!

Ist es kein Logbuch?
Ja was ist es dann? Beschreib mal den genauen Aufbau näer und was du mit den Daten machen möchtest.

Zusammenfassend
Das Schreiben in eine Datei macht eigtl nur bei einem Logbuch Sinn, in dem du nicht ausgerechnet nach Userid und IP suchen möchtest.

z.B. Auflisten aller IPs der UserID X seit den letzten 7 Tagen.
Da wiederrum macht nur eine Datenbank Sinn und ist auch um ein vielfaches schneller. Versuch erst gar nicht so etwas in PHP nachzubilden!

[Chriz]

z.B. pro Aufruf:
* timestamp (4 Byte)
* userid (4 Byte)
[..]
Versuch erst gar nicht so etwas in PHP nachzubilden!

Und versuch auch nicht deine Inhalte bitweise in eine Logdatei zu schreiben wie hier vorgeschlagen

[Griffith]

Byteweise, nicht bitweise! Es wird immer ein 12-Byte-Chunk in die Logdatei geschrieben und nicht einzelne Bits.

<?php

// Schreibe ins Logbuch

$filename = 'logbuch.dat';

$timestamp = time();
$userid = 123;
$ip = ip2long('127.0.0.1');

$fp = @fopen($filename, 'ab') or die('Konnte Logdatei nicht oeffnen.');
fwrite($fp, pack('V*', $timestamp, $userid, $ip));
fclose($fp);

?>

<?php

// Lese aus Logbuch

$filename = 'logbuch.dat';
$record_num = 2;  // 3. Eintrag

$fp = @fopen($filename, 'rb') or die('Konnte Logdatei nicht oeffnen.');
fseek($fp, $record_num * 12);
$record_data = fread($fp, 12);
fclose($fp);

$arr = unpack('V*', $record_data);

echo "Timestamp: ", date('r', $arr[1]),  "<br />\n";
echo "User-ID: ",   $arr[2],             "<br />\n";
echo "IP: ",        long2ip($arr[3]),    "<br />\n";

?>

Das erste Skript nen paar mal aufrufen, damit sich das Logbuch füllt.
Das zweite Skript liefert dann eine Ausgabe, wie z.B.

Timestamp: Thu, 05 Jun 2008 10:37:20 +0200
User-ID: 123
IP: 127.0.0.1

[Chriz]

Doch, die IP wird in Bit dargestellt, 4x die 255 in 8 Bit. Effizienter geht es nicht.

Trotzdem ist das dann wieder so ein - sorry - beschissenes personal-Dateiformat und das alles im Namen der Performance. Ich find das ehrlich gesagt Kaese, vielleicht kann der ein oder andere ja mal realisieren dass wir mittlerweile genug Speicherplatz und Rechenpower haben, um auf soetwas verzichten zu koennen.

Was wird denn dann, wenn noch eine Information variabler Laenge hinzugefuegt werden soll; ne halt achso, es geht ja nicht um Komplexitaet wie _anfangs_ behauptet - aber es laeuft doch am Ende immer auf Erweiterungen heraus. Wer gegenteiliges behauptet ist einfach noch nicht lang genug im Geschaeft ..

[Griffith]

Jopp, ihm ging es eben um die Performance und nicht um Flexibilität.
Natürlich ist bei der Verwendung einer Datenbank der Aufwand geringer und gleichzeitig die Erweiterungsmöglichkeit höher. Aber ich nahm an wir wollten hier lediglich die Performance diskutieren, wie es im Threadtitel steht.

Dazu bräuchte man Vorschläge, welche Varianten es zur Umsetzung gibt und diese dann einfach in nem Benchmark gegenüberstellen. Ist der Perfomancegewinn minimal, zieht man natürlich die Variante vor, die leichter zu warten ist.

Und was heißt hier lange im Geschäft? Man hat schon immer die Teile eines Codes auf Geschwindigkeit optimiert, die häufig ausgeführt werden.

Naja und ich bin nicht einer der Vertreter, die meinen es sei in Ordnung, dass man bald für ein Officeprogramm 4 GB RAM und nen Quadcore-Prozessor braucht, weil das ja inzwischen jeder haben sollte.

Codeoptimierung und die Entwicklung ressourcensparender Codes ist und bleibt weiterhin ein wichtiges Thema ... sofern es sich lohnt.