nicht angemeldet
PostgreSQL: Auktionsskript mit Countdown - DB-Architektur
Guten Abend!
Ich möchte den weisen Rat der Community einholen.
Vorerst das Grobe:
Server Apache 2.2.x
PHP 5.3.2
PostgreSQL 8.4
Auf einer Seite können Leute Coins kaufen.
Es werden verschiedene Produkte reingesetzt.
Jedes Produkt hat einen Countdown X Min und einen Startpreis von 0 Coins.
Die Leute setzen Coins und müssen am Ende die Anzahl der Coins noch einmal bezahlen und bekommen dafür das Produkt. Sie sparen dabei im Durchschnitt 40% des Preises.
Immer wenn ein Coin(bei Klick auf "bieten") gesetzt wird, erhöht sich der Countdown wieder um Y Sekunden und der Cointcounter um 1.
Wenn es zum Ende der Auktion kommt, dann passiert es ganz schnell das auf die selbe Datenbank und den selben Datensatz 100 mal pro Sekunde zugegriffen wird. Das Ganze läuft btw über Ajax so das die Leute schnell mal in ein Klickfieber kommen wenn es zum Ende zugeht.
Die Auktionen stürzen dann ab.
Das System ist also sehr schlecht geschrieben (nicht von mir, sehr groß und ca 1000 Dateien in prozedual geschriebenen PHP 4) und ich würde es gerne neu schreiben.
Wie würdet ihr daran gehen? Ich mache mir natürlich einige Gedanken da der Kunde stark PR machen möchte und die Belastung für den Server, speziell für die Datenbank, sehr sehr hoch werden.
Wie lasse ich die Zeit bei jedem gleich ablaufen?
Wie sollte die Tabelle eurer Meinung nach aussehen?
Wo ein Index gesetzt werden?
Sollte das erhöhen als Stored Procedure gespeichert werden?
Sollte man die Tabelle für jedes erhöhen nur für diesen Aufruf schließen und wieder öffnen?
Wie kann das ganze hunderte Schreib-Zugriffe in der Sekunde aushalten?
Mein Vorschlag:
auctionid endtime coincounter lastcoinfrom
int timestamp int int
Primarykey auf auctionid.
Das Erhöhen wird als Stored-Procedure(SP) gespeichert.
Bei klick auf "Bieten", wird direkt ein Skript aufgerufen welches die SP aufruft.
Bei Timestmap bin ich mir btw. unsicher ob das die richtige Wahl ist.
Ich würde wenn man auf die Seite geht, die Zeit aus der Tabelle holen, die Differenz mit dem jetzigen Timestamp per JS ablaufen lassen. Bei jedem "Biete", bzw Aufruf der SP wird gecheckt ob die Zeit > der "endtime" ist. Wenn nicht, geht es nicht und die Auktion wird abgebrochen, falls doch, wird erhöht.
Mir machen vor allem die vielen Zugriffe Sorgen.
Habt ihr noch mehr Ideen?
Vielleicht auch ein paar Anregungen worauf in diesem Fall bei der KOnfiguration der DB geachtet werden sollte.
Beste Grüße,
Toprica
-
Was ich vergessen hatte zu erwähnen:
Lohnt sich ne persistente Connection in dem Fall?-
Moin!
Was ich vergessen hatte zu erwähnen:
Lohnt sich ne persistente Connection in dem Fall?Äh? Das fragst Du?
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Äh? Das fragst Du?
Ich muss ehrlich gestehen das ich sie noch nie genutzt habe!
Also dein Rat? Ja?lg
-
Moin!
Ich muss ehrlich gestehen das ich sie noch nie genutzt habe!
Also dein Rat? Ja?Ja. Was gibt es da zu fragen? Vor allem wenn PHP als Modul (nicht CGI!) läuft macht das Sinn. Oder wozu willst Du die Verbindung 100 mal pro Sekunde aufbauen?
Aber über den prozeduralen Code des Vorgängers meckern - ich verstehs nicht.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Aber über den prozeduralen Code des Vorgängers meckern - ich verstehs nicht.
Sorry, da hast du wohl Recht ;).
Kannst du was zu meinen anderen Fragen sagen?
Wäre lieb.lg, Toprica
-
Moin!
Kannst du was zu meinen anderen Fragen sagen?
Nicht ohne eine genaue Analyse des Tatsächlichen.
Prüfe die tatsächliche Anzahl lesender und schreibender Zugriffe auf die Datenbank (das ist ein großer Unterschied), stelle diese mal gegen die Seitenabrufe. Prüfe, ob sich die Anzahl der Zugriffe nicht mindern lässt. Gerade bei nicht-prozeduraler Programmierung schleicht sich gerne der Fehler ein, dass dieselben(!) Daten vielfach(!) pro Skriptaufruf aus der Datenbank geholt werden. Oft werden die Datenbanken auch zu oft gefragt, statt sich einmal einen Array abzuholen: z.B. erst nach Kategorien, dann für jede der Kategorien einzeln nach den Subjekten der jeweiligen Kategorie. Kläre ob die Datenbank (Postgres) auf dem gleichen Rechner wie der Webserver läuft oder ob es ein weiterer Server ist. Wie sind diese verbunden ) gleiches physikalisches Netz wie das zu den Webclients? Zweite Netzwerkkarte? Bei lokalem Datenbankserver: Anbindung über socket oder tcp, udp? Ermittle auch die Auslastung der Server (CPU, Speicher, Netz) ...
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
Moin!
Kannst du was zu meinen anderen Fragen sagen?
Nicht ohne eine genaue Analyse des Tatsächlichen.
Prüfe die tatsächliche Anzahl lesender und schreibender Zugriffe auf die Datenbank (das ist ein großer Unterschied), stelle diese mal gegen die Seitenabrufe. Prüfe, ob sich die Anzahl der Zugriffe nicht mindern lässt. Gerade bei nicht-prozeduraler Programmierung schleicht sich gerne der Fehler ein, dass dieselben(!) Daten vielfach(!) pro Skriptaufruf aus der Datenbank geholt werden. Oft werden die Datenbanken auch zu oft gefragt, statt sich einmal einen Array abzuholen: z.B. erst nach Kategorien, dann für jede der Kategorien einzeln nach den Subjekten der jeweiligen Kategorie. Kläre ob die Datenbank (Postgres) auf dem gleichen Rechner wie der Webserver läuft oder ob es ein weiterer Server ist. Wie sind diese verbunden ) gleiches physikalisches Netz wie das zu den Webclients? Zweite Netzwerkkarte? Bei lokalem Datenbankserver: Anbindung über socket oder tcp, udp? Ermittle auch die Auslastung der Server (CPU, Speicher, Netz) ...
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
-
-
-
-
-
-
Moin!
Guten Abend!
Ich möchte den weisen Rat der Community einholen.
Mir machen vor allem die vielen Zugriffe Sorgen.
Wenn es zum Ende der Auktion kommt, dann passiert es ganz schnell das auf die selbe Datenbank und den selben Datensatz 100 mal pro Sekunde zugegriffen wird.Server Apache 2.2.x
PHP 5.3.2
PostgreSQL 8.4Hierbei ist es durchaus schon hilfreich, wenn die Informationen via "Ajax" zwischen dem Server und den Clients hin- und hergehen. Wenn die Zahlen stimmen sollten und außerdem noch steigen, dann würde ich bei den relavanten Abfragen zu einem grundsätzlichem Technologie-Wechsel raten.
Zuvor sollte eine brauchbare Analyse der tatsächen Zugriffe erfolgen. Und vor allem auch, warum diese so häufig sind.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix
-
moin,
PostgreSQL 8.4
für dich sind zwei schlagwörter interessant, hochverfügbarkeit und skalierbarkeit. leider kenne ich mich dies bezüglich mit PostgreSQL nicht aus. musst mal danach suchen oder eben das DBMS wechseln.
Ilja
-
für dich sind zwei schlagwörter interessant, hochverfügbarkeit und skalierbarkeit. leider kenne ich mich dies bezüglich mit PostgreSQL nicht aus. musst mal danach suchen oder eben das DBMS wechseln.
Du meinst PG wäre ungeeignet?
Meiner Erfahrung nach kommt PG mit vielen Datenmengen besser aus.-
Hallo,
für dich sind zwei schlagwörter interessant, hochverfügbarkeit und skalierbarkeit. leider kenne ich mich dies bezüglich mit PostgreSQL nicht aus. musst mal danach suchen oder eben das DBMS wechseln.
Du meinst PG wäre ungeeignet?
nein, meint Ilja nicht. Ilja meint, Du solltest Dich darüber informieren, wie PostgreSQL in diesen beiden Punkten dasteht und welche Möglichkeiten Du hast.
Meiner Erfahrung nach kommt PG mit vielen Datenmengen besser aus.
besser? Als was? Es ist bisher gar kein anderes DBMS angesprochen worden.
Mach zuallererst die Flaschenhälse der Anwendung ausfindig. Anschließend beseitige diese.
Freundliche Grüße
Vinzenz
-
Hi.
Mach zuallererst die Flaschenhälse der Anwendung ausfindig. Anschließend beseitige diese.
Das ist leider so gut wie unmöglich.
Das ganze wurde von einem vond en Philippinen gecoded. Undokumentiert, prozedual, unübersichtlich und völlig veraltete Nutzung von HTML und CSS. Alles zusammen vermischt. Keine Form von Design-Pattern o.ä., erkennbar.Wie gesagt das Teil muss komplett neugecoded werden.
Ich werde also eine persistente DB-Verbindung nutzen und das Ganze als Stored Procedure speichern. Das sind schonmal 2 Schritte Richtung Entlastung der Datenbank.
3. Schritt: Einen Index anlegen (das hatte er auch nicht)3 Dinge die schon einmal viel verändern. Jetzt ist die Frage ob es noch weitere Möglichkeiten gibt.
Es gilt jetzt noch weitere zu sammeln. Vorerst ist nur ein Server vorhanden.
Was haltet ihr von dem Countdown-Konzept? (siehe 1st post)
Beste Grüße!
-
-
moin,
Du meinst PG wäre ungeeignet?
Meiner Erfahrung nach kommt PG mit vielen Datenmengen besser aus.das ist ein pauschale aussage, mit der man nichts anfangen kann. über wieviele terrabyte reden wir den, wenn du von großen datenmengen ausgehst, weil dort sie die großen dankbanken inzwischen angekommen. aber noch wichtiger ist, dass du die begriffe hochverfügbarkeit und skalierbarkeit falsch zuordnest. hochverfugbarkeit meint ausfallsicherheit, besonders wichtig für 24/7 systeme. nicht nur das ein rechner mal ausfallen kann, du musst ja das dbms auch mal patchen, etc. und skalierbarkeit meint, wie kannst du es erweitern, zum beispiel kannst du einen zusätzlichen server hinzufügen, wenn das geschäft brummt und die zugriffe steigern. infomiere dich darüber, ob PG dafür lösungen anbietet, lass dich notfalls auch beraten. ein fehler in der planung kann am ende teuer werden.
Ilja
-
-