mmofacts.com

PHP Performance

gepostet vor 14 Jahre, 11 Monate von barkeltheboon

Man stell sich folgendes Szenario vor:

Definition eines Systemmittelpunkts (in der Galaxieübersicht; Sprich Position der Sonne). Von da aus bekommt jeder Planet per Zufall einen relativ realistischen Radius, bzw. Bahngeschwindigkeit zugewiesen. Diese Daten werden als Planetendaten fest gespeichert. Ähnliches wäre für das System selbst dann auch sinnvoll, sonst lohnt sich der Aufwand ja garnicht. Kommt es nun zu einer Abfrage z.B.: Wie lange brauche ich von Planet x in System 1 zum Planeten y in System 2, wird ein Berechnungsscript ausgeführt. Abhängig von einem Timestamp (Startpunkt) ergibt sich dann recht schnell die derzeitige Position auf einer Kreisbahn um die jeweilige Sonne. Die Position des Systems in der Galaxie wird genauso berechnet. So ergeben sich recht zügig die derzeitigen Positionen der Planeten. Dann wird die Strecke und Flugzeit abhängig von der Planetenbewegung einmalig berechnet.

Ich würde gerne von den Erfahrensten der erfahrenen PHP-Programmierern (^^) mal hören ob diese Berechnungen für ein Spiel (sagen wir ~ 1000 Spieler) mit PHP möglich/sinnvoll sind, oder ob die Performance dabei zu schlecht ist. Wenn ja, wäre es eine Lösung die Berechnung in eine externe Datei (z.b. in ein kleines C++ Programm) auszulagern? Würde dies die Performance auf ein tragbares Niveau heben?

P.S.: Man muss natürlich beachten, dass diese Berechnungen für Flottenbewegungen, Systemanzeige etc. pro Aufruf durchgeführt werden müssen.

MfG,

Thomas

gepostet vor 14 Jahre, 11 Monate von Drezil

geht. hatte ich schon einmal umgesetz.

schwierig wird es erst, wenn man anfängt das ganze 2d darzustellen (da jeweils immer alles berechnet werden muss - welcher planet ist grad wo etc. pp.). Aber da kann man die berechnung auch in den client verlagern und nur noch die metadaten übertragen und den rest per javascript machen.

was meinst du mit 'berechnungen für flottenbewegungen' die angestellt werden müssen? beim absenden der flotte macht man das einmalig und speicher den vektor und die flugzeit ab und dann ist die sache gegessen (kann auch in den client verlagert werden, wenn es um die anzeige geht)

was bei meinem projekt an performance nicht gereicht hat, war die rohstoffberechnung. die hätte ich in c++ auslagern müssen.

gepostet vor 14 Jahre, 11 Monate von barkeltheboon

Das mit dem JavaScript klingt nach einer guten Alternative, wenn du sagst das haut hin. Ansonsten sterbe ich auch nicht, wenn ich nen kleines Programm in eine Externe schreibe.

Mitder Flottenbewegung habe ich mich natürlich ungenau ausgedrückt. Die Flugzeit muss natürlich nur beim Abschicken der Flotte berechnet werden.

Danke schonmal für den Hinweis, dass deiner empirischen Erhebung nach die Berechnung in PHP kein Problem darstellen sollte.

gepostet vor 14 Jahre, 11 Monate von Nuky

Es ist inzwischen ein Blödsinn, PHP die Schuld zuzuschieben. Mit einem automatischen Cache wird der Interpretiert-Faktor so gut wie eliminiert, und den größten Mist macht man sowieso immer selber. Ich traue mich zu Wetten das ein richtig geschriebenes PHP-Programm ohne Optimierung ein schlecht geschriebenes C-Programm in 98% der Fälle in der Geschwindigkeit übertrumpft - und zwar noch ohne Calling Time oder sonstwas.

Ok, Edit: Ich muss anmerken dass diese 98% natürlich nur für die 2% der Fälle zutreffen wo es aufgrund der Datenmenge überhaupt einen Unterschied machen könnte.

gepostet vor 14 Jahre, 11 Monate von Kampfhoernchen

Sowas würde ich der Datenbank überlassen. PLSQL und stored procedures sind für sowas perfekt geeignet.

gepostet vor 14 Jahre, 11 Monate von Dunedan

Original von Nuky

Ich traue mich zu Wetten das ein richtig geschriebenes PHP-Programm ohne Optimierung ein schlecht geschriebenes C-Programm in 98% der Fälle in der Geschwindigkeit übertrumpft - und zwar noch ohne Calling Time oder sonstwas.

Ein schlecht geschriebenes Programm kann man über übertrumpfen. thedailywtf lässt grüßen. Insofern ist deine Aussage ziemlich aussagelos.

gepostet vor 14 Jahre, 11 Monate von Phoscur

Original von Drezil

was bei meinem projekt an performance nicht gereicht hat, war die rohstoffberechnung. die hätte ich in c++ auslagern müssen.

Da kann ich nur zustimmen, soweit ich das mal umgesetzt habe und wieder umsetzen werde, ist das ein recht komplizierter Mechanismus, vor allem wenn du noch gewisse Flexibilität für etwaige neue Gebäude einplanen willst.

Ansonsten fällt mir dazu noch Fusionkraftwerkproblem ein :D

Ich versuche gerade eine Art abstrakten Energiecontainer für Schiffe zu schreiben, der über die Flugzeit verbraucht wird. Auf dieser Basis könnte man auch zu wenig Treibstoffe für eine Umkehr haben, oder feststecken wenn jemanden die Transporter wegeballert hat. Mal sehen wie viel ich wirklich umsetze...

Zum Thema: Über die Performance von PHP würde ich mir in diesem Fall keine Sorgen machen. Und wie drezil schon meinte, lässt sich vieles direkt in zum Client verlagern.

gepostet vor 14 Jahre, 11 Monate von buhrmi

Aaaalso nur mein Einwurf...

Diese ganzen Berechnungen, sind das ein paar trigonometrische Funktionen die pro Berechnung aufgerufen werden? Oder ist jede Berechnung ein iterativer Prozess mit vielen Schleifen, z.b. schrittweise Berechnung der Position oder Routenberechnung usw.

Im 1. Fall würde ich mir ebenfalls keine PHP-Sorgen machen, im 2. Fall vielleicht schon eher.

gepostet vor 14 Jahre, 11 Monate von TheUndeadable

Oder ist jede Berechnung ein iterativer Prozess mit vielen Schleifen, z.b. schrittweise Berechnung der Position oder Routenberechnung usw.

Da ist das interessantere Problem die numerische Stabilität...

gepostet vor 14 Jahre, 11 Monate von altertoby

Original von buhrmi

Aaaalso nur mein Einwurf...

Diese ganzen Berechnungen, sind das ein paar trigonometrische Funktionen die pro Berechnung aufgerufen werden?

 Wahrscheinlich ist das nicht mehr als eine Multiplikation (phi = omega * t + phi0), ein arctan und Wurzelziehen (Umkehrung der Polarkoordinaten) und dann nur noch Differenz zwischen den Positionen der Planeten...

dürfte also für keine Programmiersprache wirklich Schwierigkeiten bereiten, und selbst wenn php mit dem arctan ein (Performance-)Problem hat, dann kann man den ja auch noch Taylorentwickeln (2. Grad dürfte für ein BG schon ausreichend sein)

gepostet vor 14 Jahre, 11 Monate von barkeltheboon

Ok, ja naja da wird zwar später noch ne kleine Formel (aus Flugtechnischen Gründen) reingeschoben, aber das hört sich hier schonmal vielversprechend an. Danke für die Antworten, ich habe leider keine Ahnung gehabt inwiefern es da Performance Probleme geben kann und wollte deshalb liebe rmal fragen; Dann werde ich da einfach bei PHP bleiben.

MfG

Thomas

gepostet vor 14 Jahre, 11 Monate von Kallisti

Wie wäre es damit die Daten einfach serverseitig für das gesamte Universum in regelmäßigen Abständen zu aktualisieren und den Client nur lesen zu lassen?

Klingt für mich nach einer Menge wiederholter Berechnungen derselben Sache oder sollen sich die Planeten jede Sekunde stark bewegen?

Dann skaliert es vor allem auch mehr oder weniger unbegrenzt nach oben.

PS, re, war ja eine Weile net da. ^^

gepostet vor 14 Jahre, 11 Monate von Kampfhoernchen

Seh ich auch so, ein Raster (sagen wir mal 1.000.000x1.000.000 oder mehr, je nach genauigkeit die du willst) und ein Cronjob der regelmäßig die Positionen der einzelnen Planeten auf dem Raster neu berechnet.

Cool wäre es natürlich wenn du die Flugbahn bei der Routenberechnung mit berücksichtigst.

Sprich: jetzt ist der Planet bei Koordinate 473355:10377, aber wen du ankommst ist er bei 2 Stunden Flugzeit schon bei 473357:10371. Deswegen musst du quasi nen "Abfangkurs" berechnen, so dass du den Planeten in 2 Stunden und 10 Minuten bei 473556:10375 triffst.

gepostet vor 14 Jahre, 11 Monate von Kallisti

Original von Kampfhoernchen

Cool wäre es natürlich wenn du die Flugbahn bei der Routenberechnung mit berücksichtigst.

Sprich: jetzt ist der Planet bei Koordinate 473355:10377, aber wen du ankommst ist er bei 2 Stunden Flugzeit schon bei 473357:10371. Deswegen musst du quasi nen "Abfangkurs" berechnen, so dass du den Planeten in 2 Stunden und 10 Minuten bei 473556:10375 triffst.

Dachte das war die Idee des Ganzen? ^^ Wobei ich sagen muss, dass ich keine Lust auf Abfangkursberechnung auf eliptischen Bahnen hätte. ;-)

gepostet vor 14 Jahre, 11 Monate von Todi42

Original von Kallisti

Wie wäre es damit die Daten einfach serverseitig für das gesamte Universum in regelmäßigen Abständen zu aktualisieren und den Client nur lesen zu lassen?

Klingt für mich nach einer Menge wiederholter Berechnungen derselben Sache oder sollen sich die Planeten jede Sekunde stark bewegen?

Dann skaliert es vor allem auch mehr oder weniger unbegrenzt nach oben.

 Dem OP ging es um die Flugzeit zwischen zwei Planeten, selbst wenn die nicht von der Geschwindigkeit des Fluggeräts und dem Zeitpunkt abhängen würde, würde die Anzahl der zu berechnenden Routen quadratisch mit der Anzahl der Planeten steigen. Und "quadratisch" skaliert nicht wirklich gut.

gepostet vor 14 Jahre, 11 Monate von Kallisti

Original von Todi42

Original von Kallisti

Wie wäre es damit die Daten einfach serverseitig für das gesamte Universum in regelmäßigen Abständen zu aktualisieren und den Client nur lesen zu lassen?

Klingt für mich nach einer Menge wiederholter Berechnungen derselben Sache oder sollen sich die Planeten jede Sekunde stark bewegen?

Dann skaliert es vor allem auch mehr oder weniger unbegrenzt nach oben.

 Dem OP ging es um die Flugzeit zwischen zwei Planeten, selbst wenn die nicht von der Geschwindigkeit des Fluggeräts und dem Zeitpunkt abhängen würde, würde die Anzahl der zu berechnenden Routen quadratisch mit der Anzahl der Planeten steigen. Und "quadratisch" skaliert nicht wirklich gut.

Er wollte bei jedem Zugriff die Position der Planeten neu berechnen, um dann daraus die Route errechnen zu können.

Ich würde nun die Positionen der Planeten vorberechnen lassen (was dann ganz normal linear skaliert), woraus sich ergibt, dass die Errechnung der Route wieder auf die normale Standardroutenberechnung reduziert werden kann, die man auch jetzt schon hat - nur eben mit beweglichen Planeten.

gepostet vor 14 Jahre, 11 Monate von Todi42

Original von Kallisti

Er wollte bei jedem Zugriff die Position der Planeten neu berechnen, um dann daraus die Route errechnen zu können.

Ich würde nun die Positionen der Planeten vorberechnen lassen (was dann ganz normal linear skaliert), woraus sich ergibt, dass die Errechnung der Route wieder auf die normale Standardroutenberechnung reduziert werden kann, die man auch jetzt schon hat - nur eben mit beweglichen Planeten.

 Aber die Zeit, die zwischen zwei Planeten benötigt wird, hängt bei bewegten Planeten ja eben nicht von der Entfernung ab.

gepostet vor 14 Jahre, 11 Monate von barkeltheboon

Also, das mit dem Cronjob ist jetzt so eine Frage. Wenn ich plane circa 1000 Spieler in eine Galaxie zu packen und denen genug Platz geben will sich zu entfalten, dann brauche ich schätzungsweise 10.000-100.000 Interaktionsobjekte. Wenn ich von denen alle 10 Minuten komplett die Position neu berechne und in eine DB schreibe...ist das glaube ich a lot. Andererseits bei nem virtuellen Server wahrscheinlich auch kein so großes Problem. Ich kann mich grad für keine Variante entscheiden. Soweit ich das verstanden habe, scheint ja die Performance in beiden fällen okay zu sein.

MfG

gepostet vor 14 Jahre, 11 Monate von Kallisti

Original von Todi42

 Aber die Zeit, die zwischen zwei Planeten benötigt wird, hängt bei bewegten Planeten ja eben nicht von der Entfernung ab.

Nun, nicht allein zumindest, das Problem sind ja aber die Menge der Views für eine einfache Kartenansicht und darum geht es doch auch.

Darüber hinaus gibt es dir zumindest schonmal einen fixen Startpunkt. Die zukünftige Bewegung deines Ziels kannst du ja noch dazurechnen, auch wenn ich wie beschrieben Angst vor Abfangkursen auf eliptische Routen hätte und es mit einer Gerade approximieren würde. ;)

barkeltheboon: Die Frage ist eben immer was wie oft passiert. Wenn der Benutzer sich die Karte ansieht, wie viele Planeten sieht er? Und wie findest du heraus, welche er überhaupt sehen darf? Indem du jedesmal ALLE berechnet...? D.h. jeder Klick auf "Karte" berechnet 100.000 Objekte.. hmm suboptimal. Da kann man sicher wieder cachen und alles in Sektoren unterteilen, so dass man nur noch eine Teilmenge checken muss, aber das macht die Berechnungen wiederum um einiges komplexer.

Die nächste Frage ist: brauchst du eine Berechnung alle 10 Minuten? Ich würde glaub ich die Koordinaten stündlich aktualisieren. Du kannst es auch splitten, dass alle paar Minuten je ein Sonnensystem oder eine Gruppe derer aktualisiert wird. Das verteilt dann die Last und erzeugt dennoch das Gefühl von Interaktivität, aber verringert natürlich Transparenz.

Ich habe mir ähnliche Fragen gestellt und da ging es nur um die Bewegung von Geschwadern. Mein Schluss war definitiv regelmäßige Updates, weil es schlichtweg alle Views enorm entlastet und angenehm zu implementieren bleibt, aber in meinem Fall dennoch performanter ist.

Im Zweifel denk die Implementation wirklich komplett zu Ende, überschlag alle writes und alle reads auf die Daten und vergleich die verschiedenen Ansätze. Aber vergiss eben nicht, dass das Anzeigen eines Viewports nicht mehr so simpel ist wie vorher.

gepostet vor 14 Jahre, 11 Monate von knalli

Je nach den Datentypen, je nach Aufkommen: Die Möglichkeit in Betracht ziehen, einen Memorycache von (Zwischen-)Ergebnissen zu nehmen, evtl. auch mit Verfall nach "Hit/Letztem Zugriff" oder "Write/Letzte Änderung" o.ä. Und man könnte sich doch auch von Kurven (natürlich pro Objekt) vereinzelte Zwischenpuntke/Snapshots merken, um eine spätere Annäherung zu beschleunigen? Dafür muss das ganze natürlich sinnvoll katalogisiert werden, beispielsweise in einem 3D-Raster. 

Auf diese Diskussion antworten