пропозиції роботи
Wypowiedzi
-
Za miesiac kolejny harpagan. Plan jest taki, przepisac skrypty w ten sposob, by odswierzaly sie wtedy kiedy trzeba a nie statycznie co jednostke czasu.
Czyli skrypcik sprawdza np co 5 sekund czy cos sie zmienilo, jak sie zmienilo to przeladowuje, jak sie nie zmienilo to nic nie robi.
zobaczymy :) -
Jestemy w trakcie realcji H Live.
I przycina, load bardzo neistabilny, mrtg mowi ze procki zabijaja sie, ale w htop nie widac nic co moglo by je zabijac. Pojwily sie spore niescislosci.
Co jakis czas wymieka apache, trzeba do restartwoac i odrazu rusza ostro z buta, po jakims czasie znowu muli. -
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Rowerowe Trójmiasto
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Rowerowe Trójmiasto
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Rowerowe Trójmiasto
-
Po wprowadzeniu tej linijki:
Benchmarking http://rwm.org.pl (be patient)
Finished 285 requests
Server Software: Apache
Server Hostname: http://rwm.org.pl
Server Port: 80
Document Path: /
Document Length: 17034 bytes
Concurrency Level: 10
Time taken for tests: 30.010 seconds
Complete requests: 285
Failed requests: 20
(Connect: 0, Receive: 0, Length: 20, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 4929054 bytes
HTML transferred: 4854669 bytes
Requests per second: 9.50 [#/sec] (mean)
Time per request: 1052.982 [ms] (mean)
Time per request: 105.298 [ms] (mean, across all concurrent requests)
Transfer rate: 160.40 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.4 0 3
Processing: 460 1036 169.0 1034 1652
Waiting: 460 1036 169.5 1033 1652
Total: 460 1036 169.0 1034 1652
Percentage of the requests served within a certain time (ms)
50% 1033
66% 1091
75% 1118
80% 1162
90% 1234
95% 1303
98% 1416
99% 1591
100% 1652 (longest request)
konkluzje:
ten sam czas, czyli 30 sek
przed wprowadzeniem tej linijki bylo:
----------------------------------------
przed:
Benchmarking rwm.org.pl (be patient)
Finished 59 requests
po:
Benchmarking http://rwm.org.pl (be patient)
Finished 285 requests
----------------------------------------
przed:
Complete requests: 59
Failed requests: 51
po:
Complete requests: 285
Failed requests: 20
--------------------------------------
przed:
100% 5439 (longest request)
po:
100% 1652 (longest request) -
Mariusz Gronczewski:
Michal Mizera:
Zdychają pomału bo serwer wykorzystuje je ponownie jak przyjdzie nowe żądanie, czyli zamiast startować nowy wykorzystuje już instniejący.
Co moga robic te procesy po tym jak test sie zakoczyl, i czemu zdychaja pomalu przez 20 minut a nie gina odrazu ?
Mógłbyś wkleić config fastcgi jakiego używasz ?
<IfModule mod_fcgid.c>
AddHandler fcgid-script .php .php5
IPCConnectTimeout 20
DirectoryIndex index.php
</IfModule>
to chyba tylko tyle tego. -
i sesje udalo sie naprostwac.
Zrobilismy kolejny strestest, dociazylismy sie na 3 minuty i zakonczylismy test. Jednak 5 minut po zakonczeniu testu top wciaz pokazuje mase procesow obciazajacych:
12430 vu10002 20 0 130m 8600 3456 R 19 0.2 0:01.99 php-cgi
12471 vu10002 20 0 130m 8716 3316 R 18 0.2 0:00.66 php-cgi
10796 vu10002 20 0 130m 9.9m 4688 R 17 0.3 0:12.75 php-cgi
12310 vu10002 20 0 130m 9916 4500 R 17 0.2 0:02.07 php-cgi
12204 vu10002 20 0 130m 8688 3460 R 17 0.2 0:06.22 php-cgi
12335 vu10002 20 0 130m 9152 3952 R 17 0.2 0:02.10 php-cgi
12397 vu10002 20 0 130m 9.9m 4656 R 17 0.2 0:02.70 php-cgi
12327 vu10002 20 0 194m 9.9m 4640 R 16 0.2 0:03.66 php-cgi
4340 mysql 20 0 1021m 197m 5188 S 16 5.0 3:38.05 mysqld
12133 vu10002 20 0 130m 10m 4824 R 16 0.3 0:03.58 php-cgi
12360 vu10002 20 0 194m 8856 3480 R 16 0.2 0:02.09 php-cgi
12054 vu10002 20 0 138m 31m 16m R 16 0.8 0:05.97 php-cgi
12221 vu10002 20 0 128m 8660 3504 R 15 0.2 0:05.74 php-cgi
12417 vu10002 20 0 128m 8828 3472 R 15 0.2 0:01.43 php-cgi
11471 vu10002 20 0 193m 8228 3556 S 15 0.2 0:07.90 php-cgi
12412 vu10002 20 0 129m 8432 3232 S 15 0.2 0:01.42 php-cgi
12201 vu10002 20 0 193m 8468 3544 S 14 0.2 0:05.69 php-cgi
12454 vu10002 20 0 130m 8364 3264 R 12 0.2 0:00.37 php-cgi
12355 vu10002 20 0 129m 8488 3284 S 11 0.2 0:02.93 php-cgi
12331 vu10002 20 0 127m 7852 3448 S 11 0.2 0:02.15 php-cgi
11495 vu10002 20 0 127m 8200 3544 S 9 0.2 0:07.31 php-cgi
12422 vu10002 20 0 193m 7888 3444 S 8 0.2 0:02.16 php-cgi
11524 vu10002 20 0 128m 8816 3512 R 8 0.2 0:07.30 php-cgi
12263 vu10002 20 0 130m 9968 4640 R 8 0.2 0:03.18 php-cgi
9755 vu10002 20 0 130m 9.9m 4720 R 7 0.2 0:15.65 php-cgi
9572 vu10002 20 0 130m 10m 5216 R 6 0.3 0:16.74 php-cgi
12447 root 20 0 21064 3036 1136 S 6 0.1 0:01.85 htop
12356 vu10002 20 0 130m 9880 4504 R 5 0.2 0:03.12 php-cgi
12466 vu10002 20 0 127m 8096 3096 R 5 0.2 0:00.16 php-cgi
12387 vu10002 20 0 129m 8176 3508 S 5 0.2 0:02.93 php-cgi
12392 vu10002 20 0 130m 9896 4648 R 3 0.2 0:01.58 php-cgi
7591 vu10007 20 0 133m 28m 19m S 1 0.7 0:03.41 php-cgi
12434 vu10002 20 0 193m 7872 3448 S 1 0.2 0:01.45 php-cgi
11375 vu10002 20 0 129m 9324 4624 S 1 0.2 0:09.85 php-cgi
7592 vu10007 20 0 131m 22m 16m S 1 0.6 0:03.24 php-cgi
wedlug licznika gosci, wzrosl ich poziom do okolo 2560 sztuk w trakcie testu. Strona odswierzala sie okolo 15 sek. Nie gubil sie ale zamulal.
Kawalek krotkiego testu:
Benchmarking http://rwm.org.pl (be patient)
Finished 59 requests
Server Software: Apache
Server Hostname: http://rwm.org.pl
Server Port: 80
Document Path: /
Document Length: 29642 bytes
Concurrency Level: 10
Time taken for tests: 30.069 seconds
Complete requests: 59
Failed requests: 51
(Connect: 0, Receive: 0, Length: 51, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 1764659 bytes
HTML transferred: 1749260 bytes
Requests per second: 1.96 [#/sec] (mean)
Time per request: 5096.441 [ms] (mean)
Time per request: 509.644 [ms] (mean, across all concurrent requests)
Transfer rate: 57.31 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.4 0 1
Processing: 3829 4823 336.3 4855 5439
Waiting: 3829 4823 336.3 4855 5439
Total: 3830 4823 336.1 4855 5439
Percentage of the requests served within a certain time (ms)
50% 4852
66% 4974
75% 5026
80% 5057
90% 5275
95% 5417
98% 5425
99% 5439
100% 5439 (longest request)
Co moga robic te procesy po tym jak test sie zakoczyl, i czemu zdychaja pomalu przez 20 minut a nie gina odrazu ? -
a wiec prace ida naprzod. Po odpaleniu fastcgi okazalo sie ze cos sie z sesjami stalo. Zamiast prcesy odpalac sie jako apache odpalaja sie jako userzy vu1001 itd.... coprawda oni nalaza do grupy apacha... ale cos sie kitrasi.
Nie mniej jednak, sprawy ida do przodu. :) -
Mariusz Gronczewski:
Gdy używasz mpm_worker + phpa przez fastcgi to generalnie tuning jest głównie dla plików statycznych, jeżeli chodzi o liczbe procesów phpa, ja zwykle ustawiam ją na liczba_rdzeni x2 gdy baza jest na innym serwerze lub po prostu na liczbe rdzeni gdy baza jest na tym samym serwerze (teoria jest taka że gdy baza jest na innym serwerze i jeden proces na danym rdzeniu zajmuje sie czekaniem na powrót requestu z bazy, drugi proces może tobić coś innego)
Czy fakt ze mamy ispOmege jest istotny w tym temacie ?
Co do samego wordpressa, plugin wp-cache jest bardzo pomocny, potrafi skrócić czas ładowania strony o połowę albo więcej dla stron zcachowanych (jest też wp-supercache ale dosyć skomplikowany w konfiguracji)
wordpress jest malo obciazajacy, to blog zmian jakie uskuteczeniamy na stronie. Odwiedzalnosc zedu 10 odslon dziennie. Podalem jako przyklad porownawczy. -
Dogrzebalem sie do tego stress testu... i:
siege --time=60s -c 100 http://rwm.org.pl
Lifting the server siege... done.
Transactions: 769 hits
Availability: 100.00 %
Elapsed time: 60.45 secs
Data transferred: 6.55 MB
Response time: 6.35 secs
Transaction rate: 12.72 trans/sec
Throughput: 0.11 MB/sec
Concurrency: 80.84
Successful transactions: 769
Failed transactions: 0
Longest transaction: 14.84
Shortest transaction: 0.00
teraz cos na wordpress:
siege --time=60s -c 100 http://about.rwm.org.pl
Lifting the server siege... done.
Transactions: 969 hits
Availability: 100.00 %
Elapsed time: 60.19 secs
Data transferred: 7.27 MB
Response time: 5.36 secs
Transaction rate: 16.10 trans/sec
Throughput: 0.12 MB/sec
Concurrency: 86.29
Successful transactions: 603
Failed transactions: 0
Longest transaction: 14.33
Shortest transaction: 0.02
i cos bez baz danych i php:
siege --time=60s -c 100 http://mizera.pl
Lifting the server siege... done.
Transactions: 11957 hits
Availability: 100.00 %
Elapsed time: 59.59 secs
Data transferred: 19.42 MB
Response time: 0.00 secs
Transaction rate: 200.65 trans/sec
Throughput: 0.33 MB/sec
Concurrency: 0.63
Successful transactions: 11957
Failed transactions: 0
Longest transaction: 0.15
Shortest transaction: 0.00
aktualne obciazenie prockow w ruchu:
2 x apache 77% oraz 20% pamiec odpwoeidnio 11% i 3% poza tym mysql 2% procka i 1.5% pamieci, przy takim obciazeniu wlaczylem stress test.
Jak widac strona glowna rwm, niewiele ustepuje stronie glownej wordpressa.
Zeby obraz byl pelny, podam jeszcze test dla galeri pelnej zdjec:
Lifting the server siege... done.
Transactions: 503 hits
Availability: 100.00 %
Elapsed time: 60.27 secs
Data transferred: 49.94 MB
Response time: 9.81 secs
Transaction rate: 8.35 trans/sec
Throughput: 0.83 MB/sec
Concurrency: 81.91
Successful transactions: 503
Failed transactions: 0
Longest transaction: 21.54
Shortest transaction: 0.00
Wnioski.... hmm.. galeria wypada lepiej niz glowna, to moze jeszcze live:
Lifting the server siege... done.
Transactions: 395 hits
Availability: 100.00 %
Elapsed time: 60.02 secs
Data transferred: 11.86 MB
Response time: 11.19 secs
Transaction rate: 6.58 trans/sec
Throughput: 0.20 MB/sec
Concurrency: 73.62
Successful transactions: 395
Failed transactions: 0
Longest transaction: 28.19
Shortest transaction: 0.01
i chyba ostatnie potrzebny test, to test przywolania zdjecia:
siege --time=60s -c 100 http://rwm.org.pl/relacje/?pobierz-zdjecie,105995
Lifting the server siege... done.
Transactions: 3977 hits
Availability: 100.00 %
Elapsed time: 59.96 secs
Data transferred: 6.16 MB
Response time: 0.99 secs
Transaction rate: 66.33 trans/sec
Throughput: 0.10 MB/sec
Concurrency: 65.77
Successful transactions: 3977
Failed transactions: 0
Longest transaction: 3.92
Shortest transaction: 0.00
"z tego co sie doczytalem to chodzi o usatwienie tego mpm_worker lub mpm_prefork i odpowiendich limitow dla nich. Macie wypracowane jakies ich wartosci ?" -
Peter K.:
Na pierwszy rzut oka śmierdzi mi galeria. Pliki statyczne są chyba serwowane przez coś serverside no i miniatury wyglądają na generowane w locie.
Obaczcie panowie
http://rwm.org.pl/relacje/?&mode=galeria&id=1688
Michale, jak to z tym jest?Peter K. edytował(a) ten post dnia 15.02.10 o godzinie 01:50
Miniaturka jak i zdjecie jest obrabiane w czasie dodwania i zapisywane na dysku. Katalogi sa po 10k plikow. Czyli zdjecie ne 105 542 bedzie w katalogu /zdjecia/11/ a jego minitura w katalogu /miniatury/11/
Miniatury sa pobierane z dysku, w locie twozyly sie kiedys, dawno dawno temu.
System wywala w galerii 12 fotek danego usera galeri, nastepne sie przewija. Dodajac zdjecie, rownierz nie wyswietlaja sie wszystkie miniaturki danej galerii, a ostatnie 8em. Reszta jest dostepna po kliknieciu w link, tak by nie trzeba bylo za duzo miniturek naraz wyswietalc (czasami w jednej galeri jest kilka tysiecy fotek).
Co do napisania od poczatku, wiem, zdaje sobie z tego sprawe ale wieszak tego nie poczyni, a nie znam nikogo kto by mogl. Pozatym, jest to portal spolecznosciowy, ja na nim nie zarabiam, wrecz przeciwnie, dokladam i utrzymuje go a co za tym idzie, wylozeniu ... tysiecy zl na przepisanie tego... narazie pozostaje w swerze mazen. Moze kiedys. Mam jeszcze mase pomyslow o co to wzbogacic, ale nie ma komu tego pisac... szkoda. Ja w miare swoich mozliwosci bede to powoli robil.
Na dzis, temat jest taki, ze trzeba to zoptymalizowac od strony softow na serwerze, technologia opteronow w tym wydaniu sie juz konczy i bardziej nie ma juz co unowoczesniac sprzeta. Jak okaze sie ze sie nie da, znowu trzeba bedzie zmieniac platforme, a to kolejne koszty... nie male zreszta.
Wiem ze kazdy za swoja prace pragnie otrzymac wynagrodzenie, fundesze takie jakie sa, takie sa. Lokalne jednostki niechca wesprzec projektu.
Ja, ja chce jezdzic rowerem i dobrze sie bawic :) -
Jak świrują procki to odpal program top, htop i obserwuj co obciąża procesor. Zapisz użycie pamięci (free -m), zaobserwuj czy nie korzysta mocno z pamięci swap, co z I/O dysków?
Jak znajdziesz przeciążający system proces to można szukać odpowiedzi dlaczego ten proces tak przeciąża system. Czy to jego wina czy danych (ilości, formy,...), w tym momencie może być niezbędne stworzenie testu. Przykładowo stwierdzisz, że to apache, musisz stworzyć test badający obciążenie serwera wraz ze wzrostem ilości zapytań, itd...
Zawsze na szczycie TOP sa procesy apache. Czasami nawet 4 sztuki. Merginalnie jeden z nich potrafi nawet 40% procka zrzerac. Pamieci nigdy wiecej niz 8% nie widzialem przy apachu. Potem pojawia sie mysql, ale nie wiecej niz 10% procka i 5% pamieci. Czasami jakis proftpd wskoczy na chwile, ale to tak 5% cpu i troche pamieci, potem smieci po 1% - 0%
brit mizera # free -m
total used free shared buffers cached
Mem: 3968 3684 284 0 161 2327
-/+ buffers/cache: 1194 2774
Swap: 7817 13 7804
memcache ma zarezerwowane 2 Gb ramu, choc puki co go nie uzywamy, bo nie umiemy :)
kilka rzeczy mozna wywnioskowac tez stad:
http://netglob.com.pl/mrtg
user: mrtg
pass: mrtg777
nie widac momentu przeciazenia, bo ostatni trwajacy okolo 6h byl w pazdzeirniku. Koljeny bedzie za 2 miesiace (kolejna edycja Live z Harpagan39). Stad cala burza. Potem mamy prowadzic Live z eliminacji mistrzostw swiata w jezdzie rowerem na orientacje MTBO. Chcialbym sie przygotowac za wczasu na te ewentualnosci.
Piszesz o stres testach, uzylem kiedys czegos, nie pamietam, ale pamietaqm wynik. Chodzilo o zasymulownie 10 userow klikajacych na strone glowna. Odslaniajac zwykla strone html dochodzil do 1600 odslon na minute i zaczely pojawiac sie straty. Dla joomli i wordpressa wynik bylo okolo 1200 - 1400 na minute. Dla strony glownej rwm... 98 :/ dla strony live-a 270, forum 180.
Wiem ze softa do stres testu instalowalismy lokalnie na maszynie i mozna nim bylo tez odpytywac obce serwery. Jak sie nazywal, nie pamietam, a szkoda bo bym go teraz z nowymi prockami wyprubowal. -
Mariusz Gronczewski:
cóźż, ucz się lub znajdź kogoś obeznanego w tym, taki serwerek powinien uciągnąć taki ruch bez większego problemu
:) W pierwszym poscie napisalem ze szukam kogos takiego. Mam nawet jakies tam fundusze na to przeznaczone. Wiec jak ktos ma ochote sobie dorobic, to zapraszam na prv ktorego podalem w pierwszym moim poscie :)
Ja tym czasem, douczam sie i jakos malo z tego wychodzi :) -
Dodam jeszcze, bo moze to miec znaczenie, na serwerze jest zainstalowana ispOmega.
-
Mariusz Gronczewski:
Powiedz najpierw czy to PHP muli czy baza.
Podejrzewam że używasz mod_ph, który jest niezbyt ciekawy jeżeli chodzi o wydajność, odpal to na lighttpd (domyślna konfiguracja wymaga praktycznie zrobienia jednego symlinka żeby włączyć PHPa), a jeżeli odpada (np app używa pokręconego htaccess) to chociaż apachowy mpm_worker zamiast mpm_prefork + fastcgi do phpa
Jak wspomnialem na wstepie, tutaj juz to co piszesz mnie przeraza :D
Ale poczynie co w mojej mocy, jak zglebie, sprawdze i skoryguje to o co pytasz w poscie powyzej dam znac :)
Niech moc google bedzie ze mna :) -
Adam Tomasz Kajer:
Michal Mizera:
Panowie, piszecie tu takie straszne zeczy :)
Ja mam inny problem, nie znam sie :) a potrzebuje optymalizacji serwera. Stworzylem taki maly wortalik spolecznosciowy o wycieczkach rowerowych (http://rwm.org.pl) i jak przychodzi "Dzien Sądu" czytaj relacja na zywo z Harpagana, to za kazdym razem zabija mi maszyne.
W przeciagu 1.5 roku bylo okolo 5.5 mln odslon... taki ruch mniej wiecej generuje.
Ilość stron w roku dużo nie mówi w kontekście tego co piszesz. Jaki ruch jest w "dzień sądu" (w przybliżeniu), ile requestów na minutę/sekundę. Jakie masz łacze, są filmy w flv, duże pliki (foty). Masa innych pytań... o bazę chociażby. Optymalizacji może być masa albo i wcale. Najważniejsze jeszcze pytanie co to znaczy "zabija maszynę"?
okolo 70 reqestow na sekunde jest w "dniu sadu". Na codzien, 30 reg/sek. 75,78% z tego to select.
Łacze, symertyczne 2 mbpsy wpiete w światlowód tasku. W nocy 23:30 - 11:00 symetryczne 8 mbpsow. Usluga realizowana przez JarSat.
Nie ma duzych filmow, najwiekszy plik ma kilka megabajtow (filmiki z aparatow jak ktos na wyceiczce kreci). Głownie zdjecia po kilkaset kilo i miniaturki (w relacjach jest okolo 120 000 zdjec)
Zabija, znczy procki swiruja na 100%, load wskakuje na +40 a wyswieltenie strony graniczy z cudem.
Mozesz pytac o co chcesz, na to co wiem odpowiem, co nie wiem zapytam sie osoby ktora pisala strone i tez odpowiem. -
Panowie, piszecie tu takie straszne zeczy :)
Ja mam inny problem, nie znam sie :) a potrzebuje optymalizacji serwera. Stworzylem taki maly wortalik spolecznosciowy o wycieczkach rowerowych (http://rwm.org.pl) i jak przychodzi "Dzien Sądu" czytaj relacja na zywo z Harpagana, to za kazdym razem zabija mi maszyne.
W przeciagu 1.5 roku bylo okolo 5.5 mln odslon... taki ruch mniej wiecej generuje.
Sprzet do:
- proce: 2 x opteron 275
- ram: ecc 4 gb
- dyski scsi: 2 x 73 mirroring na system i 5 x 147 w raidzie 5 na potrzeby reszty
- gentoo
- apache 2
- php 5
- mysql 5
Soft dziala na ustwieniach defaultowych.
Jezeli ktos mogl by pomoc (odplatnie) w ogarnieciem tego, byl bym wdzieczny :)
kontakt: gg:36079 -
Ja może się wtrące :)
Otóż każda drukarka czy to atramentowa czy laserowa wymaga opieki. O ile kwestia regeneracji wiąże się z nawykami użytkowników, o tyle niedbałość w trakcie eksploatacji szczególnie drukarek laserowych jest żenująca wśród użytkowników, ale dzięki temu mamy pracę :)
Co do samej regeneracji, uważam że tonerów nie da się metodami domowymi napełnić zgodnie ze sztuką i ochroną środowiska.
Tusze atramentowe, domowym sposobem można regenerować równie dobrze jak maszyną zakładając że użytkownik nie będzie czekał aż tusz się skończy i głowica zaschnie. Uzupełniając na bieżąco takie dolewanie będzie równie skuteczne przynajmniej przez jakiś czas.
Użytkownicy maszyn regenerujących i tak najczęściej wstrzykują tusz strzykawką... bo szybciej. Udrożnienie realizuję się przez kompresory ssące. Osobiście nie jestem ich zwolennikiem, używamy pompy olejowe niskiej próżni. O wiele skuteczniejsza. No ale użytkownik domowy nie zakupi sobie takiego sprzętu bo i po co ?
Jedna z istotniejszych kwestii jest sam tusz. Na allegro cała masa tych wynalazków, już na 45zł możemy mieć litr ! Co z tego ze druk jest nie wyraźny, tusz nie wiąże i przebija na drugiej stronie kartki. Każdy ma to co lubi.
My naszym klientom proponujemy oryginały, zamienniki, regenerację oraz materiały do regeneracji. -
no to teraz i mnie tutaj znajdziecie :D
- 1
- 2
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
