Pan Kot

Ale nie do wszystkiego apache może mieć dostęp... Albo chmodujesz na 777 wszystko co tego wymaga (nie polecam), albo zmieniasz ownera całego /var/www (czy gdzie tam masz WP) na www-data.

A najlepiej będzie to chownąć jako www-data, chmody są niezbyt bezpieczne na dzisiejsze standardy.

Właśnie to miałem pisać. Jeśli mówimy o minecrafcie to bez ramdisku po prostu nie ma możliwości długo z tym pojechać, no chyba, że chcesz zmieniać dyski co parę miesięcy .

Skopiować plik na własny komputer i sprawdzić czy cokolwiek można z niego wydobyć np. 7-zipem. Przynajmniej ja bym tak zrobił.

Jeśli chodzi o serwery dedykowane to taniej niż w OVH nie znajdziesz i to Ci mówię z góry - nie licz na to. Możliwością jest jednak VPS, a jeśli jednak przebolejesz polskich providerów to chętnie zaproponuję Ci kilku moich faworytów. Zdecyduj tylko sam czy jest sens się przenosić i jakim kosztem. Jednak dedyk to dedyk. http://mintshost.pl/virtual.php http://www.slaskdata...dedykowane.html http://biznes-host.pl/?s=plany_vps2 Przypominam, że to są polskie firmy, a więc mają też datacenter ulokowane w Polsce. Jeśli chodzi o Francję to tylko i wyłącznie OVH => http://www.ovh.pl/se...ne/kimsufi.xml A jeśli o Niemcy to w grę wchodzi jak zawsze http://www.hetzner.d...r-produktmatrix Tyle typów ode mnie, być może ktoś zaproponuje coś więcej. Wszystkie wyżej wymienione firmy osobiście polecam.

Czy ja wiem? Nie jedna marka jest na rynku. http://biznes-host.pl/?s=dedykowane Razem z administracją, cena nie jest duża jeśli liczyć SLDC + Admina.

Ostatnio sprawdzałem przykładowy serwer gry - w tym wypadku DayZ, 40 osób na serwerze jest w stanie pociągnąć lekko od 2 TB wzwyż (miesięcznie), także ja bym uważał i z tym. Nie wiem ile minecraft ciągnie, "just sayin".

Przykładowa oferta wygląda tak: http://www.slaskdatacenter.pl/dedykowane.html Sam oceń, i nie zapomnij doliczyć pracy administratora (skoro piszesz, że z obsługą). Ja osobiście sądzę, że jest to za drogo przynajmniej o kilka stówek, ale różnie ludzie się cenią.

Zawsze możesz wziąć te 10 megabitów i wspomnieć moje słowa jeśli chcesz .

Jeżeli chodzi o hardware to powinno to dać radę. Zastosuje się parę tricków optymalizacyjnych i wszystko powinno ładnie współgrać. Jeśli chodzi o łącze to definitywnie nie. 100 megabitów to jest minimum jakie trzeba posiadać, do tego trzeba będzie się zainteresować chociażby vnstat'em, który da nam szczegółowe informacje jak to obciążenie wygląda. To nie jest coś, co można przewidzieć - chyba że sprecyzujesz konkretnie ile slotów na każdy serwer i ile serwerów na daną grę.

Nie widzę różnicy, co więcej. Bateria trzyma dłużej (jest większa), a procesor ma tylko te 200 Mhz mniej. No i może aparat trochę kuleje, ale tak naprawdę nie wiem czy poczujesz znaczną różnicę. Ja bym sobie dał spokój z wojną i brał tego Tipo, nie wygląda najgorzej, mi się nawet bardziej podoba ale to już kwestia gustu. No ale zawsze możesz walczyć o swoje, nikt Ci przecież nie zabroni .

Przede wszystkim zależy od tego gdzie masz domenę. Jedne firmy mają taką opcję, inne nie.

To jest cena "normalna" .

http://www.slaskdatacenter.pl/dedykowane.html Oferta 10 zł, oferta 19 zł. http://biznes-host.pl/?s=plany_vps2 #1 http://mintshost.pl/virtual.php VPS Mini / VPS Starter (Tu przypominam, że mintshost ma swoje serwery w serwerowni BH więc weź jedno bądź drugie jeśli zależy Ci na unikalnej lokalizacji) I jest jeszcze kilka.

OVH.

Nie zmienia to faktu, że worker_connections można sobie zwiększyć nawet 10x bez jakichkolwiek większych problemów .

Nie, po prostu sądziłem, że chodzi tu o optymalizację serwera WWW pod kątem WP, a nie doinstalowanie apc i plugina do WP. Można powiedzieć, że różne mieliśmy wizję na daną sytuację, oddaję punkty .

Zależy od oversellingu, bo czasem i 180% selera w selerze może być .

No jak chciałeś stawiać forum na WP to był to ogromny błąd. Rozważ PHPBB3, MyBB, SMF. Trzy moje osobiste faworyty z naciskiem na MyBB. Niektórzy sądzą, że jest ono pamięciożerne, ale z własnych testów wyszło mi, że jest najszybsze do mniej więcej 10 tys. zapytań na sekundę.

ab -c 1000 -n 10000 http://127.0.0.1/ Concurrency Level: 1000 Time taken for tests: 4.999 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Non-2xx responses: 10000 Total transferred: 3280000 bytes HTML transferred: 1620000 bytes Requests per second: 2000.35 [#/sec] (mean) Time per request: 499.912 [ms] (mean) Time per request: 0.500 [ms] (mean, across all concurrent requests) Transfer rate: 640.74 [Kbytes/sec] received Zrobiłem concurrency 1000, bo więcej po localhoście nie da rady. 10k skończonych żądań, 0 failed i oczywiście w trakcie testu mogłem bez problemu dostać się na stronę zewnętrznie ze swojego komputera. Jeśli kogoś to interesuje to testowanym skryptem był MyBB w wersji 1.6.9. Mam odpalać ten sam test z 9 innych serwerów, żeby udowodnić, że przy concurrency 10k również unix socket działa bardzo dobrze? Czemu na siłę sądzisz, że jedynie Twoja konfiguracja jest słuszna zamiast spytać choćby na priv o takie niuansiki? P.S. Skoro skrypt nie wyrabia docelowych 4x 1024 requestów (ledwo 2k dałem radę z MyBB wyciągnąć) to jakim cudem taka wartość jest za mała? To chyba lepiej dostać errora 503/504 niż katować użytkownika 20x wczytującą się stroną? Zresztą nawet w takim przypadku zdążyłbym ją zwiększyć. @Edit Odpaliłem ten test via 10 screenów z komendą ab, przykład jednego z nich: Failed requests: 0 Write errors: 0 Non-2xx responses: 20000 Total transferred: 6560000 bytes HTML transferred: 3240000 bytes Requests per second: 224.68 [#/sec] (mean) Jak mi nie wierzysz to daj znać na priv i sam zalejesz maszynę requestami .

Chyba jednak 4x 1024, a nie 1024/4 . Do tego chyba wyraźnie napisałem, że są to przykładowe ustawienia i rzeczy, na które trzeba zwrócić uwagę, a nie jedyna i słuszna konfiguracja. Równie dobrze możesz sobie to zwiększyć. Unix socket nie wyrabia? Ja nie spotkałem się z takim problemem, ale zaraz sprawdzę. Możesz być tego pewny. A jeśli masz jeszcze jakieś zażalenia to o nich napisz, człowiek uczy się całe życie. Do tego nie wiem jakim cudem konfiguracja @2 ma być lepsza od mojej, skoro tam jedynie są podane rewrite'y i ogólna konfiguracja + instalacja apc, a nie optymalizacja pod kątem WP.

Miejsca to i 100 mb wystarczy. Transferu? To zależy. Jeśli pod "startującą" to i kilkanaście GB miesięcznie, pewno nawet mniej. Musisz to na bieżąco kontrolować bo to zależy zarówno od userów, jak i od tego co hostujesz na stronie. Hosting? Każdy hosting w swojej ofercie ma WWW. Rozejrzyj się trochę, poczytaj opinie i podejmij wybór. Nie ma jedynego i słusznego .

Trochę tak, zaraz naprawię swój błąd . Chodziło mi o to: http://wordpress.org...wp-super-cache/ @fixed.

Przykro mi, ale za to dostajesz minusa. Nie o to autorowi chodziło. @Topic Przede wszystkim trzeba zacząć od właściwego dobrania nginxa i php. Z własnego doświadczenia powiem Ci, że php-fpm radzi sobie lepiej od wersji CGI, więc warto się tym bardziej zainteresować. Następnie przechodzimy do podstawowych rzeczy - ilość workerów zarówno nginxa jak i php-fpm powinno się ustawić (maksymalnie) na ilość threadów Twojego procesora. Czyli przykładowo gdy masz 2 rdzenie po 2 thready w każdym to wszystkich threadów (np. w htopie) wyświetla się 4 i właśnie 4 workerów powinieneś ustawić zarówno dla nginxa, jak i php-fpm. W przypadku php-fpm i modelu "dynamic" min childs na 2 i max childs na 4. Potem przechodzimy do samego połączenia nginx'a z php. Nie wiem czemu w wielu poradnikach autorzy proponują połączenie po TCP (127.0.0.1:9000), jest to strasznie słabe rozwiązanie jeśli mówimy tu o tej samej maszynie. O wiele lepszych rozwiązaniem jest użycie unixowego socketa. Całość operacji polega na zamianie: fastcgi_pass 127.0.0.1:9000 na: fastcgi_pass unix:/var/run/php5-fpm.sock; (Oczywiście przykładowo) Nie jest to jakiś potężny boost, ale jak mówimy o optymalizacji to trzeba o tym wspomnieć. Kolejnym krokiem jest użycie jakiegokolwiek skryptu cache'ującego do php. Aktualnie najpopularniejszymi jest APC, xcache oraz eAccelerator. Nie ma większej różnicy i działają bardzo podobnie, toteż wybierz ten, który Ci odpowiada. Ja polecam od siebie APC, ponieważ jest zapakowany już do repo debiana/ubuntu i można go łatwo zainstalować: apt-get install php-apc Teraz przechodzimy do części właściwej, czyli zaawansowanej optymalizacji. Zacząć należy od takich podstaw, jak np. # Basic config events { worker_connections 1024; multi_accept on; use epoll; } Jednak to powinno być defaultowe w większości konfiguracji. Przechodzimy do ciekawszej części: http { # Glowne ustawienia sendfile on; tcp_nopush on; tcp_nodelay on; # Podstawowa optymalizacja keepalive_timeout 10; client_body_timeout 60; client_header_timeout 60; send_timeout 60; types_hash_max_size 2048; Są to wartości przykładowe, ale najważniejsza część dotyczy keepalive. Keepalive potrafi być strasznie pamięciożerny i defaultowa wartość około 65 jest absolutnie niepotrzebna. Wartości 10-20 są o wiele lepsze. Reszta to głównie zabezpieczenia przed loopowaniem, a także wolnymi botami, które mogłyby zaatakować nasz serwer chociażby slowlorisem. Przechodzimy do serca optymalizacji nginxa: # Zaawansowana optymalizacja open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; # Kompresja Gzip'em gzip on; gzip_disable "msie6"; gzip_vary on; gzip_proxied any; gzip_comp_level 4; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; #gzip_static on; Dzięki cache'owaniu przez nginxa plików obniżamy I/O dysku, a także requesty, przez co strony działają o wiele szybciej, a nginx nie musi wykonywać zapytania do tego samego pliku. Kompresja gzip dodatkowo pomaga w oszczędzaniu łącza, a co za tym idzie przyspiesza ładowanie się stron. Waznym elementem tutaj jest gzip_comp_level - jeśli Twój procesor głównie idluje możesz ustawić wartośc 4-5 (wyższe są już nieopłacalne ale oczywiście możesz poeksperymentować, max to 9), natomiast jeśli jest głównie używany to kompresja rzędu 0-1 będzie właściwa. Tu się kończy najważniejsza część odnośnie nginxa. Reszta jest OS-specific bądź CMS-specific. Do Wordpress'a jest milion wtyczek np. SuperCache (z tego co kojarzę), nie znam go bliżej więc musisz potestować. A co do OS-Specific to fajną opcją jest stworzenie małego RamDisk'u (do 128 mb), skopiowanie na niego plików z HDD i ustawienie vhosta właśnie na ramdisk. Przyspiesza to głównie czas dostępu do plików, a ten jest bardzo ważny (nawet pomimo cache'a nginxa). Musisz jednak pamiętać, że ram po reboocie magicznie zniknie więc w tym wypadku masz dwie opcje - CRON co x minut (polecam 24h), w którym serwer zrzuci dane z ramdisku na HDD bądź w drugą stronę - CRON, który co x minut nadpisze Ramdisk danymi z HDD. Jeśli zamierzasz się bawić z systemem plików to wybierz 1szy sposób, ponieważ nginx defaultowo będzie zapisywał do ramdisku. Tyle krótkiego poradniczka, mam nadzieję że pomogłem.

No jak najbardziej jeśli mniejsza rzecz postępem technologicznym jest do przodu to może tak być . Ale mam tu na myśli chociażby karty graficzne typu GTX 560 i GTX 560M.