MySQL: PHP ist zu langsam. Alternative?!

**onemorenerd** · 06.02.2006, 11:43

PHP eignet sich wirklich nicht für rechenintensive Simulationen. Normalerweise generiert ein Script eine Webseite und ist fertig.

MySQL ist für massive Zugriffe aber auch nicht die beste Wahl. Was hast du denn für Daten zu speichern und wann (nur am Ende oder muß es schon zwischendurch sein)?

Ich würde es mit C und richtig viel RAM probieren.

**Romeo-G** · 06.02.2006, 11:52

Hallo,
ich habe zu ca. 19.000 Unternehmen die jeweiligen Tagesschlusskurse von 62 Tagen. Dazu kommen ein paar Zusätzliche Informationen wie gehandelte Stückzahl pro Tag u.ä..

Ich hatte persönlich auch zuerst an c bzw. c++ gedacht, weil ich darin auch selbst die größte Erfahrung habe. Als ich allerdings ein paar kurze Beispiele dazu gesehen habe, wie man mit c++ ne MySQL Datenbank ansteuert habe ich spontan erstmal resigniert.

natürlich kommt man mit der Einstellung nicht wirklich weiter aber warum den harten Weg wählen, wenn es vielleicht auch einfacher geht.

PHP ist an Programmieraufwand ja nun wirklich das non-plus-ultra.

Romeo-G

--

P.S.: Das Problem der Belastung für den Server könnte man natürlich dadurch senken, das man einen Teil der Daten in Arrays läd und somit nicht für jeden einzelnen Wert ne Anfrage an den Server schickt.

Ich denke aber, dass auch so der Server die kleinste Schwachstelle sein dürfte. Das Programm muss ja nicht nach 1 Sekunde fertig sein. Für meine Zwecke könnte ich ihm ca. 6 Stunden zur Berechnung geben.

**Arni** · 06.02.2006, 12:34

schonmal mit Oracle
und Forms versucht ????

**onemorenerd** · 06.02.2006, 12:43

Ich überschlage es mal eben:

Unternehmen * Tage * Speicherbedarf eines Tagesschlußwertes = 19.000 *62 * 4Byte < 4,5MB

Das würde ich einmalig zu Beginn der Simulation in ein oder mehrere Arrays lesen. Aber nicht aus einer DB sondern aus einem CSV-File oder ähnlichem. Das dauert auch nur Microsekunden, du ersparst dir aber die Fummelei, mit C eine DB zu erreichen.

Die Eingabe ist im MB-Bereich, die Ergebnisse werden es wohl auch sein. Für Nebenrechnungen und Runcode nochmal einiges ... aber insgesamt bewegst du dich in einer Größenordnung, in der man alles komplett im Speicher halten und berechnen kann.

Ist deine Simulation "rundenbasiert"? Berechnest du eine Runde und mit den Ergebnissen gehts in die nächste Runde? Sicherlich.

Aber brauchst du in jeder Runde alle Ergebnisse aus allen vorherigen Runden? Oder werden deine Ergebnisse sonstwie größer? Dann wirds nämlich eng mit RAM.

Dennoch mußt du nicht gleich auf eine DB zurückgreifen, kannst Zwischenergebisse auch in Dateien speichern ... sozusagen dein eigenes Swapping implementieren.

**asp2php** · 06.02.2006, 12:49

Original geschrieben von Romeo-G

Ich hatte persönlich auch zuerst an c bzw. c++ gedacht, weil ich darin auch selbst die größte Erfahrung habe. Als ich allerdings ein paar kurze Beispiele dazu gesehen habe, wie man mit c++ ne MySQL Datenbank ansteuert habe ich spontan erstmal resigniert.

das wundert mich aber echt ... denn, ob du mit C++ oder mit PHP eine Datenbankverbindung aufbaust, ist es ja nicht mehr als eine Zeile, also was soll denn die obige Aussage?

**Romeo-G** · 06.02.2006, 16:24

Hallo,
vielleicht wäre es hilfreich euch mein Projekt doch nochmal genauer zu beschreiben:

Führt man eine technsiche Analyse für ein Unternehmen durch, dann verfährt man immer nach den gleichen Mustern. Für die Analyse gibt es aber nur leider keinen allgemeingültigen Weg, sondern jeder Wertpapieranalyst hat sein eigens Handelssystem. Mir geht es nun darum ein Programm zu schreiben, dass die Signale von verschiedenen Indikatoren so bewertet, dass am Ende der Simmulation der größtmögliche fiktive Gewinn dabei rauskommt.

Im Ablauf sähe das so aus:
1. Berechnung einer Parameterkonstellation
--
2. Generierung einer Liste mit Kaufempfehlungen, wobei jeder Wert die
vorgegebenen Parameter aufweisen muss.
3. Fiktiver Kauf einer bestimmten Zahl an Werten.
--
4. Auswertung: Wie haben sich die gekauften Werte in den letzten 24 Std.
verhalten? Daraus folgen Verkaufsempfehlungen bzw. die Empfehlung
zu Halten oder Nachzukaufen.
5. Fiktiver Verkauf:
6. "goto" 2!

Am Ende des simmulierten Zeitraums werden alle Werte verkauft und der Depotwert wird in die Datenbank geschrieben, dann folgt das gleiche Spiel von vorne für eine andere Parameterkonstellation.

--

Zum Vorschlag mit der csv Datei:
Die Idee ist gar nicht mal schlecht aber vielleicht etwas umständlich, weil man zu Beginn der Berechnungen ja immer erst den Inhalt der Datenbank in eine csv Datei exportieren muss. Das dauert vielleicht etwas lang, besonders wenn ich meine Datenbank dann mit den Monaten/Jahres erweiter.

--

@asp2php:
Es wäre sehr hilfreich, wenn du mir einen Codeschnipsel dazu geben könntest.Ich würde den Weg über die Datenbank aus genannten Gründen schon bervorzugen.

Danke,
Romeo-G

**asp2php** · 06.02.2006, 16:36

Wasfür Code? Um die Verbindung aufzubauen? Ich dachte, du hättest Erfahrung in C++?

Du kannst entweder über ODBC oder direkt über API gehen, z.B. von sourceforge. Google wird dir mit Infos erschlagen, da muss ich nicht auch noch daran beteiligen.

**Romeo-G** · 07.02.2006, 10:41

Hallo,
wenn ich den bisherigen Stand der Dinge mal zusammenfassen darf, dann komm ich wohl doch nicht drum herum mir den c code anzugucken.

Melde mich dann, wenn ich dabei festhänge.
Romeo-G

MySQL: PHP ist zu langsam. Alternative?!