Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Oprogramowanie / Software → Alternatywa dla raspberry pi jako web serwer z php
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
Witam
Co byście polecili za router z usb którego zadaniem by miało być hostowanie plików na ftp z pendrive'a / karty
Musi umieć też obsługiwać php'a.
Zastanawiam się nad raspberry pi. Jego koszt z obudową oscyluje coś w granicach 200zł a ma dużo ramu.
A ilu użytkowników jednocześnie ma obsłużyć serwer z PHP? Jeżeli to ma być kilku użytkowników, to RPi będzie OK. Nie wiem czy znajdziesz tańszą alternatywę. No i oczywiście lepiej odpuść sobie Apache'a i postaw Nginx'a lub Lighttpd.
Kilkunastu to w porywach 
Raspberry Pi jak znalazł - o tańszą platformę do takiego prostego zadania naprawdę ciężko, jeżeli ma to być łatwe w konfiguracji i szybkie w uruchomieniu.
Kwestia tylko, czy chcesz to mieć na kablu (wtedy rev. B) czy po Wi-Fi (wtedy tańsza rev. A + karta Wi-Fi na USB, a udostępniasz dane z SD).
http://www.dobreprogramy.pl/Nie-tylko-R … 38832.html
http://www.dobreprogramy.pl/Raspberry-P … 40806.html
Tylko nie wiem czy nada sie do tego co mowisz.
W obu przypadkach cena minimum 2x wyższa.
Nie upieram sie przy tym, to tylko przyklady. W komentarzach powyzszych artykulow sa tez inne propozycje. Musi po prostu poszukac.
http://forum.r-pi.pl/viewtopic.php?t=14 … p;p=162350
Ja też się nie upieram, ale pod względem ceny naprawdę nie ma alternatywy. Tym bardziej jeśli pod uwagę weźmie się dostępne wsparcie i czas poświęcony na uruchomienie takiego rozwiązania.
A to? http://allegro.pl/marsboard-a10-dev-boa … 314753.htm
Cena wyzsza, ale wydaje sie to byc dosc fajne.
A wiesz jak wygląda wsparcie u Chińczyków? Dzisiaj jest, jutro go nie ma 
Za maliną stoi fundacja i ogromna społeczność, a to jest bezcenne.
Posiadam Raspberry Pi od ponad pół roku. Mam na nim wiele usług, np. WWW (Apache z PHP, nginx), MariaDB (dawniej MySQL), SMB, FTP (vsftpd), SVN, Jabber, SSH, fail2ban, dnsmasq. Generalnie daje radę. Najwęższym gardłem jest karta SD, dlatego bazę danych trzymam w RAM-ie (inaczej przymula). Jeżeli chciałbyś hostować na poważnie jakieś pliki, np. multimedia, to polecam dysk zewnętrzny. Karta SD nadaje się do postawienia na niej systemu, trzymania na niej plików HTML/PHP, ale przy większych plikach poczujesz opór. Wydajność procesora jest w miarę. O ile forum fluxBB (fork PunBB, na którym oparte jest to forum) śmiga bardzo ładnie, tak samo WordPress z cache'em stron (WP Super Cache), to taki ownCloud już muli. Oczywiście włączony OPCache w PHP. Load average zwykle < 0,3.
Jeżeli chcesz podłączyć pendrive'a, to konieczny będzie porządny zasilacz, min. 1,5A jak na moje; dla bezpieczeństwa dałbym 2A.
No i oczywiście lepiej odpuść sobie Apache'a i postaw Nginx'a lub Lighttpd.
Jeżeli kolega chce używać PHP, to nietrafiona rada. nginx jest lepszy w hostowaniu statycznych plików, natomiast w benchmarkach PHP wygrywa Apache. Najlepszym rozwiązaniem jest połączenie tych dwóch serwerów, jeżeli to możliwe, czyli postawić witrynę w PHP na Apache, a linki do plików statycznych (obrazki, JS, CSS) dać na inny port, na którym będzie stał nginx.
Jeżeli kolega chce używać PHP, to nietrafiona rada. nginx jest lepszy w hostowaniu statycznych plików, natomiast w benchmarkach PHP wygrywa Apache. Najlepszym rozwiązaniem jest połączenie tych dwóch serwerów, jeżeli to możliwe, czyli postawić witrynę w PHP na Apache, a linki do plików statycznych (obrazki, JS, CSS) dać na inny port, na którym będzie stał nginx.
Zupełnie się z tym nie zgadzam i nie lubię jak ktoś strzela twierdzeniem ("w benchmarkach PHP wygrywa Apache") bez podawania konkretnych źródeł, bo na każdy taki argument można znaleźć drugi, który pokazuje, że jest zupełnie odwrotnie (powiedzmy, że nie korzystamy z mod_php w Apache i już sprawa się całkiem odwraca). Poza tym, nie ma czegoś takiego jak "sprawiedliwy" i jednoznaczny test dwóch zupełnie różnych aplikacji, w dodatku serwerów, bo zawsze dochodzi do porównania w konkretnym otoczeniu sprzętowo-programowym i w jakiejś konkretnej konfiguracji, która dla obu jest zupełnie inna i w praktyce niemożliwa do przeniesienia z jednej aplikacji do drugiej.
W sieci można znaleźć od groma testów i informacji w temacie, w których m.in. porównywane są różne serwery, w różnych konfiguracjach, z różnymi dodatkowymi "przyspieszaczami" (coś "na ząb" na dobry początek: http://drupal.stackexchange.com/questio … -out-there, http://www.wikivs.com/wiki/Apache_vs_nginx).
Stosowanie na jednej maszynie, w dodatku takiej klasy jak RPi, przy omawianym w wątku problemie, dwóch instancji dwóch różnych serwerów, tylko po to żeby jeden serwował statyczny content, bo jest teoretycznie w tym szybszy, to moim zdaniem jakieś nieporozumienie - to nie ta skala problemu.
Co więcej, akurat wydajność serwera i tak w ostatecznym rozrachunku, przy serwowaniu stron dynamicznych, ma raczej niewielki wpływ na końcową wydajność całej aplikacji. To interpreter PHP jest, do pary z bazą, najbardziej zasobożerny i jak już ktoś naprawdę wie jak używać PHP, to korzysta z akceleratorów itp. i potrafi tak całość skonfigurować, że będzie działać tak samo wydajnie, niezależnie od typu zastosowanego serwera.
Zasugerowałem rezygnację z Apache, bo jest to zasobożerny kombajn z milionem opcji, możliwości i setką opcji konfiguracyjnych, z których w ostateczności wykorzystuje się najczęściej... kilka. Moim zdaniem, przy określonych przez autora wątku wymaganiach (kilkanaście jednoczesnych połączeń to chyba nawet nie jest "wymaganie") nie ma po prostu sensu stosowania Apache'a, a zaoszczędzone zasoby można "podarować" innym uruchomionym procesom/zadaniom.
Podsumowując, dobierajmy odpowiednie narzędzia do skali i typu problemu.
Zupełnie się z tym nie zgadzam i nie lubię jak ktoś strzela twierdzeniem ("w benchmarkach PHP wygrywa Apache") bez podawania konkretnych źródeł, bo na każdy taki argument można znaleźć drugi, który pokazuje, że jest zupełnie odwrotnie (powiedzmy, że nie korzystamy z mod_php w Apache i już sprawa się całkiem odwraca).
Niestety, nie pamiętam już, co to były za testy. Wiem, że jak z pół roku temu interesowałem się tematem, to generalnie trafiałem na takie, gdzie przeważał Apache (oczywiście, że z mod_php - czemu ktoś miałby go nie używać, skoro jest zoptymalizowany dla Apache'a?). Jednak muszę przyznać, że jak teraz zajrzałem do sieci, to znalazłem sporo takich z przewagą dla nginx.
Stosowanie na jednej maszynie, w dodatku takiej klasy jak RPi, przy omawianym w wątku problemie, dwóch instancji dwóch różnych serwerów, tylko po to żeby jeden serwował statyczny content, bo jest teoretycznie w tym szybszy, to moim zdaniem jakieś nieporozumienie - to nie ta skala problemu.
Zgodzę się, że jest to przekombinowane pod względem administracyjnym, niewarte zachodu w takiej konfiguracji. Jednakże ja u siebie tak to mam skonfigurowane, działa, dlatego proponuję. Na pewno problemem nie jest działanie dwóch serwerów jednocześnie na malince. Kiedy nie ma żądań, procesy Apache i nginx są uśpione, więc nie konkurują. A jeśli chodzi o RAM: przy wszystkich tych wymienionych wcześniej przeze mnie uruchomionych usługach, w tym trzymaniu kilkudziesięcio-MB bazy w ramdysku, nie zużywam nawet połowy (patrzymy na buffers/cache):
total used free shared buffers cached
Mem: 462 376 85 0 30 183
-/+ buffers/cache: 162 299Co więcej, akurat wydajność serwera i tak w ostatecznym rozrachunku, przy serwowaniu stron dynamicznych, ma raczej niewielki wpływ na końcową wydajność całej aplikacji. To interpreter PHP jest, do pary z bazą, najbardziej zasobożerny i jak już ktoś naprawdę wie jak używać PHP, to korzysta z akceleratorów itp. i potrafi tak całość skonfigurować, że będzie działać tak samo wydajnie, niezależnie od typu zastosowanego serwera.
Z ciekawości uruchomiłem ownCloud na nginx, bo z nim mam największe problemy. Mierzyłem w przeglądarce czasy ładowania, raz na nginx, raz na Apache. Konfiguracja PHP ta sama. Różnice w czasach były rzędu maks. 10-20%, ale nie na korzyść konkretnego serwera. Nie było reguły: raz był szybszy ten, raz - tamten. Proszę nie uważać tego za obiektywny test, bo wiadomo, obciążenie w systemie przez inne usługi nie jest stałe. Pokazuje to tylko, że Apache nie jest na tyle gorszy wydajnościowo, żeby z niego rezygnować.
Zasugerowałem rezygnację z Apache, bo jest to zasobożerny kombajn z milionem opcji, możliwości i setką opcji konfiguracyjnych, z których w ostateczności wykorzystuje się najczęściej... kilka. Moim zdaniem, przy określonych przez autora wątku wymaganiach (kilkanaście jednoczesnych połączeń to chyba nawet nie jest "wymaganie") nie ma po prostu sensu stosowania Apache'a, a zaoszczędzone zasoby można "podarować" innym uruchomionym procesom/zadaniom.
Dla mnie pewna funkcjonalność Apache jest kluczowa, dlatego z niej nie zrezygnuję, np. mod_rewrite. Żeby dla powyższego testu uruchomic ownCloud na nginx musiałem grzebać w pliku konfiguracyjnym serwera, tam ustalać rewrite'y, gdy tymczasem stawiając coś pod Apache nie musisz robić nic, bo praktycznie każda aplikacja internetowa jest dziś do niego przystosowana, a wręcz rzekłbym śmielej: wiele z nich nie jest przystosowanych do innych serwerów niż Apache, głównie ze względu na mod_rewrite.
Co do zasobów, odniosłem się wyżej. Co z tego, że Apache zużywa znacznie więcej pamięci operacyjnej, jeżeli jest jej pod dostatkiem?
Niestety, nie pamiętam już, co to były za testy. Wiem, że jak z pół roku temu interesowałem się tematem, to generalnie trafiałem na takie, gdzie przeważał Apache (oczywiście, że z mod_php - czemu ktoś miałby go nie używać, skoro jest zoptymalizowany dla Apache'a?). Jednak muszę przyznać, że jak teraz zajrzałem do sieci, to znalazłem sporo takich z przewagą dla nginx.
mod_php to tak naprawdę interpreter PHP w postaci modułu do Apache. Bez problemu jestem w stanie podać przykłady, w których się z tego modułu nie korzysta (zamiast tego stosując FCGID albo FPM) - np. ze względu na możliwość uruchamiania różnych wersji PHP na tym samym serwerze (np. hostujesz głupkowatą aplikację, która działa tylko w jakiejś starej wersji PHP), kontrolować wykorzystywane zasoby, uprawnienia z jakimi mają być wykonywane skrypty PHP lub korzystania z kilku serwerów jednocześnie (mod_php jest przecież tylko dla Apache'a). Co więcej, dla niektórych niedopuszczalna jest możliwość, aby jedna z aplikacji uruchomiona na serwerze mogła ubić cały serwer i tym samym wyłożyć pozostałe serwisy... A przecież to wcale nie są takie niespotykana zdarzenia Tak czy inaczej, wydaje mi się też, że mod_php wcale nie jest najwydajniejszym rozwiązaniem z możliwych, ale na pewno najłatwiej to uruchomić i skonfigurować... ba, praktycznie tego się nie konfiguruje.
Testy testami, a rzeczywistość wygląda różnie - wedle potrzeb i upodobań.
Co do zasobów, odniosłem się wyżej. Co z tego, że Apache zużywa znacznie więcej pamięci operacyjnej, jeżeli jest jej pod dostatkiem?
To już zależy od konkretnej konfiguracji i potrzeb, ale ja tam bardziej lubię rozwiązania, które są "szyte na miarę" i nie zżerają więcej zasobów niż to naprawdę potrzebne.
Poza tym, Raspberry Pi występuje również w wersji z 256 MB RAM (model A lub pierwsze rewizje modelu B), a w takim wydaniu może już zacząć brakować pamięci, szczególnie jeżeli ktoś potrzebuje przeznaczyć dla GPU trochę więcej pamięci niż domyślne 64 MB.
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
eko.one.pl → Oprogramowanie / Software → Alternatywa dla raspberry pi jako web serwer z php
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc