Wie viel Code darf unter einen Timer?

Zitat von BlackAce

Die Funktion wird ans Plugin übergeben, welches selbst in einem eigenen Thread hängt.
Also den test will ist sehen der das gegenteil beweist - denn rein SA:MP Teschnisch ist das schon eine Lüge.

Wie gesagt, ich habe mit einem einzigen Query Lags verursacht. Mit mehreren Queries testweise noch viel stärkere Lags. Alle anderen Funktionen (zum Beispiel aus Files auslesen) gingen dabei ohne Lags.
Was letzendlich das Problem war ist dabei nicht relevant. Fakt ist, dass der SA:MP Server für die Zeit des Lags keine weiteren Funktionen ausgeführt hat. Generell tritt dieses Problem auf, wenn auf dem Server auf dem die Datenbank liegt eine hohe Lese-/Schreibrate im Gange ist. Dies hat aber weder Files noch sonstige Funktionen beeinflusst, nur MySQL.

Jemanden der Lüge zu bezichtigen ich übrigens nicht die feine Art.

Manyula:
http://forum.sa-mp.de/gta-mult…ng-fragen-667#post1951525

Zitat von Jeffry

Manyula: Es ist besser einen Timer mit 50 Berechnungen zu haben, als 50 Timer mit je einer Berechnung, das geht weniger auf die CPU.

dies kommt wieder auf die berechnung an die sollte mit hilfe von gettickcount gemessen werden. sobald ein durchlauf einer Berechnung mehr als 5-10ms dauert kann dies zu einen größeren Laag führen wenn mehr spieler online sind.

gehen wir mal iweder zu meinen DayZ Server ich hatte kurzzeitig ein System drine welches mit hilfe von Mapandreas mögliche Laufwege der Zombies recht genau berechnet hat doch da Map Andreas nicht das schnellste System ist wenn es um genauigkeit geht hatte meine Berechnung pro durchlauf ungefähr 10 ms sekunden gebraucht was sich in einer einzelnen abfrage nicht so stark bemerkbar macht als wenn der Server für alle 300 NPC's die BErechnung gleichzeitig machen muss.

In meinem Beispiel habe ich so eine 3 Skunden Berechnung alle 30 sekunden gehabt. wodurch der Server natürlich alle 30 sek für 3 sekunden laggte.
Nachdem ich das ganze auf Timer Pro NPC geschrieben habe und die Timer um 50ms versetzte habe hatte ich das selbe system eingebaut ohne große Laags sondern nurnoch mit kleinen. Ich habe dann die Berechnung etwas vergrößert wodurch sie 12ms gebraucht hat ich aber den Timerabstand von 50ms auf 150ms hochschrauben konnte wodurch es keine merkbaren laags mehr gibt.

Es kommt alles sehr stark auf die arbeitsweise an und was genau berechnet werden soll. auch sollte man niemals alle 10 min alle Spieler etc auf einmal speichern lieber jeden Spieler einzeln alle 10 min (ausnahme mysql mithilfe von threated querys braucht der server ja nicht zu warten bis mysql was zurück meldet)

edit:
Jeffry: dein Argument aus dem anderen Thread:

Zitat

Hat man aber MAX_PLAYERS Timer, die alle X Sekunden aufgerufen werden, dann laufen MAX_PLAYERS Timer gleichzeitig, was bedeutet die CPU muss während der Zwit zwischen dem Aufruf (MAX_PLAYERS-1)-mal mehr Arbeit leisten. Wenn dann einer der ganzen Timer aufgerufen wird, dann wird zwar nur 1/MAX_PLAYERS -stel der Arbeit verrichtet als beim Timer mit Loop, aber (!) es wird ja jeder Timer aufgerufen, somit summiert sich hier die Arbeit wieder auf die selbe auf, nur, dass wir zwischen den Aufrufen eben eine MAX_PLAYERS-Fache CPU-Leistung brauchen.

stimmt zwar aber wer lässt bitte alle Max_Player timer gleichzeitig laufen, der hat ja auch den sinn der Timer nicht verstanden. Wenn man dass macht gebe ich dir recht dann ist ein einzelener Timer besser.
Doch wenn man die Playerspezifischen Timer erst beim connecten des Spielers startet und beim disconnecten wieder killt so ist automatisch eine Zeitdifferenz zwichen den einzelnen Timern... esseiden ich hätte einen 10sek timer und die Spieler würden alle auf die ms genau nach 10 sekunden joinen...

Zitat von Jeffry

Dies hat aber weder Files noch sonstige Funktionen beeinflusst, nur MySQL.

Dann müsste das ja auch bei SQLite auftreten, was es ja auch nicht tut.
Ich weiß nicht was du für einen Query ausgeführt hast, dass du den Lagg messen konntest.

Sobald die Funktion abgeschickt ist, hat der PAWN Thread damit nichts mehr am Hut, somit kann das nicht laggen.
Das verbietet jede Logik.

Zitat von Jeffry

Jemanden der Lüge zu bezichtigen ich übrigens nicht die feine Art.

Nunja, da du eigentlich nur eine bahuptung in den Raum stellst und man meine Aussage durchaus einfach nachlesen / -vollziehen kann, muss daran ja was faul sein.

Wie gesagt den Test will ich immernoch sehen

Zitat von BlackAce

Wie gesagt den Test will ich immernoch sehen

Zitat

Spoiler anzeigen

[02:00:25] MySQL: 1
[02:00:26] MySQL: 1
[02:00:27] MySQL: 0
[02:00:28] MySQL: 1
[02:00:29] MySQL: 1
[02:00:30] MySQL: 0
[02:00:31] MySQL: 1
[02:00:32] MySQL: 0
[02:00:33] MySQL: 111
[02:00:34] MySQL: 296
[02:00:36] MySQL: 1238
[02:00:36] MySQL: 12
[02:00:37] MySQL: 172
[02:00:38] MySQL: 141
[02:00:40] MySQL: 347
[02:00:40] MySQL: 280
[02:00:42] MySQL: 312
[02:00:42] MySQL: 6
[02:00:43] MySQL: 2
[02:00:44] MySQL: 216
[02:00:45] MySQL: 5
[02:00:46] MySQL: 2
[02:00:47] MySQL: 8
[02:00:48] MySQL: 1
[02:00:49] MySQL: 1
[02:00:50] MySQL: 2
[02:00:52] MySQL: 148
[02:00:52] MySQL: 60
[02:00:54] MySQL: 136
[02:00:54] MySQL: 21
[02:00:56] MySQL: 283
[02:00:57] MySQL: 181
[02:00:57] MySQL: 7
[02:00:58] MySQL: 1
[02:00:59] MySQL: 1
[02:01:00] MySQL: 1
[02:01:02] MySQL: 1
[02:01:03] MySQL: 59
[02:01:04] MySQL: 63
[02:01:05] MySQL: 19
[02:01:06] MySQL: 165
[02:01:07] MySQL: 103
[02:01:08] MySQL: 46
[02:01:09] MySQL: 115
[02:01:10] MySQL: 69
[02:01:11] MySQL: 43
[02:01:12] MySQL: 85
[02:01:13] MySQL: 67
[02:01:14] MySQL: 113
[02:01:15] MySQL: 112
[02:01:16] MySQL: 38
[02:01:17] MySQL: 1
[02:01:18] MySQL: 1
[02:01:19] MySQL: 1
[02:01:20] MySQL: 1

Alles anzeigen

Manyula: Was [DT]Sniper: sagt stimmt auch, eben bezogen auf die größeren Berechnungen. Kleine Berechnungen = 1 Timer besser, größere Berechnungen (nach dem was ich vorhin beschrieben habe, MySQL, Files, etc) mehrere verteile Timer. Wie gesagt, es kommt darauf an was du machen willst.

Zitat von Jeffry

Spoiler anzeigen

forward Repeater();
public Repeater()
{
new a = GetTickCount();
new query[128];
format(query, 128, "UPDATE test SET coll = %d WHERE ID = 0", a);
mysql_query(query);
printf("MySQL: %d", GetTickCount()-a);
return 1;
}

Spoiler anzeigen

Jetzt darfst du ran mit deiner Logik.

Manyula: Was [DT]Sniper: sagt stimmt auch, eben bezogen auf die größeren Berechnungen. Kleine Berechnungen = 1 Timer besser, größere Berechnungen (nach dem was ich vorhin beschrieben habe, MySQL, Files, etc) mehrere verteile Timer. Wie gesagt, es kommt darauf an was du machen willst.

Alles anzeigen

Es gibt noch Plugins, die kein Multithread unterstützen?

Irgendwie ist das, was du für einen Benchmark einbringst, ja schon fies

Zitat von Jeffry

Manyula: Was [DT]Sniper: sagt stimmt auch, eben bezogen auf die größeren Berechnungen. Kleine Berechnungen = 1 Timer besser, größere Berechnungen (nach dem was ich vorhin beschrieben habe, MySQL, Files, etc) mehrere verteile Timer. Wie gesagt, es kommt darauf an was du machen willst.

zum thema größe der Berechnung/ anzahl der Zeilen. Die Zeilenanzahl hat weniger was damit zutun sondern die ausführzeit mann sollte sich sowas immer mal printen lassen und mal ne Hochrechnung machen wie lang die BErechnung bei 1,5,50,100,500 Spielern braucht.

Jeffry: welches Mysql Plugin + VErsion verwendest du? sieht mir nach einem Plugin ohne Multithread aus.

Zitat von Jeffry

Jetzt darfst du ran mit deiner Logik.

Gerne - das Problem leigt hier an Format.

Ich hab momentan durch aktuelle CPU Last 30 ms.
mit Format ~160ms.

Das das der Ping zwischen dem Server und Datenbank ist - glaub ich eher weniger.
Mein Ping liegt da höher.

Zitat von [DT]Sniper

Jeffry: welches Mysql Plugin + VErsion verwendest du? sieht mir nach einem Plugin ohne Multithread aus.

Das wurde mit dem R5 (was sehr viele hier noch nutzen) sowie dem neusten von StrickenKid getestet.

Zitat von BlackAce

Gerne - das Problem leigt hier an Format.

Dein Ernst?
Wie erklärst du dir dann, dass der gleiche Code in 1ms sowie in 1238ms ausgeführt wird?
Wo ist denn dein Test? Den würde ich gerne sehen...

Also bitte, wenn das am Format liegt, dann müsste doch jeder Server sofort abschmieren.

Zitat von Jeffry

Wie erklärst du dir dann, dass der gleiche Code in 1ms sowie in 1238ms ausgeführt wird?

Naja nen request zum Server bei >1000 ms würde ich auch nicht die Schuld geben.

Zitat von Jeffry

Wo ist denn dein Test? Den würde ich gerne sehen...

Der ist nicht viel anders als deiner - nur kein Format drin
forward Repeater();
public Repeater()
{
new a = GetTickCount();
mysql_query("UPDATE Test SET Coll = 2 WHERE ID = 0", UpdateHandle);
printf("MySQL: %d", GetTickCount()-a);
return 1;
}

Zitat von [DT]Sniper

stimmt zwar aber wer lässt bitte alle Max_Player timer gleichzeitig laufen, der hat ja auch den sinn der Timer nicht verstanden. Wenn man dass macht gebe ich dir recht dann ist ein einzelener Timer besser.
Doch wenn man die Playerspezifischen Timer erst beim connecten des Spielers startet und beim disconnecten wieder killt so ist automatisch eine Zeitdifferenz zwichen den einzelnen Timern... esseiden ich hätte einen 10sek timer und die Spieler würden alle auf die ms genau nach 10 sekunden joinen...

Es ging um sich wiederholende Timer, wie zum Beispiel ein Tacho, der jede Sekunde aktualisiert wird. Wenn du 500 Spieler im Server hast, hast du entweder einen Timer der 500 Schleifendurchläufe hat, oder 500 Timer mit einem Durchlauf.
Aber klar, ich denke wir wollen beide aufs gleiche hinaus: Es kommt auf die Situation an. Je nach dem ist das eine oder das andere besser.

@BlackAce: Meinst du wirklich ich hätte es nicht ohne das format getestet? ._.
Und wie ich schon sagte:

Zitat von Jeffry

Generell tritt dieses Problem auf, wenn auf dem Server auf dem die Datenbank liegt eine hohe Lese-/Schreibrate im Gange ist. Dies hat aber weder Files noch sonstige Funktionen beeinflusst, nur MySQL.

Die files habe ich ebenfalls über einem formatierten String geöffnet. Somit ist format ausgeschlossen.

@BlackAce:
Jeffry:

Darf ich mal wissen wie ihr Repeater(); aufruft?

Zitat von Jeffry

Die files habe ich ebenfalls über einem formatierten String geöffnet. Somit ist format ausgeschlossen.

Merkwürig, ist nur das ich mit format eine höhere Latenz habe als ohne

Zudem müsste es dann ja auch bei SQLite der Fall sein, was ich im übrigen auch schon erwähnt und ebenso dort kann ich dein Problem in keinsterweise nachvollziehen
Tut mir Leid.

Was allerdings ein könnte ist eine Syntaxprüfung in deinem MySQL Plugin, so das der Query halt nicht immer erst zum Server muss sondern direkt intern geprüft wird
und somit ein result wert erzeugt werden kann.

Meist wird ja nur geguckt ob der query abgesendet wurde -> result 1
ansonsten 0.

Syno:
Das dürfte egal sein wie man das macht, denn schließlich gilt der errechnete Wert lokal und wird daraufhin ausgegeben.

Syno: Sekündlich, aber das ist, wie BlackAce sagt, irrelevant.

@BlackAce: Ich habe mir bezüglich des genauen Grundes auch schon einige Gedanken gemacht, allerdings keine Lösung gefunden habe. Es geht mir auch nicht um die Lösung, weil das Problem ja nur bei hoher Schreib- und Leserate am Server selbst auftritt, sondern um die ursprüngliche Aussage, dass MySQL Lags verursachen kann. Das ist wohl hiermit geklärt: Ja, es kann.

Dass du mit dem format eine höhere Latenz hast ist ja klar, aber dass die so hoch ist scheint mir merkwürdig. Ich selbst hatte mit format noch nie sonderlich Probleme. Klar, wenn man es auf 1Mio Aufrufe jagt, dann spürt man die Differenz, aber sonst merkt man da keinen Unterschied, zumindest nicht so enorm wie bei dir.

Wie dem auch sei, ich denke wir sind doch etwas vom Thema abgeschweift. Manyula dürfte jetzt mehr Informationen haben als ihm lieb ist.

[DT]Sniper
Manyula

Wenn ihr Timer verwendet, welche recht performanceintensive sind aufgrund von Kalkulationen hat man noch die Möglichkeit die Rechenleistung auf die Threads von NPCs
auszulegen, da wie schon bekannt NPCs in einem seperaten Thread laufen. Um einen Datenaustausch zwischen den NPC Skripts und dem Mainskript zu gewährleisten müsste man
ein Callback schreiben, welches aufgerufen wird, wenn OnPlayerCommandText aufgerufen wird über SendCommand und andersrum via SendClientMessage und OnClientMessage.

Zitat von IPrototypeI

Wenn ihr Timer verwendet, welche recht performanceintensive sind aufgrund von Kalkulationen hat man noch die Möglichkeit die Rechenleistung auf die Threads von NPCs
auszulegen, da wie schon bekannt NPCs in einem seperaten Thread laufen. Um einen Datenaustausch zwischen den NPC Skripts und dem Mainskript zu gewährleisten müsste man
ein Callback schreiben, welches aufgerufen wird, wenn OnPlayerCommandText aufgerufen wird über SendCommand und andersrum via SendClientMessage und OnClientMessage.

Es gibt auch Multithread-Plugins - man muss nur mit globalen Variablen aufpassen, aber das ist ja standart bei Threads

Tion
Du solltest bedenken das Pawn nicht darauf ausgelegt ist.
Das bedeutet jetzt jedoch nicht das PAWN nicht multithreadfähig wäre sondern
nicht threadsicher.
Warum Pawn generel nicht multithreadfähig ist, liegt daran, dass nur ein Stack also auch ein Parametersatz genutzt wird für die .amx
die Auswirkung eines zweiten Threads wäre, dass auf den ersten Stack zurück gegrieffen würde und dieser zerstört wird.

Daher ist das Multithread Plugin auch nicht wirklich empfehlenswert

Solange es so bleibt spricht wie wir geschrieben haben nichts gegen die Verwendung eines einzelnen Timers.

Zitat von Manyula

Printe ich nur die Zeitmessung in die Konsole, dann dauert die Ausführung der Funktion 0-1ms.
Printe ich aber mehrere Sachen, also nach jeder if-Abfrage etwas zum Debuggen, dann schwankt die Ausführungszeit zwischen 3ms und 7ms.

Hast ja auch mehr Code drin wenn du öfter was printest