Co myślicie aktualnie o pluginie FunnyGuilds? Czy opłaca się go używać?

[ArrowDev]

UWAGA! TEN KOMUNIKAT MA PRZESTRZEC PRZED DZIAŁANIEM FUNNY GUILDS, NIE ZRAZIĆ. PÓKI WASZ SERWER NIE BĘDZIE MIAŁ WIĘCEJ NIŻ KILKADZIESIĄT TYSIĘCY GRACZY W BAZIE MOGĄ SIĘ ZACZĄĆ PROBLEMY Z WYDAJNOŚCIĄ I RAMEM. DO TEGO CZASU POWINNO BYĆ OK.
 

Witam,

funny guilds jest aktualnie prawdopodobnie najpopularniejszym pluginem wprowadzającym gildie na serwer minecrafta. Na pierwszy rzut oka prezentuje się bardzo dobrze. Tab do skonfigurowania, wiadomości, gildie w mysql, wszystko. Niestety punkt postrzegania funny guildsów zmienia się dopiero po zagłębieniu się w source code. Ja wiem, że tego co zostało zrobione już chyba nie da się zmienić. Ale żeby ładować wszystkich graczy z bazy do RAMu przy starcie?! Gildie - przeboleje, regiony - spoko, ale ładowanie graczy to jest przesada. Przy dużym serwerze w mysqlu może ich być nawet kilkadziesiąt do kilkuset tysięcy. Chcecie tego potwora trzymać w ramie? Do tego dochodzi jeszcze zapisywanie tych obiektów w liście, a nie w mapie. Czyli na przykład, gdy ów plugin chce zmienić graczowi liczbę rankingu musi przerezać w skrajnych przypadkach całą listę z graczami i porównać ich nicki. Nie wspominając już o mysql... Tu jest istna masakra. Sama tabelka na gildie ma 16 kolumn. Tabelka na graczy już spokojniej, bo tylko 7. Jednak pojawia się problem. Primary key'em jest uuid. W mojej opinii powinien nim być int, lub bigint z auto_increment. Bazie jest o wiele łatwiej porównać liczbę, niż uuid gracza, które właściwie jest tekstem. Uuid wygląda mniej więcej tak: 974dc589-14ef-4f5f-ae56-4bcb18953950. Int lub bigint wygląda tak: 1 (przy pierwszym wpisie do bazy). Przewijając tak sobie source code natknąłem się na jeszcze jedną ciekawą rzecz. Funny guilds tworzą z tego co widzę JEDEN wątek, który ma obsługiwać, wymieniam: tworzenie gildii, zapisywanie danych, aktualizacje punktów gildii i gracza, aktualizacje rankingu gildii i gracza, wysyłanie tablisty, update scoreboarda i jeszcze kilka innych. Już chyba lepiej tworzyć i usuwać nowy wątek przy wykonywaniu akcji... Ja też nie spodziewałem się takich rzeczy po dzikoysku.

[cycuszek98]

A Co sądzisz o funnyguild reloaded wpisz w Google niby on ma coś piprawiione dasz znać co i jak? Pozdrawiam

 

 

Pisane z telefonu

[ArrowDev]

@up

Zmienia się styl kodu, lepsze tabelki i ogólnie sql. Primary key'em nie jest uuid, tylko int, co idzie na plus. Nadal jest ten jeden wątek. Reszta kopiuj, wklej funny guilds. :P

[cycuszek98]

Hymm w takim wypadku lepiej zastosować te co podałem.. Nie są idealne Ale w jakiś sposób obniżają zużycie serwera..

[GotoFinal]

UWAGA! TEN KOMUNIKAT MA PRZESTRZEC PRZED DZIAŁANIEM FUNNY GUILDS, NIE ZRAZIĆ. PÓKI WASZ SERWER NIE BĘDZIE MIAŁ WIĘCEJ NIŻ KILKADZIESIĄT TYSIĘCY GRACZY W BAZIE MOGĄ SIĘ ZACZĄĆ PROBLEMY Z WYDAJNOŚCIĄ I RAMEM. DO TEGO CZASU POWINNO BYĆ OK.

 

Witam,

funny guilds jest aktualnie prawdopodobnie najpopularniejszym pluginem wprowadzającym gildie na serwer minecrafta. Na pierwszy rzut oka prezentuje się bardzo dobrze. Tab do skonfigurowania, wiadomości, gildie w mysql, wszystko. Niestety punkt postrzegania funny guildsów zmienia się dopiero po zagłębieniu się w source code. Ja wiem, że tego co zostało zrobione już chyba nie da się zmienić. Ale żeby ładować wszystkich graczy z bazy do RAMu przy starcie?! Gildie - przeboleje, regiony - spoko, ale ładowanie graczy to jest przesada. Przy dużym serwerze w mysqlu może ich być nawet kilkadziesiąt do kilkuset tysięcy. Chcecie tego potwora trzymać w ramie? Do tego dochodzi jeszcze zapisywanie tych obiektów w liście, a nie w mapie. Czyli na przykład, gdy ów plugin chce zmienić graczowi liczbę rankingu musi przerezać w skrajnych przypadkach całą listę z graczami i porównać ich nicki. Nie wspominając już o mysql... Tu jest istna masakra. Sama tabelka na gildie ma 16 kolumn. Tabelka na graczy już spokojniej, bo tylko 7. Jednak pojawia się problem. Primary key'em jest uuid. W mojej opinii powinien nim być int, lub bigint z auto_increment. Bazie jest o wiele łatwiej porównać liczbę, niż uuid gracza, które właściwie jest tekstem. Uuid wygląda mniej więcej tak: 974dc589-14ef-4f5f-ae56-4bcb18953950. Int lub bigint wygląda tak: 1 (przy pierwszym wpisie do bazy). Przewijając tak sobie source code natknąłem się na jeszcze jedną ciekawą rzecz. Funny guilds tworzą z tego co widzę JEDEN wątek, który ma obsługiwać, wymieniam: tworzenie gildii, zapisywanie danych, aktualizacje punktów gildii i gracza, aktualizacje rankingu gildii i gracza, wysyłanie tablisty, update scoreboarda i jeszcze kilka innych. Już chyba lepiej tworzyć i usuwać nowy wątek przy wykonywaniu akcji... Ja też nie spodziewałem się takich rzeczy po dzikoysku.

Boże, ten rozmiar tekstu...

 

 

 

Ale żeby ładować wszystkich graczy z bazy do RAMu przy starcie?! Gildie - przeboleje, regiony - spoko, ale ładowanie graczy to jest przesada.

Zależy jak na to spojrzeć, jak chcemy mieć wszystkie topki, komendy, zarządzanie graczami z gildii offline... To musimy to załadować, a ram jest tani, a tutaj go dużo nie zjadamy, mało kiedy dasz radę dobić do 1 kB na gracza.

A ładować przy komendach to większa bieda, po co poświęcać procka dla kilku kB ramu.

 

A gildie zdecydowanie trzeba ładować wszystkie, bo często mogą być potrzebne od sprawdzania różnych rzeczy.

 

 

 

Co do użycia mapki, mapka po UUID byłaby oczywiście lepsza od listy, tutaj nie ma co marudzić.

Nie wspominając już o mysql... Tu jest istna masakra. Sama tabelka na gildie ma 16 kolumn. Tabelka na graczy już spokojniej, bo tylko 7. Jednak pojawia się problem. Primary key'em jest uuid. W mojej opinii powinien nim być int, lub bigint z auto_increment. Bazie jest o wiele łatwiej porównać liczbę, niż uuid gracza, które właściwie jest tekstem. Uuid wygląda mniej więcej tak: 974dc589-14ef-4f5f-ae56-4bcb18953950.

Co ma do czegokolwiek ilość kolumn w bazie danych?

skoro potrzebuje zapisać np prefix, nazwę itd itp, to niby co ma zrobić? podzielenie tego na 2 tabelki to by był kretynizm skoro obie opisują ten sam element....

 

Primary Key po UUID nie jest zły, co najwyżej dziku źle go zrobił, bo dał typ jako text... bo nie wiem skąd ty wymysliłeś że UUID to text? UUID to liczba, prosta 128 bitowa liczba, 2x long. I tak powinna być zapisywana do bazy danych, jako BINARY dla 128 bitów.

Wtedy może śmigać pięknie.

Przewijając tak sobie source code natknąłem się na jeszcze jedną ciekawą rzecz. Funny guilds tworzą z tego co widzę JEDEN wątek, który ma obsługiwać, wymieniam: tworzenie gildii, zapisywanie danych, aktualizacje punktów gildii i gracza, aktualizacje rankingu gildii i gracza, wysyłanie tablisty, update scoreboarda i jeszcze kilka innych. Już chyba lepiej tworzyć i usuwać nowy wątek przy wykonywaniu akcji... Ja też nie spodziewałem się takich rzeczy po dzikoysku.

Jeszcze głupsze byłoby tworzenie i usuwanie wątku przy każdej akcji... 

Tak samo jak nie widzę zbytnio sensu dzielenia tego na więcej wątków, to nie jest masakryczna ilość obliczeń, i jak już dzielić to na ThreadPoola i zmieniać jego wielkość w zależności od obciążenia lub dać do konfiguracji.

 

 

A same gildie dziku pisał że dawno już porzucił

I dobrze wie że są rakotwórcze, to jeden z powodów dla którego pewnie tego nie rozwija, nie opłaca się naprawiać, bo by trzeba było robić od 0.

A sam plugin jest po prostu stary, kiedy widocznie dziku jeszcze nie wiedział tyle co trzeba

Samego pluginu nie bronie, bo na prawdę jest zrypany, ale twoje argumenty są jeszcze bardziej zrypane.

[dzikoysk]

Mehhh... Fascynuje mnie to, że mija rok, a fg nadal jest na tylu serwerach - mimo wielokrotnego powtarzania, że to plugin porzucony, którego nie radzę używać. Powychodziły nowe gildie z ciągłym wsparciem ich autorów, głupotą jest więc używanie moich.

 

Warto pogodzić się z tym, że z mojej strony ten plugin aktualizacji już nie utrzyma, a na nowy musielibyście sie zrzucić

 

P.S.

 

Funny guilds tworzą z tego co widzę JEDEN wątek, który ma obsługiwać, wymieniam: tworzenie gildii, zapisywanie danych, aktualizacje punktów gildii i gracza, aktualizacje rankingu gildii i gracza, wysyłanie tablisty, update scoreboarda i jeszcze kilka innych. Już chyba lepiej tworzyć i usuwać nowy wątek przy wykonywaniu akcji... Ja też nie spodziewałem się takich rzeczy po dzikoysku

 

@ArrowDev Emmmm kotku, tworzenie nowych wątków wcina zasoby, więc gdyby to wszystko przerzucić na Twój system, to by dopiero było straszne. Tworzyć nowy wątek dla każdej akcji - chore Kiedyś patrzyliśmy na 200 osobowym serwerze ile mniej więcej wykorzystuje fg w tym oddzielnym wątku, to było to koło 15%. Najlepszy byłby tu ThreadPool, ale i tak prawdopodobnie stanęłoby to na 1 wątku.