Sunnydev

lol, na praktykach w technikum też byłem "adminem" :P akurat w pierwszy dzień, w którym dali mi słuchawkę zostałem opieprzony o to, że nie ma jakiegoś widoku na stronie (nie wiedziałem o co nawet chodzi). Hmm okej, przekazuje to swojemu opiekunowi po czym wziął ode mnie słuchawkę i zaczęli się kłócić (serwer stał, było dobrze, a ziomek pomylił adresy XD) jak na siebie ku*ami rzucali to się aż zjeżyłem haha. lenistwo typa level awesome.

axde

@Satanistyczny Awatar: Takich kwiatków jest wszędzie pełno im dłużej w tym siedzę. I jedynym rozwiązaniem jakie zewsząd słyszę jest "dokupmy mocy".

AMD64

@Satanistyczny Awatar: A jak to jest zrobione, że taki serwer Heroku na Debianie posiada 10 wersji PHP, czy wszystko jest kompilowane? Przecież Debian nie ma wszystkich pakietów PHP, po jakimś czasie stabilna wersja przechodzi na nowsze, a starsze porzuca.

czysteskarpety

Też najlepiej robić bez kontaktu z klientem, ew. sporadycznie przy własnych projektach.

somedev

To tylko opinie. Trzeba było zmierzyć zasoby na jednym serwerze na drugim jakie zużywa strona, porównać ze wymaganiami i zasobami hostingu. Inaczej to zwykle bicie piany.

Satanistyczny Awatar

Dokładnie - jak dotąd nikt takich pomiarów nie przedstawił.

TomRZ

Ta.. a kiedy ja czasem zwracam uwagę na to, żeby nie używać kobylastych frameworków do PHP składających się z kilkudziesięciu tysięcy plików, to mnie często wyśmiewają, że to nie problem przy współczesnych dyskach SSD / procesorach ehhh... walka z wiatrakami

czysteskarpety

@TomRZ: Z plikami to nie problem (poza ciężkim backupem, co może mieć znaczenie, bo zajmuje miejsce i czas jak kopiujesz itp.), bardziej requestami, które obciążają serwer.

TomRZ

@czysteskarpety: piszę w kontekście shared hostingu, wtedy z plikami i I/O też zaczyna się problem, kiedy masz na jednym serwerze 200 klientów a każdy korzysta z Symfony albo Laravela, masakra. Teraz porównaj to z Phalconem lub czymś podobnym, co jest współdzielone przez wszystkich klientów. Różnica jest znaczna.

czysteskarpety

@TomRZ: nie no na współdzielonym to tylko mniejsze projekty, chociaż teraz Symfo odchudzili, a zamiast Larwy to Lumen i da się żyć (gorzej z instalką tego, upgradem, composerem, uprawnieniami), a droższego shareda nie ma sensu za bardzo brać jak VPS jest od 120zł/rok

TomRZ

@czysteskarpety: nie wiem jak dokładnie wygląda rynek, ale raz że ludzie często chyba wolą shareda bo nie ma problemu z zarządzaniem, a dwa sharedy często kuszą rożnymi pakietami/frameworkami które można automatycznie zainstalować. Wszystko hula dopóki te strony mają mały ruch, ale wystaczy że zacznie się coś dziać i są przestoje / zamuły.

TomRZ

@czysteskarpety: aha i VPS tez taki fajny nie jest bo o ile procesor sie fajnie dzieli, to już I/O nie podzielisz. Kilka VPSów na jednym fizycznym potrafi się między sobą ostro " żreć" o I/O

Tenonymous

Tak bardzo prawda. Zresztą to jeden z powodów dla których porzuciłem adminkę. Szkoda się kopać z idiotami.

WeiXiao

po co brać shareda gdy vpsy tanie?

mr_jaro

zadam jedno, pytanie... wycieki pamięci w php?

mr_jaro

a pożeranie kilku procesów to nic szczególnego, wystarczy dodać uprawnienia do zdjęć i już lecą ;)

TomRZ

@mr_jaro: wycieki pamięci to nie problem, raz że są małe, a dwa, zawsze się ustawia, że np. po x obsłuzonych requestach (np. 5 tysięcy) proces ma się restartować (restart jest bardzo szybki, niezauważalny, i niczego nie psuje). W ten sposób wycieki pamięci są eliminowane. Zobaczyć: https://php-fpm.org/

mr_jaro

@TomRZ: to nie jest problem bo jeszcze nigdy w życiu nie miałem wycieków w php, jak mi się zdarzą kiedyś to będę o tym myślał :D

TomRZ

@mr_jaro: wycieki są powodowane przez standardowe biblioteki PHP lub dodatkowe, dlatego php-fpm ma standardowo ustawioną pewną ilość requestów po których procesy się restartują. Ustaw, żeby proces się nie restartował to zobaczysz jak proces będzie z biegiem czasu puchnął. Jezeli nie używasz php-fpm tylko jakiegoś workera pod apachem, to tam tak samo się robi, workery są co pewien czas restartowane.

mr_jaro

@TomRZ: widzisz, php jest tak dobrze skonfigurowane defaultowo że nigdy takich problemów nie miałem i pewnie mało kto miał ;)

TomRZ

@mr_jaro: ta, tylko nie ma żadnego restartu w trybie CLI, spróbuj uruchomić proces który będzie coś mielił np. przez kilkanaście godzin, może się okazać, że zabraknie pamięci, mimo kodu PHP który teoretycznie nie powinien tego powodować.

somedev

Standardowe biblioteki powodują leaki i obchodzi się to restartami zamiast postawić code guatda i usunąć ? No to jeszcze bardziej dziwie się jak na tym stoi pół internetu.

WeiXiao

jak działają te restarty, że nie gubią się requesty?

TomRZ

@WeiXiao: php-fpm albo worker odpala nie jeden proces ale pulę procesów, każdy proces ma swoj osobny licznik requestów, kiedy jeden się restartuje reszt nadal obsługuje. Poza tym tak jak pisałem, restart jest błyskawiczny, rzędu kilku milisekund. PHP-FPM to bardzo wydajny manager procesów, życzyłbym np. serwerom Javowym/Servletowym takiego tempa w (re)starcie.

TomRZ

@somedev: tzn może trochę przesadziłem, te standardowe raczej bardzo mało mają wycieków lub w ogóle, gorzej z jakimiś bibliotekami dll/so które ktoś sobie zrobił i dołączył do PHP-a, tzw. "third party". One najczęsciej robią leaki, i dlatego głównie jest taki mechanizm restartów - tak trochę na wyrost. Inna sprawa to niesamowity hejt na PHP który co poniektórzy wykazują. Teraz wyobraźcie sobie że macie coś napisane w pythonie albo javie i tam jest jakiś niewielki, ale jednak leak, a mechanizmu restartu serwer nie ma. Co się wtedy dzieje.... wiadomo co. Klient narzeka że system coś wolno działa, musi przyjść admin i zrestartować serwer.

somedev

@TomRZ: u paru klientów miałem taka sytuacje. Kilka razy z mojej winy kilka w innym kodzie -nieważne. Wtedy robi się dobre logi, w miejscach szczególnie podejrzanych, młody dumpuje pamięć serwera jak usługa napuchnie i ręcznie restartuje u klienta. Jak po a analizie ntego dumpa wiadomo ocb i można odtworzyć sytuacje to to latamy a w tym czasie automat przejmuje obowiązek resetowania usługi. Rozumiem ze to ważny mechanizm ale obejście zanim wyśledzi się błąd a Ty piszesz jakby to było docelowe rozwiązanie.

TomRZ

@somedev: żeby było jasne ja nie chce hejtować żadnego języka, wskazuje tylko na dobre strony takiego rozwiązania w PHP, które w pełni automatycznie, wydajnie, i transparentnie rozwiązuje ten problem, zamiast obarczać nim administratora.

somedev

Spoko - ja też wyrosłem z hejtowania czegokolwiek co pozwala realizować projekty i zarabiać na tym. Przy czym będę się upierał ze php daje awaryjna możliwość obejścia problemu anie jego rozwiązanie. Jak tam to zostawisz go po n-latach jednak się wysypie bo zazwyczaj 5000requestow wchodziło a teraz przy 4900 skończyła się pamięć lub coś ze sterty zostało pomazane i bum. Jednak wycieki to bym śledził ;)

WeiXiao

aplikacja pada, to wstaje nowy kontener i lecimy dalej :P

mr_jaro

@TomRZ ostatnio napisałem taki, który mielił ok. 40h i obyło się bez problemów, jak mowię jeszcze mi się to nigdy nie zdarzyło.

somedev

@WeiXiao: nie bądź ignorantem. Jeśli to ewidentnie problem aplikacji należy to śledzić. Jeśli robiąc eksperymenty z wersja awk lub openssl rozwaliłem pakiety to reset contenera jest najlepsza opcja. Tak samo jak w przypadku zapewnienia działania proda w czasie jak siedzimy problem.

TomRZ

@somedev: raczej nie, to są wycieki rzędu kilku bajtów na request, restart po 5k requestów to konserwatywne ustawienie. Zresztą jak pisał wyżej mr_jaro on problemu nigdy nie mial z tym, ja w sumie też nigdy, więc raczej powtarzam zachowawczo coś o czym słyszałem. Największy problem, z tego co czytałem, zawsze był z jakimiś dziwnymi, rzadko używanymi dodatkowymi blbliotekami które sobie ktoś dokompilował do PHP. Nad PHP pracuje zbyt duży zespól ludzi, zbyt wielu ludzi na Świecie to już używa, żeby byly jakieś bardzo poważne kwiatki.

somedev

Spoko dzięki za info i opinie. Ja pisałem o wycieku grubych gigabajtów ale to soft dedykowany i tylko garstka osób tego używała.