Pytanie o graczy (! WAŻNE !)

46 minut temu, TeZetYT napisał:

Hej. Mam takie jedno pytanie, które w sumie zależy od tego czy mam sens pisania skryptów - Czy właściwie serwer 100 graczy+ może pociągnąć serwer który ma kilka skryptów, czy serwer może być troche oparty na skryptach? Czy właściwie skrypty pisać można tylko na małe serwery?

Dobrze. Widzę, że trzeba wyjaśnić kilka spraw.
Lakonicznie odpowiadając na Pana pytanie, Skript sam w sobie nie jest obciążający dla serwera. To źle i niewydajnie napisane skrypty są powodem obciążenia serwera. A teraz pora na dłuższą odpowiedź.
 

1. Wiele osób piszących w Skript w nonszalancki sposób:

• wykorzystuje zapis zmiennych globalnych,
• tworzy ogromne pętle działające na wielu danych,
• wykonuje kosztowne w zasobach serwera operacje w sposób synchroniczny, podczas gdy często istnieje możliwość wykorzystania takich dodatków jak skript-reflect (czy też SkQuery) do asynchronicznego wykonania kodu.

System zmiennych globalnych w Skript jest bardzo niewydajnie napisany, co zresztą wielokrotnie przyznawali twórcy pluginu. Niewydajność wynika z tego, że Skript każdą zmienną (globalną) zapisuje do pamięci RAM (rzecz normalna), ale również na dysku. Innymi słowy, za każdym razem gdy skrypt wykonuje efekt 'set {zmienna::globalna} to <coś>', zmiana ta jest zapisywana na dysku. W przypadku zapisu setek (a czasem tysięcy) zmiennych w jednym momencie, taka operacja staje się niezwykle kosztowna.
Trzeba również pamiętać o tym, że Skript "lubi" często przeorganizowywać plik ze zmiennymi globalnymi (variables.csv), co jest kolejnym powodem niskiej wydajności tego systemu.

W ramach ciekawostki powiem, że na pewno do niedawna (a może i do teraz, kto wie) poniższy kod był w stanie zatrzymać pracę serwera (wywalić go).

command /test:
	trigger:
		loop 10000 times:
			set {testVariable::%loop-number%} to loop-number

W przypadku używania zmiennych lokalnych takiego ryzyka nie ma, gdyż są one zapisywane jedynie w pamięci RAM.

Dodam, że miłą alternatywą dla zmiennych globalnych może się okazać dodatek skript-yaml. Ogromną przewagą tego pluginu jest fakt, iż to skrypter decyduje kiedy dane mają być zapisane na dysku, nie Skript (czyli właściwie każdorazowo gdy zapisujemy zmienną globalną). Do momentu zapisu na dysku dane są przechowywane w pamięci RAM, a więc pod tym kątem są tak samo wydajne jak zmienne lokalne.

Wniosek? Generalnie kierujemy się zasadą: zmiennych globalnych należy używać tylko wtedy gdy nie jesteśmy w stanie rozwiązać danego problemu przy pomocy zmiennych lokalnych.

2. Część (skripterów?) przecenia możliwości Skripta i myśli, że jest on w stanie w 100% zastąpić pluginy. Wtedy zaczyna się tworzenie w nim wielkich projektów - od anticheatów, poprzez całe tryby, kończąc na skryptach obsługujących dosłownie wszystko.

Skript został stworzony w celu dodawania mało skomplikowanych mechanizmów i rzeczy na serwer gdy tworzenie osobnego pluginu jest zwyczajnie nieopłacalne. Plugin ten nie jest i nigdy nie będzie dobry do tworzenia ogromnych projektów.
Oczywiście, istnieją wielkie dzieła napisane wydajnie w Skript, jednakże jest to nie więcej niż promil podjętych prób tworzenia ich. Dlatego też odradzam takiego postępowania dopóki nie jest się absolutnie pewnym tego co się robi.

3. Na koniec jeszcze jedno. Zła reputacja Skripta bierze się w dużej mierze z ignorancji rzeszy jego użytkowników, którzy myślą, że to akurat ich skrypty są dobre. Nie, nie są. Wystarczy spojrzeć na to, że połowa (jak nie więcej) skrypterów nie potrafi posługiwać się dokumentacją, więc nie ma mowy o pisaniu dobrego (to znaczy, wydajnego i schludnego) kodu.

Myślę, że powiedziałem o wszystkich ważniejszych rzeczach. Gdyby jeszcze zrodziły się jakieś pytania, śmiało je można zadawać. Z miłą chęcią odpowiem.

Pozdrawiam.

36 minut temu, Kormic napisał:

Dobrze. Widzę, że trzeba wyjaśnić kilka spraw.
Lakonicznie odpowiadając na Pana pytanie, Skript sam w sobie nie jest obciążający dla serwera. To źle i niewydajnie napisane skrypty są powodem obciążenia serwera. A teraz pora na dłuższą odpowiedź.
 

1. Wiele osób piszących w Skript w nonszalancki sposób:

• wykorzystuje zapis zmiennych globalnych,
• tworzy ogromne pętle działające na wielu danych,
• wykonuje kosztowne w zasobach serwera operacje w sposób synchroniczny, podczas gdy często istnieje możliwość wykorzystania takich dodatków jak skript-reflect (czy też SkQuery) do asynchronicznego wykonania kodu.

System zmiennych globalnych w Skript jest bardzo niewydajnie napisany, co zresztą wielokrotnie przyznawali twórcy pluginu. Niewydajność wynika z tego, że Skript każdą zmienną (globalną) zapisuje do pamięci RAM (rzecz normalna), ale również na dysku. Innymi słowy, za każdym razem gdy skrypt wykonuje efekt 'set {zmienna::globalna} to <coś>', zmiana ta jest zapisywana na dysku. W przypadku zapisu setek (a czasem tysięcy) zmiennych w jednym momencie, taka operacja staje się niezwykle kosztowna.
Trzeba również pamiętać o tym, że Skript "lubi" często przeorganizowywać plik ze zmiennymi globalnymi (variables.csv), co jest kolejnym powodem niskiej wydajności tego systemu.

W ramach ciekawostki powiem, że na pewno do niedawna (a może i do teraz, kto wie) poniższy kod był w stanie zatrzymać pracę serwera (wywalić go).

command /test:
	trigger:
		loop 10000 times:
			set {testVariable::%loop-number%} to loop-number

W przypadku używania zmiennych lokalnych takiego ryzyka nie ma, gdyż są one zapisywane jedynie w pamięci RAM.

Dodam, że miłą alternatywą dla zmiennych globalnych może się okazać dodatek skript-yaml. Ogromną przewagą tego pluginu jest fakt, iż to skrypter decyduje kiedy dane mają być zapisane na dysku, nie Skript (czyli właściwie każdorazowo gdy zapisujemy zmienną globalną). Do momentu zapisu na dysku dane są przechowywane w pamięci RAM, a więc pod tym kątem są tak samo wydajne jak zmienne lokalne.

Wniosek? Generalnie kierujemy się zasadą: zmiennych globalnych należy używać tylko wtedy gdy nie jesteśmy w stanie rozwiązać danego problemu przy pomocy zmiennych lokalnych.

2. Część (skripterów?) przecenia możliwości Skripta i myśli, że jest on w stanie w 100% zastąpić pluginy. Wtedy zaczyna się tworzenie w nim wielkich projektów - od anticheatów, poprzez całe tryby, kończąc na skryptach obsługujących dosłownie wszystko.

Skript został stworzony w celu dodawania mało skomplikowanych mechanizmów i rzeczy na serwer gdy tworzenie osobnego pluginu jest zwyczajnie nieopłacalne. Plugin ten nie jest i nigdy nie będzie dobry do tworzenia ogromnych projektów.
Oczywiście, istnieją wielkie dzieła napisane wydajnie w Skript, jednakże jest to nie więcej niż promil podjętych prób tworzenia ich. Dlatego też odradzam takiego postępowania dopóki nie jest się absolutnie pewnym tego co się robi.

3. Na koniec jeszcze jedno. Zła reputacja Skripta bierze się w dużej mierze z ignorancji rzeszy jego użytkowników, którzy myślą, że to akurat ich skrypty są dobre. Nie, nie są. Wystarczy spojrzeć na to, że połowa (jak nie więcej) skrypterów nie potrafi posługiwać się dokumentacją, więc nie ma mowy o pisaniu dobrego (to znaczy, wydajnego i schludnego) kodu.

Myślę, że powiedziałem o wszystkich ważniejszych rzeczach. Gdyby jeszcze zrodziły się jakieś pytania, śmiało je można zadawać. Z miłą chęcią odpowiem.

Pozdrawiam.

Dziękuje za wytłumaczenie wszystkiego. Generalnie na swoim serwerze za pomocą skripta mam zrobione: automatyczna wymiana na bloki, bany, komendy takie jak msg, helpop czy gamma, oraz system sprawdzania. Myśli Pan, że z takimi skryptami serwer może pociągnąć dużo graczy?

2 minuty temu, TeZetYT napisał:

Dziękuje za wytłumaczenie wszystkiego. Generalnie na swoim serwerze za pomocą skripta mam zrobione: automatyczna wymiana na bloki, bany, komendy takie jak msg, helpop czy gamma, oraz system sprawdzania. Myśli Pan, że z takimi skryptami serwer może pociągnąć dużo graczy?

Najbardziej podejrzliwe są skrypt dodający automatyczną wymiane na bloki i skrypt dodający system sprawdzania. Jeżeli są one w większości oparte na listenerach zdarzeń (a więc są  asynchroniczne, ale tylko do pewnego stopnia, bo są zależne od zegara gry) i nie występują w nich duże pętle czy też długie kody wykonywane w krótkich odstępach czasu (periodicale) oraz wielkie operacje działające na wielu zmiennych globalnych w jednym momencie, wszystko powinno być w porządku.

Skrypty pozwalające na banowanie i dodające komendy takie jak /msg, /helpop i /gamma nie budzą moich podejrzeń. Zdaje się, że widziałem skrypt dodający ostatnią z nich, gdyż Pan ją pokazywał. Niczego strasznego tam nie widziałem, więc mogę stwierdzić, że nie będzie on generował dużego obciążenia na serwerze. O pierwszych dwóch komendach nie wspomnę, gdyż ich implementacja jest trywialna - nie ma potrzeby tworzenia tam jakichkolwiek zmiennych globalnych i pętli.

Pozdrawiam.

13 godzin temu, Kormic napisał:

Najbardziej podejrzliwe są skrypt dodający automatyczną wymiane na bloki i skrypt dodający system sprawdzania. Jeżeli są one w większości oparte na listenerach zdarzeń (a więc są  asynchroniczne, ale tylko do pewnego stopnia, bo są zależne od zegara gry) i nie występują w nich duże pętle czy też długie kody wykonywane w krótkich odstępach czasu (periodicale) oraz wielkie operacje działające na wielu zmiennych globalnych w jednym momencie, wszystko powinno być w porządku.

Skrypty pozwalające na banowanie i dodające komendy takie jak /msg, /helpop i /gamma nie budzą moich podejrzeń. Zdaje się, że widziałem skrypt dodający ostatnią z nich, gdyż Pan ją pokazywał. Niczego strasznego tam nie widziałem, więc mogę stwierdzić, że nie będzie on generował dużego obciążenia na serwerze. O pierwszych dwóch komendach nie wspomnę, gdyż ich implementacja jest trywialna - nie ma potrzeby tworzenia tam jakichkolwiek zmiennych globalnych i pętli.

Pozdrawiam.

do wymiany na automatyczne bloki używam pętli WHILE a do sprawdzania używam jedej zmiennej globalnej grupowej (chyba tak to się nazywa) wygląda ona tak: {miejsca::*}

a tak to przypisane tylko do gracza, np. {zmienna::%player%}

3 godziny temu, TeZetYT napisał:

do wymiany na automatyczne bloki używam pętli WHILE a do sprawdzania używam jedej zmiennej globalnej grupowej (chyba tak to się nazywa) wygląda ona tak: {miejsca::*}

a tak to przypisane tylko do gracza, np. {zmienna::%player%}

Co do pierwszego, nie podoba mi się ta pętla 'while'. Zgaduję, że w Pana kodzie wygląda to tak jak poniżej.

on join:
	while player is online:
		# [...]
		wait {_timespan}

Proszę zauważyć, że powyższy skrypt powoduje, iż na serwerze działa jednocześnie n pętli 'while', gdzie n to liczba graczy obecnych na serwerze. Lepiej będzie to rozwiązać zwykłym periodicalem.
Może Pan pomyśleć o tym w ten sposób, że lepiej zatrudnić jednego pracownika obsługującego n graczy w jednej chwili czasu z daną częstotliwością niż zatrudnić n pracowników obsługującego każdego gracza indywidualnie z tą samą częstotliwością, ale chwilami wykonywania kodu przesuniętymi w czasie względem siebie.
Oczywiście, w przypadku periodicala będą widoczne wzrosty użycia zasobów serwera (procesor, pamięć ram, itd.), ale pętle while nigdy nie będą lepszym rozwiązaniem. Mogą być co najwyżej tak samo wydajne, bo ich użycie zasobów jest bliskie równomiernego w czasie, chociaż obciążenie jest średnio wyższe niż w przypadku periodicala.
Poza tym - myślę, że to istotna i dość oczywista zaleta - łatwiej jest zarządzać jedną pętlą niż n pętlami.

Jeśli chodzi o drugie, w użytku jest określenie "lista zmiennych", ale myślę, że każdy zrozumie co Pan ma na myśli poprzez zmienną grupową.
To czy jest ona używana w skrypcie, niewiele mi mówi. Ważne jest to jak jest używana. To samo tyczy się zmiennych globalnych przypisanych do graczy.
Jeżeli one nie są używane nagminnie i w ogromnych ilościach, nie powinno być problemu.

Pozdrawiam.

W dniu 21.06.2024 o 15:38, Kormic napisał:

Co do pierwszego, nie podoba mi się ta pętla 'while'. Zgaduję, że w Pana kodzie wygląda to tak jak poniżej.

on join:
	while player is online:
		# [...]
		wait {_timespan}

Proszę zauważyć, że powyższy skrypt powoduje, iż na serwerze działa jednocześnie n pętli 'while', gdzie n to liczba graczy obecnych na serwerze. Lepiej będzie to rozwiązać zwykłym periodicalem.
Może Pan pomyśleć o tym w ten sposób, że lepiej zatrudnić jednego pracownika obsługującego n graczy w jednej chwili czasu z daną częstotliwością niż zatrudnić n pracowników obsługującego każdego gracza indywidualnie z tą samą częstotliwością, ale chwilami wykonywania kodu przesuniętymi w czasie względem siebie.
Oczywiście, w przypadku periodicala będą widoczne wzrosty użycia zasobów serwera (procesor, pamięć ram, itd.), ale pętle while nigdy nie będą lepszym rozwiązaniem. Mogą być co najwyżej tak samo wydajne, bo ich użycie zasobów jest bliskie równomiernego w czasie, chociaż obciążenie jest średnio wyższe niż w przypadku periodicala.
Poza tym - myślę, że to istotna i dość oczywista zaleta - łatwiej jest zarządzać jedną pętlą niż n pętlami.

Jeśli chodzi o drugie, w użytku jest określenie "lista zmiennych", ale myślę, że każdy zrozumie co Pan ma na myśli poprzez zmienną grupową.
To czy jest ona używana w skrypcie, niewiele mi mówi. Ważne jest to jak jest używana. To samo tyczy się zmiennych globalnych przypisanych do graczy.
Jeżeli one nie są używane nagminnie i w ogromnych ilościach, nie powinno być problemu.

Pozdrawiam.

a to nie będzie lagować serwera?

6 minut temu, TeZetYT napisał:

a to nie będzie lagować serwera?

O co Pan pyta? Proszę się odnieść do konkretnej części mojego postu, bo nie wiem o której jego części Pan mówi.

Pozdrawiam.

W dniu 21.06.2024 o 15:38, Kormic napisał:

Lepiej będzie to rozwiązać zwykłym periodicalem.

to

20 godzin temu, TeZetYT napisał:

to

Dosłownie pół jego wypowiedzi dotyczy tego aspektu, wystarczy przeczytać.