Frage zur Skalierbarkeit (für Fortgeschrittene)

[Jan.O]

Hi Leute,


Ich entwickle derzeit ein Web 2.0 Projekt. Es handelt sich hauptsächlich um eine website mit Echtzeit-Ereignissen, und ich muss etwas fixen. Hier ein schaubild zu meinem Problem:



Es gibt einen DB-Query, den alle http-clients in 10-sekudenabständen ausführen müssen. Aber statt diesen immer wieder auszuführen, möchte ich einen thread haben der den query ausführt und die daten über den Speicher an die clientthreads übergibt. Es ist also vergleichbar mit caching.

Ist das möglich? Welche server-engines/programme sollte ich benutzen?

Ich hoffe es gibt eine Lösung mit zB Apache/Lighttpd und Python.

mfg
Jan O.

[EnTeQuAk]

Wenn ich dich richtig verstanden habe, solltest du dir mal [wiki=WSGI]WSGI[/wiki] anschauen. Datenbank ohne großes gewurschtel, kann ich SQLAlchemy empfehlen.

Wenn du Werkzeug für die WSGI-Implementierung nimmst, hast du sogar ein sehr geniales Cache-Framework (wenn ich das grad so nennen darf) um deine Bedürfnisse zu bewältigen.

Die Frage ist allerdings, hast du schon etwas fertiges, laufendes oder ist das alles noch erst Planungsphase?
Ansonsten brauchst du wirklich nur die Website ansich, die DB-Anbindung und nen Workerthread der den cache füllt und leert.

Solltest du WSGI nutzen, läuft deine Lösung 100%ig mit Apache und Lighttpd, siehe Wiki-Artikel.

Ich hoffe ich konnte dir ein wenig helfen.

Gruß, Christopher

[gerold]

Es gibt einen DB-Query, den alle http-clients regelmäßig ausführen müssen

Hallo Jan O!

Zu diesem Problem kann man so pauschal nichts sagen. Um einen guten Vorschlag machen zu können, brauchen wir mehr Informationen.

- Welche Datenbank?
- Liegt die Datenbank auf dem selben Computer?
- Wie lange dauert derzeit diese Abfrage?
- Wie viele Datensätze mit wievielen Feldern werden von dieser Abfrage zurückgegeben?
- Wie oft ändern sich die für die Abfrage relevanten Daten in der Datenbank?
- Ist das Ziel, den Speicherverbrauch zu reduzieren, oder die Geschwindigkeit zu erhöhen?
- Was setzt du derzeit für ein System ein? Nur den Apachen? CGI? Oder soll das eine Neuentwicklung werden? Windows oder Linux? Eigener Server auf dem du alles machen kannst?
- ...

mfg
Gerold

[Jan.O]

Hi,

danke für eure antworten. Es geht darum, die belastung auf eine MySQL-Datenbank zu reduzieren. Jeder user macht alle 10 sekunden dieselbe abfrage auf die DB. Stattdessen sollen die Daten jetzt nicht mehr direkt aus der DB, sondern aus dem RAM bezogen werden. Also muss ein thread laufen, der die daten aus der DB im 10 sekunden-abstand aus der DB in den RAM schreibt und für alle clients verfügbar macht.

Meine aktuelle Lösung ist memcached. http://www.danga.com/memcached/

Memcached ist ein server, der einträge per Schlüssel im ram speichern kann. Diese einträge können von php, python, perl etc gelesen und geschrieben werden. Benchmarks zeigen, dass php am besten performt. So könnte man also ein seperates python-script laufen lassen, welches die daten regelmäßig ausließt und in memcached schreibt. Diese daten können dann in der website von PHP ohne DB-Query extrem schnell gelesen werden.

Große seiten wie Youtube benutzen memcached

Jan

[gerold]

Meine aktuelle Lösung ist memcached. http://www.danga.com/memcached/

Hallo Jan!

Gut, du benutzt also derzeit "memcached". Damit hat sich dein Problem ja bereits gelöst. Oder was brauchst du denn noch? Oder willst du die Website neu programmieren und auf PHP verzichten, oder wobei brauchst du noch Hilfe? Und meine übliche Antwort ist "CherryPy".

mfg
Gerold

[Y0Gi]

Große Seiten wie Youtube nutzen Python

PHP ist doch dieses Zeug, was nicht thread-sicher ist und damit nur eingeschränkt mit einem Worker-Apache funktioniert? *scnr*

Hast du den Flaschenhals denn wirklich in der DB gefunden? Wenn memcached nicht hilft, muss wohl die Anwendung optimiert oder mehr Hardware angeschafft werden. MySQL lässt sich ja z.B. auch clustern, munkelt man.

[Sr4l]

Wenn man haargenau die gleichen SQL Befehle sendet braucht man (meiner Meinung nach) kein Cache auf Arbeitsspeicherebene, das macht MySQL z.B schon sehr gut. Habe das selber mal getestet.

[Jan.O]

Große Seiten wie Youtube nutzen Python

Ja

PHP ist doch dieses Zeug, was nicht thread-sicher ist und damit nur eingeschränkt mit einem Worker-Apache funktioniert? *scnr*

Ja, jedoch ist PHP auch sehr bekannt und sogar sehr schnell, wenn man es richtig anstellt.

Hast du den Flaschenhals denn wirklich in der DB gefunden? Wenn memcached nicht hilft, muss wohl die Anwendung optimiert oder mehr Hardware angeschafft werden. MySQL lässt sich ja z.B. auch clustern, munkelt man.

Das projekt befindet sich noch in der entwicklung.
rechnen wir mal folgendes: 50 aktive Leute befinden sich gleichzeitig in dem hier behandelten teil der seite, und zwar so, dass sie informationen austauschen müssen. Das hätte dann zur folge, dass pro sekunde 50 inserts in die DB gemacht werden. Jeder dieser inserts müsste dann an jeden der 50 Benutzer übermittelt werden. Macht 2500 ausgelesene zeilen pro sekunde . Und es kann sich natürlich auch um mehr als 50 leute handeln.

Mit einer speicherung der Daten im RAM würde man die anzahl der ausgelesenen zeilen in diesem falle auf 50 reduzieren.

[Sr4l]

Wie muss ich mir das vorstellen? Wie Teamarbeit bei Google's Write?

[Jan.O]

Wie muss ich mir das vorstellen? Wie Teamarbeit bei Google's Write?

kenne ich nicht

[Sr4l]

Ich meine mehrere Benutzer sind in einem Texteingabefeld, einer schreibt ein neues Wort und bei allen anderen Benutzern kommt diese Änderung in nahezu Echtzeit an.

PS: Kannst du auch nicht schlafen?

[Jan.O]

von er technik her ist es das selbe, allerdings gehts hierbei nicht um einen editor . Es geht um eine fortschrittliche community (social-networking) mit echzeit-welt, in der man sich gegenseitig sieht (RPG in 2D). DIe koodrinaten der spieler müssen natürlich in nahezu echtzeit ausgetauscht werden.

PS: Ich kann schlafen, aber es ist noch zu früh ^^

[Sr4l]

Vielleicht eine statische Datei vom Server erzeugen lassen in der die nötigen Informationen stehen. und deine Clienten holen sich die Information aus der Datei, soweit sollte das mit AJAX alle machbar sein.

Dann trickst du noch etwas: du gibst die Koordinaten des Spielers und die wahrscheinlichen Zielkoordinaten an, dadurch entsteht nicht das Gefühl des laggens, wenn es mal etwas länger dauert die Daten abzufragen, weil du die Figuren weiterlaufen lassen kannst.

Das ändert die Anzahl der INSERT's nicht aber die Zahl der SELECT's

(Nur mal so ins Blaue geschossen, ich weiß ja nicht wie es aussehen soll und wie der Aufbau geplant ist)

[Jan.O]

es handelt sich um eine 2D-welt. Die spielerkoordinaten werden feldweise angegeben. Da eine berechnung von laufruten zu hart ist, müssen sämtliche schritte der spieler übermittelt werden.

Die idee mit den statischen dateien finde ich nicht so gut, da der RAM um einiges schneller ist.

[thelittlebug]

neuerdings (1960) können einige betriebsysteme (*nix) dateien im ram "cachen"?

lgherby

[Jan.O]

aber warum daten -> datei -> ram -> website und nicht daten -> ram -> website?

[thelittlebug]

wenn du eine lösung kennst, warum hast du sie noch nicht implementiert?

lgherby

[Jan.O]

auf die lösung mit memcached bin ich nach meinem ersten beitrag gestoßen.

Aber danke für die mit der datei, werde es mal testen/benchmarken

[sma]

Ich würde prinzipiell das Pollens anzweifeln. Statt das jeder Client periodisch nachfragt, ob sich etwas getan hat, sollten sie nur informiert werden, wenn wirklich etwas passiert ist. Das reduziert IMHO stärker die Last auf dem System als Versuche, SQL-Queries zu cachen.

HTTP ist leider keine gute Basis für derartige Events. Unter dem Stichwort COMET werden entsprechende Workarounds zusammengefasst. Eine Alternative ist das AMF-basierte Remote-Objekt-Protokoll von Flash. Der Server dazu ist mitlerweile quelloffen, allerdings ein Java-Programm.

Dieses Vorgehen macht allerdings die 1-Request-Share-Nothing datenbank-zentrische Programmierung unmöglich und dauerhaft laufende Server machen die Entwicklung deutlich einfacher. Vielleicht habe ich zu lange Java gemacht, doch das würde ich hier eher in Erwägung ziehenals PHP oder Python. Möglicherweise wäre Jython eine gute Wahl, um Spiellogik zu scripten.

Ich fände auch spannend mal zu prüfen, wie ein klassisches Setup mit Django und FastCGI oder Modpython plus Apache gegen Jython mit modjy auf einem Glassfish-Server so besteht. Allerdings würde diese Architektur wieder die klassische 1-RSN-Situation simulieren.

Stefan

[Y0Gi]

2500 Zeilen pro Sekunde sollten nun wirklich kein Problem für ein DBMS sein, behaupte ich mal frech.