Forum PHP.pl

Poczytaj o HTTP Long-Polling lub Websocket .

Witam,
zacząłem bawić się SSH w PHP zarówno przez netywne rozszerzenie jak i za pomocą phpseclib. W obu przypadkach wszystko działa mi dobrze, jestem w stanie zalogowac usera, wykonać komendę i pobrać output. Problem to niestety czas wykonania operacji. Praktycznie każda komenda SSH wykonuj się ~0.1 sek. Dodając do tego fakt, że samo zalogowanie się też jest komendą, to by zrobic cokolwiek potrzebuję wykonać co najmniej 2 komeny. To daje AŻ 0.2 sek. Szukałem trochę po stackoverflow tematy odnośnie wolnego SSH, powyłączałem niepotrzebne opcje w serwerze, ale w sumie nie widzę rożnicy wydajności. Serwer SSH jest na tym samym Hoście co wykonywany skrypt, więc opóxnienie związane z łączem nie powinno na to wpływać. Moje pytanie jest takie - czy SSH naprawdę tak wolno działa, czy u mnie jest coś nie tak? Co mogę zrobić?

Przypominam, zarówno serwer i client to localhost.

Z góry, dzięki za odpowiedzi.

Jak chcesz bronić ludzi przed podszywaniem się, to po prostu zaimplementuj mechanizm sesji, ustaw timeout na tę sesję i dodaj logowanie do czatu. WebSocket działa na serwerze HTTP, w momencie utworzenia socketa, leci request HTTP. Wymuś logowanie na typ etapie, by utworzenie połączenia było możliwe tylko z loginem i hasłem, po utworzeniu socketa ustaw timeout po jakim HTTP ma być zamknięte, co zamknie również WS.

Najlepiej zrób flood protection, czyli limit ile wiadomości może dany user posłać na czat w danym przedziale czasu, rozpoznając go np po IP.

Nie jestem profesjonalnym programistą JAVY, ale pracując z nią hobbystycznie i pobocznie w pracy, myślę, że mogę odpowiedzieć.

1. JAVA a bazy danych to dwie osobne rzeczy i najcześciej sprawa takich aplikacji wygląda podobnie jak w PHP - apka JAVAowa korzysta z API i konfiguracji osobno zainstalowanej bazy danych lub big data, by zapisywać i czytać dane. W przypadku aplikacji bardziej pod zastosowanai domowe niz serwerowe, czasem do instalatora dodawane są opcje typu "Posiadam bazę danych" i "Nie posiadam", po czym instalator odpowiednio reaguje. Aczkolwiek najczęściej baza stoi na serwerze.

2. Nie mam pojęcia, przynajmniej nie przy desktopowej apce.

3. IntelliJ jest teraz na topie , więc jak do PHP używasz PHPStorma, to powinieneś czuć się jak w domu.

4. Spring i Hibernate to podstawa.

Tak jak pisze Pyton_000 to czego szukasz to websocket - tutaj przykład https://github.com/kraken-php/demo-chat

Cześć,
istnieje w sieci gdzieś jakiś walidator dla protokołu HTTP 1.1? Chciałem popracować nad implentacją paru featurów z HTTP 1.1 w PHP, ale nie mam pojęcia gdzie mogę to porządnie zwalidować? Ktoś coś wie?

Hej,
czy ktoś na forum używał do czegokolwiek Patreona? Mam parę pytań odnośnie niego, ale nie znam nikogo takiego. Głównie chodzi mi o kwestie formalne i prawne.

PHP dlatego, że zbyt często w nowoczesnym webdevelopingu spotykam się z sytuacją, gdzie jest produkowana apka w PHP, do której potem dochodzą wymagania typu websocket, dystrybucji obliczeń, kolejkowania różnych tasków i często w takiej sytuacji ludzie od razu zaczynają automatycznie zaprzęgać node.js tylko do tej jednej funkcjonalności lub inne technologie co powoduje, że od razu rośnie niepotrzebnie poziom skomplikowania. Jestem zdania, że PHP nie powinien być traktowany jako gorszy język ("dlaczego PHP?"), bo posiada również wiele niewykorzystanych zalet - chociażby to, że wspomniany Kraken używajać PHP7.0 działa wydajniej niż wspomniany Node.js przy podobnych taskach. Jeśli deweloprzy pójdą w tym kierunku dalej rozwijająć aplikacje, moglibyśmy stworzyć własnego Node.php kiedyś. Nie mówię, że Node.js jest zły, oczywiście bo nie jest. Sam piszę głównie w PHP, w Node i w Go, ale nie lubię jak wszystko jest mieszane tylko dlatego, że w "bo tam to jest." Czy naprawdę, każdy projekt teraz musi być mieszanią PHP, Node, Pythona z Go/C++ w tle i obowiązkowo chociaż jednym serwisem JAVowym, by być "dobry"?

Duże projekty oferują wiele funkcjonalności i konfiguracji, więc to oczywiste, że poziom skomplikowania i złożoności jest i będzie duży. Akka.io to jeden ze wzorów który chciałem naśladować tworząc to oprogramowanie, co jest widoczne m.in. w systemie jak został stworzony cały nadzór aplikacji. Niestety nie da się wszystkiego przenieść 1-do-1, niektóre rozwiązania w PHP po prostu nie będą na tyle wydajne by był sens je implementować, więc trzeba to zrobić tak by było dobrze, a nie by było tak samo ale niewydajnie. Na sam koniec powiem, że jest to też szkielet aplikacji nie dla każdego, moim targetem były mniejsze i średnie projekty. Nie zamierzam tutaj konkurować z JAVĄ czy Akką, bo nie do tego zostało to stworzone. Ponadto, jeśli jesteś w stanie zaprząc tego typu duże enterprise'owe projekty i masz odpowiednie zasoby na to, to wybór technologii jest naprawdę duży, a złośliwiec może rzecz "po co JAVA czy Python? Tylko Erlang!"

Mogłem używać dwóch skali, albo z sekundowej z przedziału od 0 do 1, albo wielokrotności najmniejszej obsługiwanej jednostki czasu, tak jak piszesz od 1 do N. Tą najmniejszą jednostką w Krakenie to mikro a nie milisekunda, więc oczekując pół sekundy, trzeba byłoby pisać wartości rzędu 5e5, lu 500000, co zaczyna wyglądać zabójczo. Ponadto cały system bazuje na przesyłaniu wiadomości pomiędzy różnymi odizolowanymi od siebie kontenerami korzystajać z architektury opartej o wiadomości, i w takim przypadku fallbacki oczekujące kilku sekund są dopuszczalne. Innymi słowy, operowanie na sekundach jest tutaj bardziej intuicyjne. Ponadto, tę skalę wykorzystują również inne biblioteki oferujące asynchroniczność w PHP, zwłaszca React, do którego Kraken posiada odpowiednie adaptery. Lepiej używać już tego co zostało w jakimś tam stopniu przyjęte za standard niż zmieniać to na siłę, a potem przemnażać w adapterach każdą operację przez 1e6

Jeżeli pytasz o to , czy jest przykład związany z implementację czatu to tutaj https://github.com/kraken-php/demo-chat . Jeśli pytaz czy ta implementacja jest gdzieś uruchomiona i działająca online, to niestety w tej chwili nie. Przynajmniej nie publicznie. Aczkolwiek, rzeczywiście, można byłoby to uruchomić na zewnętrznym serwerze dla poglądu.

Witam wszystkich,
jest to pierwsze forum deweloperskie na jakim zarejestrowałem się kilka lat temu, nauczyłem się tu dużo rzeczy, trochę pomogłem innym i ogólnie traktuję to miejsce jako moje rodzinne forum, gdzie wszystko się zaczęło. Z tego też powodu, po 2 latach pracy, chciałem Wam w pierwszej kolejności przedstawić wyniki mojego projektu - Kraken Framework - szkielet do tworzenia wieloprocesowych, wielowątkowych aplikacji webowych z zastosowaniem architektury multiagentowej. Jest to pewnego rodzaju przed-premiera, bądźcie wyrozumiali

Projekt jest szkieletem aplikacji, umożliwiającym tworzenie bezpiecznych, rozproszonych i asynchronicznych aplikacji webowych w PHP. Jego główną rolę jest zapewnienie podstawowych funkcjonalności z tym związanych out-of-the-box, by nie trzeba było do każdego projektu obowiązkowo zaciągać node.js, gdy nagle okazuje się, że trzeba dodać np websockety. Wsparcie asynchroniczności i strumieni, zezwają na utrzymanie wysokiej wydajności i niskiego zużycia pamięci. Całość jest open source i wydane na licencji MIT.

Więcej o projekcie:
- Strona Główna - Official Kraken Website
- Github - Kraken Framework

Prosiłbym w tym temacie, byście wypowiadali się jedynie na temat samego projektu, wszystkie niedoskonałości strony WWW możecie zgłosić w osobnym temacie.

Prosiłbym także o wsparcie, jeśli uważacie, że technologia, którą wam prezentuję jest ciekawa i godna uwagi, proszę byście szepnęli o niej jakieś drobne słówko w swoich blogach czy innych serwisach, z których korzystacie. Jeżeli nie chcecie nic takiego robić, to chociaż nagrodźcie projekt Githubowym Star'em. Zainteresowanie projektem pozwoli mi go nadal, dynamicznie rozwijać, wiedząc, że na to co robię jest odpowiednio wysokie zapotrzebowanie

Z góry wszystkim dziękuję!

Dzięki wszystkim za pierwsze zgłoszenia, gdy zbierze się ich trochę więcej zrobię jeden większy push na serwer poprawiający zgłoszone przez Was problemy

@pyro Chociaż High Performant, nie jest błędnym sformułowaniem, o tyle zdaję sobie sprawę, że literówek jest za pewnie znacznie więcej niż opisałeś. Sam widzę nawet kilka. Cała strona będzie musiała jeszcze przejść przez audyt językowy.

@com Niestety kolorystyka serwisu to nie jest taka prosta sprawa. Na dwóch komputerach lenovo, które posiadam ten fiolet jest wręcz wyblakły, z którego przebija niebieski odcień. Na sprzęcie Apple - tj iPhone i iPad - kolory są dobrze wyważone, natomiast na monitorach Samsunga ten kolor jest rzeczywiście zbyt ciepły. Ciężko znaleźć dobry balans kolorystyczny.

@Spawnm Pierwsze załadowanie trwa długo głównie dlatego, że Twitter ładuje się synchronicznie. Nie powinno tak byc, mea culpa, ale nie miałem już czasu się tym zająć przed tą przed-premierą.

@viking Dzięki za zgłoszenie

Czekam na więcej

Witam wszystkich,
w osobnym temacie zamieściłem link do projektu open source, nad którym pracowałem przez ostatnie 2 lata. Wszystkie uwagi na temat projektu, proszę kierować do osobnego tematu, a tutaj pytam Was o ocenę samej strony WWW. Frontendu nie robiłem już hoho, więc za pewne znajdzie się wiele błędów

http://kraken-php.com

Zaleznie od potrzeb używasz albo WebSocket, albo HTTP Long-Polling. To pierwsze jest wydajniejsze, ale wymaga customowej logiki, bo nie jest zgodne z tym jak działa HTTP w 100%. Z tego co piszesz to long-polling będzie wystarczajace.

WebSocket to nie jest wynalazek node'owy. Jest to pewien standard. Websocketów możesz używać również w PHP, Pythonie, Ruby i zapewne wielu innych językach programowania.

Ratchet to implementacja WebSocketów w PHP, dzięki czemu nie potrzebujesz Node.js by ich używać. Ratchet jest wydajniejszy od implementacji node'owych, ale nie jest aż tak enterprise'owy jak np socket.io. A jak myślisz nad WS w PHP to oprócz ratcheta polecam jeszcze sprawdzić Kraken/Network

Nie, to nie są websockety. To jest long-polling z wykorzystaniem samego HTTP. Klikasz na budowę budynku, do serwera leci requet, serwer przelicza czas kiedy budowa się zaczęła, odsyła do przeglądarki ile ma ona czekać, przeglądarka uruchamia timer a po tym czasie odświeża automatycznie stronę. Nic wiecej tutaj nie potrzeba. A jak koniecznie chcesz się bawić websocketami to zamiast mieszkać PHP z Node.js użyj albo samego Node.js albo WebSocketów w PHP.

Poczytaj o long-pollingu.

Sabre ma bardzo prymitywną pętlę zdarzeń. Praktycznie każde inne rozwiązanie na rynku sprawdzi się lepiej niż ich.

Jak sprawdzisz rożnicę, to napisz tutaj na forum ile Ci się udało wycisnąć, bo sam będę ciekawy takich testów

@nospor Oczywiście, że można. Kraken jest trochę jak symfony pod tym względem - framework i repozytorium komponentów jednocześnie. Ponadto posiada on adaptery do Reacta, więc powinien byc kompatybilny z każdą asynchroniczną biblioteką, która działa na React.

cyt. "Kraken Framework is fully modular and each of its components can be used separately. If for some reason you don't want to download full application stack, you can require any of the [...] components"

Lista modułów dostępna jest w pliku README projektu na githubie, lub po prostu wchodząc na https://github.com/kraken-php .

@viking Ten wykres na stronie głównej Krakena przedstawia wydajność przy dostarczaniu strony HTML Hello World, czytanej z dysku z pliku hello.html. Jest to jedyne porównanie, które jestem w stanie wykonać w kwestii Kraken vs standardowe biblioteki PHP, ponieważ tylko ta funkcjonalność się pokrywa. W każdym przypadku testy przeprowadzane były z użyciem jednego procesu, za każdym razem plik czytany był z dysku bez cache, OPCache również było wyłączone. Więcej tego typu testów kontekście Reacta (który powinien mieć podobną lub trochę mniejszą wydajność) vs MVC można zobaczyć w projekcie PHP-PM.

Co do bazy danych to każdy zdemonizowany proces, nieważne czy to Kraken czy React czy Icicle zapewni Ci dużo lepszą wydajność, ponieważ możesz połączyć się z bazą raz zamiast każdorazowo przy każdym requeście. Ponadto możesz czytanie i zapisywanie do bazy zrobić również asynchronicznie, w kwestii niektórych danych, co jescze przyśpieszy całość. Problemem są tutaj ORMy - np Doctrine wycieka pamięć. W przypadku zdemonizowanych procesów w PHP polecam raczej wykorzystanie czystego PDO lub jakiegoś micro-ORM. Jeżeli bardzo potrzebujesz ORMów, to wtedy lepiej wydelegować połaćzenie z bazą do osobnego procesu, nasłuchiwać jego zużycie pamięci i restartować jak dojdzie do limitu, ale wtedy przyrosty wydajność w porównaniu do standardowego rozwiąania nie będzie aż tak widoczny.

@nospor Na pewno chcę konkurować z Reactem na poziomie komponentów, aczkolwiek w przeciwieństwie do Reacta, Kraken dodatkowo dostarcza cały Framework, w którym można zapisać aplikacę od stóp do głów, i nie trzeba się martwić, o to jak zaimplementować nadzorowanie procesów, komunikację między nimi itp. Z chęcią odpowiem na wszystkie pytania, bo to pomoże mi w priorytezacji tasków na przyszłość.

Tak, ale żeby opisać czy też odpowiedzieć potrzebuję konkretnego pytania ReactPHP to jest zbiór różnych asynchronicznych komponentów a nie jednolita technologia, i jedne działają lepiej, inne gorzej. Osobiście polecam zamianę komponentów Reacta na komponenty Krakena, gdyż dużo problemów jakie miał React udało mi się naprawić, a sam interfejs jest taki sam (+dodatkowe metody) lub bardzo zbliżony. Wiem, że to zalatuje na kilometr autoreklamą, no ale co poradzić, jeśli działają lepiej?

Reacta używałem w kilku projektach przy projektowaniu gier przeglądarkowych w PHP. React sam w sobie jest po prostu implementacją asynchronicznych obliczeń w PHP na pojedynczym wątku z wykorzystaniem programowania opartego o zdarzenia (event-driven development). Główna częścią tej technologii jest Evenement i Event-Loop. To pierwsze to jest implementacja klasycznego tandemu zdarzeniowego EventEmitter-EventListener w PHP, co pozwala na tworzenie loosely-coupled architecture, a drugie to kolejka zdarzeń. Cały React działa właśnie na bazie tego drugieg komponentu - pętli. Pętla w nieskończoność sprawdza czy istnieją do wykonania jakieś funkcje, timery oraz sprawdza czy są dane do zapisanai do strumieniu, a także czy do tych strumieni przyszły dane, które warto odczytać, a następnie je wykonuje.

Oprócz tych dwóch podstawowych modułów, wartym uwagi na pewno są jeszcze Promise, które jak nazwa wskazuje jest implementacją specyfikacji Promise/A+ w PHP, Promise-Timer który dodaje timeouty do nich oraz Stream implemetujący asynchroniczne strumienie.

Nie opłaca się korzystać z komponentów takich jak Socket, Http, Http-Client czy Datagram. Zamiast nich polecam wykorzystać bibliotekę Ratchet, która to wszystko ma lepiej zrobione i wciaż jest kompatybilne z Reactem. Ratchet to osobna biblioteka rozwijana przez tego samego autora co React.

Dużo komponentów obecnie też wymarło - chociażby Zmq - gdzie od ponad roku czekam na akceptację lub odrzucenie mojego pull requesta z fixami, co skończyło się z tym, że zaimplementowałem Zmq sam.

To teraz bardziej ogólnie. React jest stosunkowo prosty w użytkowaniu ze względu na to iż każdy webdeveloper miał styczność z programowanim opartym o zdarzenia w JS. Do tego jest bardzo wydajny, w PHP7 bijący nawet Node.js. Największe problemy Reacta to polegania na bibliotece Evenement, w której wycieka pamięć przy jednorazowych zdarzeniach i która już od dłuższego czasu nie jest rozwijana, a także fakt, że React nie posiada dobrego mechanizmu do rozpraszania obliczeń na wątki i procesy. Tak, istnieje child-process, ale to tylko potrafi spawnować nie-odizolowane procesy i korzystać z ich STDOUT i STDIN. I tutaj pojawia się pewna ironia - by w pełni wykorzystać Reacta, potrzeba używać wielu procesów, które React jako tako nie wspiera i całą ich logikę - wymiany informacji, łapania błędów, deployment i bootstrap programista musi sam zaimplementować. To dla mnie było największym problemem z pracą z Reactem. Sam React jest wydajny i w miarę stabilny, ale tak jak pisałem, wymaga dużo dodatkowego boilerplate'u.

Jak macie jakieś konkretne pytania , odpowiem na wszystkie.

EDIT:

Jeśli interesują was tego typu rozwiąznaia to oprócz React PHP i Kraken PHP istnieje jeszcze trzeci zestaw bibliotek asynchronicznych dla PHP - Icicle.io. Icicle jednak ma całkowicie inne podejście do asynchroniczności, oparte o trick z generatorami. Ich metoda sprawdza się lepiej w programowaniu współbieżnym*, ale jest trudniejsze do opanowania i ma poważne problemy z kompatybilnością z bibliotekami PHP, które nie bazują na generatorach.

* Mówiąc współbieżnie, mam na myśli parallel programming. Icicle świetnie sprawdza się do tego typu programowania, ale nie jest lepszy od Reacta w kontekście distributed i concurrent programmingu.

EDIT2 :

Dużo ciekawych informacji odnośnie Reacta zawarł na swoim blogu Wyrihaximus, który jest teraz jednym z najbardzije udzielających się contributorów Reacta.

Ja używałem dużo react PHP.

Chyba już nikt isę nie wypowie.

Myślałem o tym co mówisz Pyton_000, ale to by miało sens jakby się dało zautomatyzować takie przenoszenie po stronie githuba. Pisanie crawlera specjalnie po to używają Github API średnio mi się podoba, zwłaszcza, że sam pomysł kopiowania tasków między dwoma boardami wydaje mi się... no słaby. Chyba jednak zostawię numerację od 1. W każdym razie, dzięki za sugestię

Witam,
na Githubie pojawiła się niedawno bardzo fajna opcja zarządzania projektami (kanban board) z możliwością robienianie review, integracją z listą issues, etc. Bajka. (więcej informacji: https://github.com/blog/2256-a-whole-new-gi...s-and-features)

W każdym razie, z tego też powodu pojawił się w moim projekcie pomysł przejścia z JIRA kanban board właśnie w pełni na Githuba. Jedynym problemem jest tutaj numeracja issues'ów. Do tej pory w tym projekcie nie była wykorzystywana sekcja issues, więc w momencie dodania czegokolwiek, numeracja będzie szła od 1 w górę. Co prawda, można z tym żyć, zwłaszcza że i tak zmieni się formatowanie commit messages w takiej sytuacji, aczkolwiek wciąż dublowanie się numerów issuesów może być mylące. Stąd moje pytanie - czy da się na githubie, ręcznie ustawić numer, od którego ma numerować issues? Coś jak ustawianie w SQL początkowej wartości AUTO_INCREMENT ?

Jak dla mnie to co opisujesz brzmi jak typowe zastosowanie dla strategii.

Teoria: https://en.wikipedia.org/wiki/Strategy_pattern
Strona opisująca implementację tego wzorca: http://www.oodesign.com/strategy-pattern.html
Trochę prostsza wersja tego co powyżej w PHP: http://www.phptherightway.com/pages/Design-Patterns.html