Domowe rozwiązanie pod wiele skryptów uruchomionych jednocześnie

[Samael 0]

Witam wszystkich.

Na początku tego roku, na potrzeby tworzonego przeze mnie oprogramowania parsującego, kupiłem cztery mocne jednostki centralne (AMD 8600K 4x4Ghz, 32GB RAM, 4x128GB SSD RAID 0) których zadaniem było (a w zasadzie nadal jest) przetwarzanie danych i wykonywanie wszystkich obliczeń związanych z tym oprogramowaniem.

 

 

Dotychczas skrypty były rozdzielone i mogły działać w konfiguracji dwa na jednym komputerze.

Ale z racji rozwijania się mojego projektu przyszła potrzeba zwiększenia ilości tych skryptów.

Obecnie jest już ich 28, i zaczyna stanowić to problem ponieważ mogą być uruchamiane po maksymalnie cztery jednocześnie na maszynę (powyżej tego serwer Apache traci stabilność i często przestaje działać).

Docelowo całe oprogramowanie może składać się z nawet 200 - 300 składników.

 

Zastanawiam się jak mogę zwiększyć wydajność, zmienić konfigurację czy system (mimo prób z Ubuntu, pozostałem przy Windowsie - ale to się musi chyba zmienić). Myślałem nad połączeniu maszyn w klaster lub stworzeniu vps'a. Ale mówiąc szczerze jestem zielony w tych tematach i nawet nie wiem czy dobrze główkuję bo znajomość tych terminów określiła dla mnie wikipedia, poza tym nie wiem co byłoby lepszym rozwiązaniem aby wykorzystać pełną moc komputerów, tak aby skrypty mogły działać jednocześnie.

 

Tym tematem chciałbym spytać o sporą ilość zagadnień:

1. Czym jest dokładnie VPS a czym klaster? Jakie są różnice?
2. Jakie rozwiązanie pozwoli na uruchomienie jednocześnie 200 skryptów php (obsługa plików (zapis/edycja), DOM i MySQL?)?
3. Jak stworzyć VPS lub klaster? Jaki sprzęt do tego potrzebuję? Jakie oprogramowanie i system operacyjny?
4. Jak wygląda sprawa późniejszego rozszerzania takiej konfiguracji o nowe jednostki centralne?
5. Czy jest jakiś rzetelny manual pokazujący krok po kroku jak zainstalować Ubuntu server i go skonfigurować pod vps lub klaster?
6. Czy istnieje możliwość wywoływania skryptów z terminala bez użycia trybu graficznego (skrypty nie mają w sobie szaty graficznej, wywalają jedynie datę początkową i końcową)?
7. Czy przy wywoływaniu skryptów z terminala będą obsługiwane pliki graficzne (zapis na dysk + odczyt i edycja + ponowny zapis)?
8. Czy jest możliwość zautomatyzowania procesu uruchamiania skryptu? Obecnie mogę korzystać z odświeżania przez <meta> ale czy będzie to działać bez przeglądarki?

 

To są główne pytania, w głowie siedzi mi jeszcze z tuzin innych, ale boję się, że tą salwą już nadużywam Waszej cierpliwości.

Za wszystkie odpowiedzi i pomoc serdecznie dziękuję.

Pozdrawiam!

 

[gutek 23]

Dopóki nie będzie informacji jak działają te skrypty to ciężko coś konkretnego sugerować, ja mogę napisać od siebie że np. na serwerze o konfiguracji E3-1240v2, 32 gb ram, 2 x 120 gb ssd mam bez problemu uruchomionych 5000 skryptów php jednocześnie, które realizują różne zadania. Sugerowałbym również znalezienie wąskiego gardła, ja takich w napisanej przez siebie aplikacji przez prawie 3 lata znalazłem setki i co ciekawe z każdym tygodniem są kolejne modyfikacje, dzięki którym osiągam lepsze wyniki (większą wydajność). Nie znam się na tyle na rozwiązaniach serwerowych microsoftu ale w linuxie takie ilości nie robią wrażenia na normalnym sprzęcie przy odpowiedniej optymalizacji.

 

Ad1)

vps to wirtualna maszyna (może być ich więcej niż jedna) na serwerze fizycznym

klaster to współpracujących / spiętych ze sobą kilka serwerów fizycznych w niby jeden

 

Ad2)

tu polecam optymalizację samych skryptów i nakład na odpowiedni serwer bazy danych tzn dyski ssd w raid 10, szybki cpu, wyłączone tryby oszczędzania energii itp. do tego ważne aby serwer mysql był dobrze skonfigurowany + odpowiednie rodzaje tabel i indeksy.

 

Ad3)

linux i tyle.

 

ad4)

uzależnione od konfiguracji i pomysłu. u mnie każdy serwer pracuje jako samodzielna maszyna ale wspólnie realizują jakieś tam zadania, nie bawię się w klastry bo się na tym zbytnio nie znam ale rozdzieliłem po swojemu zadania na prawie 10 maszyn i działa:)

 

ad5)

polecam howtoforge.com

 

ad6)

tak, bez problemu po zalogowaniu np. poprzez ssh

 

ad7)

to uzależnione od samej aplikacji

 

ad8)

konfiguracja aplikacji + np. cron

 

pytaj i się ucz linuxa:)

Edytowano Styczeń 28, 2016 przez gutek (zobacz historię edycji)

[Misiek08 285]

Klaster - raczej nie. VPSy - jak się nie znasz, to będzie tylko problem.

 

2) każde o ile dowiemy się co mniej więcej robią skrypty. Po prostu może robisz coś źle, a może rzeczywiście masz problem, który wymaga dużo mocy.

 

6,7) tak, skoro nie mają GUI to nie potrzebują GUI. Obrabianie grafiki to robota matematyczna, więc bez GUI się obejdzie.

 

8) jeżeli teraz do tych skryptów korzystasz z windowsa i przeglądarki tylko dlatego, żeby się odpalał co chwilę to zdecydowanie robisz coś źle. Jak nie chcesz pisać tutaj - pisz na PW, zaciekawił mnie Twój projekt, napisz co robi i wtedy będzie można udzielić więcej i konkretniejszych rad.

[Samael 0]

Nie jest to żaden sekret.

Stworzyłem kawał czasu temu serwis który miał działać na zasadzie społecznego carfax.

Szedł dość opornie, ludzie chcieli otrzymywać dane ale już nie tak ochoczo je dodawać.

Napisałem więc skrypt który miał na początku przeszukiwać carfax w poszukiwaniu darmowych danych na temat auta z numerem VIN podanym przez użytkownika.

Potem przyszedł czas na otomoto, ebay, mobile.de (kompletny niewypał - zlikwidowali numery vin ;-/ )

Obecnie, tak jak wspomniałem, mam tych serwisów 28. Z czego 27 na serwisy ogłoszeniowe, zaś jeden na całe google.

Parsuje on dane które "wydają się" być na temat danego modelu pojazdu.

Zależnie od otrzymanego prawdopodobieństwa otrzymuje rating i trafia na listę oczekującą.

Potem moja skromna osoba sprawdza poprawność danych i akceptuje lub odrzuca wpis (dwa iframe'y jeden z formularzem i danymi drugi ze stroną z której jest pobrane).

 

Obecnie trafność danych parsowanych wynosi blisko 89% i rośnie (z 45% początkowych) w miarę udoskonalenia kodu.

Żaden z tych serwisów niema wyszukiwania po numerze VIN. Można co najwyżej zmniejszać zasięg poszukiwań poprzez filtrowanie danych wyszukiwanych do modelu, marki i rocznika wynikającego z dekodowania numeru vin - ten z kolei jest na chwilę obecną dość skromny, ponieważ dane mi potrzebne do tego dekodera są dość ciężkie do pozyskania.

 

Pobierane są (o ile są dostępne): przebieg, cena, zdjęcia, link.

Do tego parsowane jest dekodowanie numeru vin, oraz infromacje na temat plusów i minusów tego modelu/rocznika.

 

Mam nadzieję, że to nieco rozjaśniłem sytuację.

Pozdrawiam.

[Pan Kot 1535]

Projekt już zapewne zaszedł za daleko, ale ja bym coś takiego napisał w C#, spiął z bazą i moim serwisem, i odpalał via Mono-sgen na Linuxie, albo natywnie na Windowsie, co kto lubi.

 

PHP nigdy szybki ani wydajny nie był, nie powinno się na nim tworzyć długo-żyjących procesów bo po prostu się do tego nie nadaje, m.in dlatego masz w domyślnych konfiguracjach limit sekundowy wykonywania skryptu. Crawlery powinny być pisane w tym, co może w pełni wykorzystać potencjał OSu oraz połączenia internetowego (patrz C# i HttpClient - który zarządza connection poolem, robi reuse socketów, jest w stanie realizować wiele requestów na jednym porcie i więcej), a nie PHP który od zawsze był tworzony w oparciu o zrealizowanie konkretnej logiki i zwrócenie wyniku.

 

Ale mówię, zapewne za daleko to zaszło, żeby już coś tutaj kombinować, choć nadal sądzę, że będzie tylko gorzej i zareagowanie obecnie zaoszczędzi Ci koszta w przyszłości. Jestem 100% pewny, że ten crawler by działał wyśmienicie ze wszystkimi 28 serwisami na jednym mocnym dedyku, sam mam podobne rozwiązania w swoich projektach, tylko że nie stawiam ich na PHP. W godzinach szczytu moja aplikacja ma otwarte ponad 1000 portów i wszystkie są aktywnie używane.

Edytowano Styczeń 30, 2016 przez Archi (zobacz historię edycji)

[Gość l3szcz]

Łatwo zdekompilować / debugować kod C#? Aby chociażby odczytać dane do MySQL? Gdzieś słyszałem taką opinię.

[Pan Kot 1535]

Łatwo zdekompilować / debugować kod C#? Aby chociażby odczytać dane do MySQL? Gdzieś słyszałem taką opinię.

 

Jeśli ktoś hardcoduje poufne dane do logowania w kodzie to jest idiotą i należy mu dać po łbie za to co robi. Dane do logowania powinny być dostarczone w oddzielnym pliku i czytane po odpaleniu programu - ja mam je zapisane w postaci pliku XML.

 

No i w zależności od tego jak poniesie Cię fantazja, plik ten można szyfrować w dowolny sposób, jeśli zajdzie taka potrzeba.

 

Co do dekompilacji - C# jest kompilowany do kodu pośredniego, tak więc mając dobry dekompilator możesz to przywrócić do "mniej więcej" tego samego kodu źródłowego. Oczywiście są wszelkiej maści obfuscatory, które już tak przemielą ten kod, żebyś spędził co najmniej tydzień na doprowadzeniu go do postaci czytelnej dla człowieka - bo nie wyobrażam sobie, żebyś zrozumiał cokolwiek z takiego obfuscated kodu bez jego obróbki. Pytanie tylko po co - sprawa ma się podobnie jak z PHP, masz skrypt/binarkę to masz jej kod. Jak chcesz świadczyć usługę dla klienta to nie dajesz mu binarki tylko świadczysz usługę, a jeśli tworzysz dla klienta projekt w C# to z definicji należy mu się binarka i jej kod źródłowy, więc nie widzę use case'a "potrzeby" takiego obfuscatora.

Edytowano Styczeń 31, 2016 przez Archi (zobacz historię edycji)

[Gość l3szcz]

Rozumiem, miałem styczność z C# tylko przez chwilę ale stwierdziłem, że za bardzo się przyzwyczaiłem do PHP. Może mnie to do siebie przekona później.

 

Do autora - a nie myślałeś o nginxie?

[areq 0]

A nie możesz opalać części tych skryptów jako cli ? Po co męczyć server Apache/nginx

[Samael 0]

[...] ja bym coś takiego napisał w C#, spiął z bazą i moim serwisem, i odpalał via Mono-sgen na Linuxie, albo natywnie na Windowsie, co kto lubi.

 

PHP nigdy szybki ani wydajny nie był, nie powinno się na nim tworzyć długo-żyjących procesów bo po prostu się do tego nie nadaje, m.in dlatego masz w domyślnych konfiguracjach limit sekundowy wykonywania skryptu. Crawlery powinny być pisane w tym, co może w pełni wykorzystać potencjał OSu oraz połączenia internetowego (patrz C# i HttpClient - który zarządza connection poolem, robi reuse socketów, jest w stanie realizować wiele requestów na jednym porcie i więcej), a nie PHP który od zawsze był tworzony w oparciu o zrealizowanie konkretnej logiki i zwrócenie wyniku.

 

Ale mówię, zapewne za daleko to zaszło, żeby już coś tutaj kombinować, choć nadal sądzę, że będzie tylko gorzej i zareagowanie obecnie zaoszczędzi Ci koszta w przyszłości. Jestem 100% pewny, że ten crawler by działał wyśmienicie ze wszystkimi 28 serwisami na jednym mocnym dedyku, sam mam podobne rozwiązania w swoich projektach, tylko że nie stawiam ich na PHP. W godzinach szczytu moja aplikacja ma otwarte ponad 1000 portów i wszystkie są aktywnie używane.

 

I tu są dwa problemy.

 

Pierwszy nie znam C#. Kompletnie. Od lat staram się rozwijać w wąskim kierunku języka PHP.

Ostatnie dwa lata to duży skok w moich umiejętnościach i wiedzy, jednak tylko w PHP (no plus CSS, HTML, MySQL).

 

Drugi problem to rzeczywiście zaawansowany stan całego przedsięwzięcia.

Projekt jest już w zaawansowanym punkcie, a codzienne prace w wolnym czasie powodują, że nie stoję w miejscu.

 

Ciekawi mnie jak można by to wszystko usprawnić i przyspieszyć utrzymując się przy PHP.

Moim głównym pomysłem było, i nadal po cichu jest, stworzenie klastra z czterech naprawdę dobrych komputerów podłączonych obecnie do jednego łącza 100Mbps, ale już za trzy tygodnie dodatkowo dorzucę jedno lub dwa łącza LTE, dla dywersyfikacji obciążenia łącza - testowałem już to rozwiązanie w moim domu i świetnie się sprawdziło, średnia przeszło 30Mbps/28Mbps.

 

Mam nadzieję, że takie rozwiązania pomogą usprawnić mi działanie.

 

 

A nie możesz opalać części tych skryptów jako cli ? Po co męczyć server Apache/nginx

 

Mógłbyś rozwinąć myśl? Pisząc CLI masz na myśli terminal (command line)?

[gutek 23]

Nie pchaj się tak bardzo w sprzęt tylko zweryfikuj dokładnie linia po linii kod skryptu php, według mnie tam jest sporo problemów, które obciążają sprzęt. Tak jak Tobie napisałem, ja przez 3 lata optymalizacji skryptu uzyskałem taki efekt że z E5-2650v2, 128 gb ram przesiadłem się z aplikacją na e3-1240v2, 32 gb ram i jeszcze sporo zostało mocy Uważam, że warto jak najszybciej pracować na linuxie i tam odpalać swoją aplikację ale tylko w CLI. Więcej czasu poświęcisz na ogarnianie "klastra" niż na optymalizacje skryptu.

Edytowano Styczeń 31, 2016 przez gutek (zobacz historię edycji)

[areq 0]

Zobacz sobie http://php.net/manual/en/features.commandline.usage.php i pogonisz to na jednym cpu

Edytowano Styczeń 31, 2016 przez areq (zobacz historię edycji)

[PrecelusMaximus 53]

 

 

Mógłbyś rozwinąć myśl? Pisząc CLI masz na myśli terminal (command line)?

Mam pytanie, po co Ci serwer http? Jeśli swój skrypt pobiera jedynie kod strony, analizuje i na tej podstawie tworzy rekordy w bazie (tak zakładam) to żaden serwer http Ci nie potrzebny :-)

 

Php ma 2 wady. Pierwsza to prędkość - języki skryptowe nie są szybkie, druga to brak wątków, w środowiskach wieloprocesorowych/wielordzeniowych widać różnice pod warunkiem że poprawnie się tym "bawi". Oczywiście można odpalić kilka procesów, ale problemem jest współpraca między nimi.

 

Z tego co się orientuje c# czy java jest kompilowana do bytecode'u, co daje dość duże przyspieszenie. Dlatego każda aplikacja napisana w tych technologiach jest uważana za publiczną, można spokojnie zdekompilować kod (chociaż jest to czasochłonne i nie daje rezultatów 1:1). Szczerze do c# nie mogę się przyzwyczaić, lepiej rozumiem logikę javy. Jeśli chciałbyś naprawdę odczuć różnice, musiałbyś użyć c/c++. Jest pełno dostępnych praserów, webclientów itp.

 

Z opisu wynika, że nie masz zoptymalizowanego kodu. Dodatkowo zastanowiłbym się czy czasem portale z których korzystasz nie mają limitów zapytań do ich serwów z jednego IP.

Kolejna rzecz to sql. Sprawdź czy wszystkie zapytania są poprawne, potrzebne i odpowiednio zoptymalizowane. Często daje się typową "*" przy selectie, jak pobiera się dużo rekordów ta gwiazdka naprawdę boli. Bywa że jednym zapytaniem sql i funkcją agregującą można zlikwidować problem kilku czasochłonnych pętli w php'ie.

Praser. Czego używasz do analizy kodu? Zwykłych wyrażeń regularnych? Zauważyłem że czasem lepiej pracuje DOMDocument a czasem owe wyrażenia, trzeba czasem poeksperymentować.

[Pan Kot 1535]

Z tego co się orientuje c# czy java jest kompilowana do bytecode'u, co daje dość duże przyspieszenie. Dlatego każda aplikacja napisana w tych technologiach jest uważana za publiczną, można spokojnie zdekompilować kod (chociaż jest to czasochłonne i nie daje rezultatów 1:1). Szczerze do c# nie mogę się przyzwyczaić, lepiej rozumiem logikę javy. Jeśli chciałbyś naprawdę odczuć różnice, musiałbyś użyć c/c++. Jest pełno dostępnych praserów, webclientów itp.

 

C# jest kompilowane do kodu pośredniego (CIL), który jest potem wykonywany przez JIT.

 

Przy odpowiednio napisanym i zoptymalizowanym kodzie wszystkie proste operacje uzyskują szybkość tych znanych z C/C++, a niektóre wyższego poziomu jak np. operacje na HtmlDocument są nawet szybsze od tych c++.

 

C# jest kilka lat świetlnych przed javą, sam lubię go nazywać javą na steroidach. Jeśli środowisko docelowego wspiera C# (patrz Linux/OS X - Mono, Windows - natywnie) to nie ma nawet co wybierać między javą, a C# bo C# ma zaimplementowanych tyle sztuczek i optymalizacji, że java jest bardzo daleko w tyle zarówno pod względem syntaxu, wydajności oraz zużycia pamięci.

 

Przykładowo takie rzeczy jak operacje asynchroniczne to 1 słowo kluczowe, C# automatycznie tworzy i zarządza sobie thread poolem, podobnie w przypadku HttpClient masz connection poola, reuse socketów i tryliard innych sztuczek, o których nawet nie wiesz pisząc docelowy kod. W javie o ile da się zrealizować większość z tych rzeczy, to na pewno nie w mniejszej ilości linijek niż 200 - a w C# jest to jedna.

 

Tak, też byłem zwolennikiem javy, po czym usiadłem do jednego projektu (który na mnie wymusił C# z powodu biblioteki), i nigdy więcej już do javy nie wróciłem. Tu nawet nie ma argumentów, doszło do takiego paradoksu, że Mono wspiera C# na Linuxie lepiej niż openjdk javę.

 

Nie wiem, nadal sądzę, że co byś nie zrobił PHP się do tego absolutnie nie nadaje i degradacja będzie tylko postępować, nieważne czy odpalisz via CLI czy mod_php, to jest nadal wolna kobyła, która pracuje na 1 wątku, dla każdego połączenia otwiera socket, nie wspomaga się zoptymalizowanym natywnym kodem CPU, i używa interpretera. Tracisz od groma cykli procesora i zwiększasz sobie koszty - nadal obstawiam przy swoim, że można by to na 1 dedyku ustawić, a bottleneckiem powinna być rurka albo I/O, a nie CPU.

Edytowano Styczeń 31, 2016 przez Archi (zobacz historię edycji)

[Samael 0]

Z opisu wynika, że nie masz zoptymalizowanego kodu. Dodatkowo zastanowiłbym się czy czasem portale z których korzystasz nie mają limitów zapytań do ich serwów z jednego IP.

Kolejna rzecz to sql. Sprawdź czy wszystkie zapytania są poprawne, potrzebne i odpowiednio zoptymalizowane. Często daje się typową "*" przy selectie, jak pobiera się dużo rekordów ta gwiazdka naprawdę boli. Bywa że jednym zapytaniem sql i funkcją agregującą można zlikwidować problem kilku czasochłonnych pętli w php'ie.

Praser. Czego używasz do analizy kodu? Zwykłych wyrażeń regularnych? Zauważyłem że czasem lepiej pracuje DOMDocument a czasem owe wyrażenia, trzeba czasem poeksperymentować.

 

Portale z którymi współpracuję mają określone limity które przestrzegam.

SQL jest już dobrze napisany - kilkukrotnie sprawdzałem, przepisywałem i optymalizowałem zapytania, tak aby były możliwie lekkie.

W żadnym zapytaniu niema ani jednej gwiazdki. Wiem jak to wpływa na płynność ;-)

 

Nie pchaj się tak bardzo w sprzęt tylko zweryfikuj dokładnie linia po linii kod skryptu php, według mnie tam jest sporo problemów, które obciążają sprzęt. Tak jak Tobie napisałem, ja przez 3 lata optymalizacji skryptu uzyskałem taki efekt że z E5-2650v2, 128 gb ram przesiadłem się z aplikacją na e3-1240v2, 32 gb ram i jeszcze sporo zostało mocy Uważam, że warto jak najszybciej pracować na linuxie i tam odpalać swoją aplikację ale tylko w CLI. Więcej czasu poświęcisz na ogarnianie "klastra" niż na optymalizacje skryptu.

 

Dziś przepisałem kod dla jednego serwisu. Uruchomiłem go na maszynie na której piszę (Win7, Athlon 64 3000+, 4GB RAM) i: między 2 a 61% obciążenia CPU przez Apache oraz maksymalnie 100MB RAM'u. Uruchomiłem go na dwóch różnych przeglądarkach i Chrome wchłaniał prawie 200MB RAM'u i 30% CPU, z kolei na SlimBrowser ciągnęło 40MB i 15%. Wcześniej kod, sam kod, obciążał Apache'a na przedział 30 do 80% i 60MB RAM0

 

Zobacz sobie http://php.net/manual/en/features.commandline.usage.php i pogonisz to na jednym cpu

 

Już studiuję, ale obawiam się o pobieranie plików.

 

 

Ponadto, nad C# myślę aby się tym zainteresować, ale ilekroć próbowałem sił z C++, nie szło mi to, a domyślam się, że składnia jest podobna a dla mnie to jest jakaś blokada. PHP używam od zawsze, ale wiem, że czas na zmiany i dalszy rozwój - z resztą chciałbym "zrozumieć" aplikacje mobilne i zacząć je tworzyć.

[gutek 23]

Według mnie największym błędem jest odpalanie skryptu w przeglądarce / apche a nie w CLI. Zweryfikuj jeszcze skąd takie zajęcie pamięci w przeglądarce, być może zbyt wiele nie potrzebnych jest printów / echo itp, jeżeli to jest jakiś mechanizm to szkoda czasu i CPU na wywalanie informacji np. do przeglądarki, sprawdź co się dzieje ze zmiennymi, ich usuwaniem itp bo przy opisywanym przez Ciebie działaniu nie powinno być takiego zajęcia więc gdzieś jest czegoś zbyt wiele.

[Samael 0]

Wywołań printów lub echo jest cztery:

• Czas rozpoczęcia
• Dodanych informacji
• Czas zakończenia
• Różnica między czasem rozpoczęcia i zakończenia