Migration VB/MS-SQL -> php/mySQL ?

[Harald Weidner]

Hallo,

<hjs at schwarzer.de>:

>Datenvolumen sind derzeit ca. 100 Datensätze pro Minute Input.
>Output kann bei ca. 250 Records per Minute liegen.
>
>Das Datenvolumen könnte auch noch steigen auf ca. input = 500, output =
>1200.
>
>Lief bislang auch immer reibungslos. Nu wächst wohl die Datenmenge
>und es sieht so aus, dass der SQL-Server beim Abarbeiten seiner Jobs
>die Resourcen nicht mehr freigibt, weil er dann plötzlich schon
>wieder mit neuen Tasks beschäftigt ist. So schaukelt sich der
>Speicherbedarf dann hoch, bis der Server dicht ist.

Obwohl ich sicherlich kein Microsoft-Fan bin, muss man hier meines
Erachtens die Schuld woanders suchen. Ich kenne SQL Server Anwendungen,
die deutlich größere Transaktionszahlen verarbeiten und dies auch
weitgehend problemlos bewältigen. Natürlich muss man mit wachsender
Last auch die Hardware entsprechend anpassen.

Kann es sein, dass die Jobs mit den Anfragen gestartet werden, obwohl
die alten noch nicht fertig sind? Das würde natürlich das Problem
potenzieren, denn je mehr Jobs gleichzeitig laufen, desto langsamer
wird jeder einzelne.

>Mein Kunde fragt mich nun, ob es denn eine Lösung sein könnte, die
>Applikation auf php/mySQL zu ziehen. Hört sich für mich sehr
>faszinierend an, da ich um die Performance des Gespanns weiss.

Das ist sicherlich eine spannende Aufgabe.

>Knackpunkte sind für mich dabei die zeitgetriggerten Datenbank-Jobs
>die ja dann allesamt auf php-Seite laufen müssen. Da habe ich bislang
>nur die cron-Lösung ausfindig gemacht. Für mich ist da auch das Risiko
>dabei, dass so ein php-Job mglw. nicht fertig ausgeführt wird,
>weil zB das Timelimit erreicht ist.

Timelimits kann man erhöhen oder abschalten; siehe die andere Antwort
auf Deine Frage. Wichtig ist, dass man sicherstellt, dass nie der
selbe Job neu gestartet wird, wenn der alte noch nicht terminiert
hat. Also z.B. ein PID-File anlegen und dann erst abprüfen, ob der
Prozess noch existiert.

Wenn es sich abzeichnet, dass die Anfragen nicht nachkommen, kann man
versuchen, die Queries zu optimieren; vor allem durch Einsatz von Indices
und Verkürzen der Transaktionslänge. Und wenn alles nichts hilft, durch
Aufrüsten der Hardware.

Gruß, Harald

-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql