Dalszy tunning

Wraz ze wzrostem ilości podłączonych hostów miałem coraz większy problem z błędami „gateway time out”,  który zwalałem na serwer synology… bo to on służy mi jako reverse proxy i przekierowuje połączenia na serwer boinca.

Niestety przez moje zaślepienie straciłem ponad miesiąc bo zamiast zmienić perspektywę na błąd cały czas szukałem problemy na moim NAS’ie. Rozwiązanie było bardzo proste, a wręcz żenujące… po postawieniu projektu na nowym komputerze nie sprawdziłem standardowej konfiguracji Apache2 (a zawsze jest to jeden z pierwszych kroków jakie robię na nowym linux’ie)… i tak o to wystarczyło ustawić moje standardowe i sprawdzone w boju ustawienia serwera WWW:

 StartServers 15
 MinSpareThreads 50
 MaxSpareThreads 100
 ThreadLimit 64
 ThreadsPerChild 50
 MaxRequestWorkers 8192
 MaxConnectionsPerChild 10000

Zapewne można by coś jeszcze lepiej zrobić, ale taka konfiguracja radzi sobie z podłączami hostami na poziomie 250,000 <- a co dopiero przy moich 7,500-8,000

Odciążanie serwera GG@h NCI

Niestety zauważyłem, że w momencie generowania zadań (szczególnie) dla wszystkich 4 aplikacji na raz, serwer nie wyrabia się z żądaniami dla podłączających się do niego komputerów…  zaś trzeba było siąść i wymyślić rozwiązanie…

Długo nie musiałem się męczyć, ponieważ zastosowałem wyjście awaryjne jakie od roku stosuje w DrugDiscovery@Home. Całość podejścia polega na tym, iż pliki zadań są generowane u mnie na serwerze i udostępnione dla serwera boincowego po NFS’ie.  Na DD@H nie ma problemu z wydajnością serwera za jest problem z wolnym miejscem na dysku <- jedna seria zadań dla sminy i viny to ok.750-800GB. Na GG@h NCI rozwiązanie sprawdziło się idealnie w ten sam sposób… pliki generuje na komputerze z analizatorami które po optymalizacji w zasadzie nie obciążają go, następnie serwer boinca NCI sprawdza co 15-30 minut czy ilość rezerwowych WU nie spadła poniżej 35,000 <- jeśli tak to pobiera 10,000 plików z serwera i robi z nich WU. Dzięki temu projekt działa szybciej i sprawniej. Kolejny mały sukces.

Optymalizacja analizatorów

  1. Z 8 skryptów, które potrafiły przy większej ilości wyników do analizy zabić komputer przerabiający dane, pozostały 4 uniwersalne skrypty z parametrami.  Drugim etapem było uruchamianie skryptów po kolei, zamiast wszystkie na raz.
  2. Jednak najważniejszym krokiem, który planowałem od ponad 2 lat (a czego nie zrobiłem z braku chęci) było tworzenie przed każdym uruchamianiem analizatorów tabeli tymczasowej z informacją o użytkownikach i plikach wynikowych jakie zwrócili w GG@h NCI. Wprowadzenie tego rozwiązania było prawdziwym kamieniem milowym ponieważ czas jednego zapytania do bazy danych zmniejszył się z nawet 5 minut do 5 sekund <- dosłownie.  Teraz można sobie wyobrazić, że każdy analizator robi kilkaset (a czasami kilka tysięcy) takich zapytań. Teraz analizatory przerabiają w 5 minut to co poprzednio w 2 dni.Postęp widać… chyba 😉

Tic-tac-toe 1 v.1.0

Pierwszy wynik zabaw z silnikiem Unity… <- wynik jednego wieczoru.
Nie ma żadnych bajerów ani miodnej grafiki 🙂 ale naukę od czegoś trzeba zacząć.

Jakby ktoś chciał poklikać dla zabawy: Tic-tac-toe 1 v.1.0 (32 pobrania)

Co można w tej wersji:
1. Granie w 2 osoby
2. Na początku pierwszy gracz wybiera jakim znakiem chce grać

Nie wiele, ale początek dobry

Unity

Od chyba 20 lat marzę o napisaniu jakiejś fajnej gry, nie musi być od razu hitem w stylu Wiesia 3 😉
Idiotycznym problemem przez te wszystkie lata nie był brak chęci, wiedzy, pomysłów itp ale moje nie dojrzałe podejście tzn.: a każdym razem, kiedy siadałem do stworzenia czegokolwiek grywalnego ubzdurałem sobie, że muszę sam napisać silnik graficzny i wogule wszystko sam. Oczywiście po 2-3 miesiącach dłubania w OpenGL lub DirectX każdy projekt był porzucany i zakopywany pod stertą innych niespełnionych tworów. Postanowiłem, że mam dość takiego podejścia i końcem zeszłego roku zainteresowałem się na poważnie istniejącymi już silnikami, których jest nie mało <- ja naliczyłem 15 sztuk. Jednak po 2-3 godzinach na mojej linii frontu pozostały już tylko dwa: Unity i Unreal.
1. Unreal : jest dość fajny jednak 90% gier na nim oparty są monotonne i na jedno kopyto <- większość to ładne FPS i tyle.
2. Unity : na tym silniku tworzony jest cały wachlarz gier od mini produkcji na androida/iOS aż do tytułów AAA <- każdy gatunek i każda wielkość

Koniec końców wybór padł na Unity i na razie tego nie żałuję.
Jedyne czego mi teraz brakuje do większej „produkcji” to 1-2 grafików…
Do próbnych projektów i nauki będę używał darmowy materiałów z internetu.

Nowy rok?

Nowy czy nie… każdy wygląda identycznie… 365 dni tego samego, więc co tu świętować.
Ja dla odmiany w tym roku rezygnuję z jakichkolwiek postanowień i rzucam się w macki improwizacji.
Nie mam zamiaru robić zbędnych planów, które później zależą od kogo innego niż ja, a przez to stają się nie wykonalne.

Na początek musiałem postawić na nowo swojego pseudo-bloga… nie nie było to moim ani postanowieniem ani planem… po prostu po ponad chyba 6 latach używania poprzedniego wszystko się sypło bo wszystkie 50 wtyczek jakie były uruchomione zaczęły się gryźć między sobą… no cóż życie.

Stary blog będzie wisiał pod: Stary blog