Temat: Proxy na linuxie

Szkoda tylko że brakuje w sumie najważniejszego statu czyli obciążenia i/o ale potwierdza tylko co mówili przedmówcy, procesor jest najmniej ważny.

Temat: Proxy na linuxie

Mariusz Gronczewski:
Szkoda tylko że brakuje w sumie najważniejszego statu czyli obciążenia i/o ale potwierdza tylko co mówili przedmówcy, procesor jest najmniej ważny.

Dowiem sie czy moge upublicznic te statystyki.
W sumie wszystko o I/O jest w CacheMgr.

EDIT:

~450 IOPS przy ~200 reqs/s.Łukasz S. edytował(a) ten post dnia 10.09.09 o godzinie 12:45

Temat: Proxy na linuxie

Tak dla porównania
Dosyć stary dysk SATA 120GB ~150 ops/sek ( random ops w bonnie++ )
RAID5 na 3 dyskach SAS 10k RPM ~700 ops/sek

Temat: Proxy na linuxie

Mariusz Gronczewski:
Tak dla porównania
Dosyć stary dysk SATA 120GB ~150 ops/sek ( random ops w bonnie++ )
RAID5 na 3 dyskach SAS 10k RPM ~700 ops/sek

Czyli podsumowujac - przy malej ilosci uzytkownikow wystarczy kilkuletni procesor, rozsadna ilosc ramu i dowolny, nowy dysk SATA wiszacy na dobrym kontrolerze.

Temat: Proxy na linuxie

Łukasz S.:

Mariusz Gronczewski:
Tak dla porównania
Dosyć stary dysk SATA 120GB ~150 ops/sek ( random ops w bonnie++ )
RAID5 na 3 dyskach SAS 10k RPM ~700 ops/sek

Czyli podsumowujac - przy malej ilosci uzytkownikow wystarczy kilkuletni procesor, rozsadna ilosc ramu i dowolny, nowy dysk SATA wiszacy na dobrym kontrolerze.

Ostatnio realizowałem bramkę na maszynie Celeron 550, 128 MB Ram, 20 Gb Pata. Dla 6 userów działa bez większych problemów. Łącze 4mbit. Debian 5.0 plus moje custom kernele, htb, layer7, imq, squid, dns/dhcp.
Taki złom klient znalazł na magazynie pytając czy da się coś z tym zrobić. Sam byłem ciekaw - jak widać działa.Marcin Bojko edytował(a) ten post dnia 11.09.09 o godzinie 08:26

Temat: Proxy na linuxie

może nie napisze na temat ;p lecz mam sieć wifi (własna firma) i ok 30 klientów. serwer który mi zarządza całym netem z proxy to serwer DEBIAN (linuxrouter.pl)
Procesor:Intel(R) Pentium(R) 4 CPU 1.60GHz
RAM: 512
Dysk: 80 GB
i obciążenie procka to 20% więc taki serwer może obsłużyć dużo więcej osób. Do proxy nie jest potrzebny duży komp, taki jak ja mam procek to w zupełności wystarczy.
A i zapomniałem napisać że mam na serwerze postawioną stronę www. łącze dsl 4000 i spokojnie śmiga. A i jeszcze chce drugie łącze zabrać i podłączyć do tego serwera.

Temat: Proxy na linuxie

Sporo lat temu optymalizowałem Squida na różnych maszynach (głównie na stacjach Suna) dla sporej liczby (ca 250) klientów.
Generalnie problem z wydajnością Squida sprowadza się do zapewnienia szybkiej obsługi pojedynczego żądania. Dlatego należy wyciąc co się da z niepotrzebnych czynności Squida, takich jak logowanie, sprawdzanie nazw odwrotnym DNS-em, wysyłanie
komunikatów do sysloga (jeśli zakładamy, ze Squid prowadzi własny log). Kolejne kroki to optymalizowanie list kontroli dostępu (im więcej wpisów, tym dłuższe przygotowanie przetwarzania pojedynczego żądania - może dać się we znaki przy
znacznym obciążeniu).
Najważniejsze jest jednak I/O. Tutaj kilka rzeczy jest istotnych:
- bufor dyskowy nie może być zbyt duży - bo będzie zbyt wolny; zamiast przydzielać więcej przestrzeni, lepiej jest zablokować cache'owanie niektórych zasobów (np. plików HTML), za to buforować intensywnie grafikę i mniejsze multimedia,
- jeśli system ma kilka dysków, dobrze jest rozproszyć bufor pomiędzy nie,
- należy wycisnąć co się da z dysku hdparmem/sdparmem tudzież wyłączeniem na dyskach zawierających bufor czasu ostatniego dostępu do pliku,
- nie należy współdzielić instalacji Squida z inną usługą intensywnie korzystającą z dysku (np. MySQL, archiwum FTP).

Przy zachowaniu powyższych zasad nawet niezbyt nowa i niezbyt "wypasiona" maszyna potrafi sporo dokonać - zwłaszcza przy niezbyt szybkim łączu do ISP.

I jeszcze jedna uwaga - procent trafień z RAM-u jest zazwyczaj tak nikły, że nie ma istotnego wpływu na ocenę szybkości pracy instalacji łącze/Squid dla klienta. Na dedykowanej maszynie najlepiej jest przydzielić 1/3 dostępnego RAM-u (Squid i tak skonsumuje więcej na całość obsługi).

M.Maciej K. edytował(a) ten post dnia 14.09.09 o godzinie 10:34

Temat: Proxy na linuxie

Maciej K.:
Sporo lat temu optymalizowałem Squida na różnych maszynach (głównie na stacjach Suna) dla sporej liczby (ca 250) klientów.
Generalnie problem z wydajnością Squida sprowadza się do zapewnienia szybkiej obsługi pojedynczego żądania. Dlatego należy wyciąc co się da z niepotrzebnych czynności Squida, takich jak logowanie, sprawdzanie nazw odwrotnym DNS-em, wysyłanie
komunikatów do sysloga (jeśli zakładamy, ze Squid prowadzi własny log). Kolejne kroki to optymalizowanie list kontroli dostępu (im więcej wpisów, tym dłuższe przygotowanie przetwarzania pojedynczego żądania - może dać się we znaki przy
znacznym obciążeniu).
Najważniejsze jest jednak I/O. Tutaj kilka rzeczy jest istotnych:
- bufor dyskowy nie może być zbyt duży - bo będzie zbyt wolny; zamiast przydzielać więcej przestrzeni, lepiej jest zablokować cache'owanie niektórych zasobów (np. plików HTML), za to buforować intensywnie grafikę i mniejsze multimedia,
- jeśli system ma kilka dysków, dobrze jest rozproszyć bufor pomiędzy nie,
- należy wycisnąć co się da z dysku hdparmem/sdparmem tudzież wyłączeniem na dyskach zawierających bufor czasu ostatniego dostępu do pliku,
- nie należy współdzielić instalacji Squida z inną usługą intensywnie korzystającą z dysku (np. MySQL, archiwum FTP).

Przy zachowaniu powyższych zasad nawet niezbyt nowa i niezbyt "wypasiona" maszyna potrafi sporo dokonać - zwłaszcza przy niezbyt szybkim łączu do ISP.

I jeszcze jedna uwaga - procent trafień z RAM-u jest zazwyczaj tak nikły, że nie ma istotnego wpływu na ocenę szybkości pracy instalacji łącze/Squid dla klienta. Na dedykowanej maszynie najlepiej jest przydzielić 1/3 dostępnego RAM-u (Squid i tak skonsumuje więcej na całość obsługi).

M.

Od tego czasu niewiele się zmieniło :)
- optymalny bufor dyskowy zależy od tego CO chcemy cacheować. Nie ma prostej zależności 'wielkość bufora/szybkość'. Jest za to zależność - każdy MB przestrzeni dyskowej cache pochłania na 'dzień dobry' pewną ilośc pamięci RAM - do samej obsługi.
W poruszanych wyżej tematach dominowało cache'owanie codziennego ruchu 'enduserskiego' plus poprawki Windows, definicje AV itp. Trzeba to niestety testować łącznie z parametrem maksymalnej wielkości pliku przechowywanego w cache dyskowym.
Generalnie bardziej składniam się ku uzywaniu COSS jako cache type.
- kolejne optymalizacje to zastosowanie reiserfs, lub przynajmniej wyłączenie journalingu na ext3, jak również last-accessed-time - o czym wspomniałeś.
- rozdzielenie cache'a na fizyczne dyski również ma swoje plusy i minusy, zwłaszcza przy wykorzystaniu NCQ czy TCQ dla SCSI. testowałem natomiast rozwiązanie z RAID0 i o ile sprzęt na to pozwala, to jest to dobra opcja.
- oczywiście, współdzielenie i/o-żernego squida z innymi aplikacjami nie jest wskazane.
- przy deklaracji zaalokowanej pamięci w squid.conf nalezy pamiętać że drugie tyle pochłonie sam squid jako exec.
- zgadzam się równiez z tezą o RAM/hit ;)

Zapomniałem dodać - squid jest jednym z niewielu pakietów które zawsze kompiluję ze źródeł, zamiast korzystać z gotowych binarek.Marcin Bojko edytował(a) ten post dnia 14.09.09 o godzinie 10:58

Temat: Proxy na linuxie

Marcin Bojko:
Od tego czasu niewiele się zmieniło :)
- optymalny bufor dyskowy zależy od tego CO chcemy cacheować.

Otóż to. Dlatego najlepiej jest nie wrzucać wszystkiego "do jednego wora". Zbyt wiele plików do obsługi to zbyt duża baza danych o plikach i spowolnienie reakcji zwłaszcza na słabszych maszynach - słabo to widać w obciążeniu procesora, bo to są zbyt krótkie interwały, ale przy pomiarze prędkości ściągania pliku (zwłaszcza niewielkiego) odbija się czkawką.
Ogólnie - tak jak napisałeś - wielkość cache'a i maksymalną wielkość pliku najlepiej jest badać empirycznie.

P.S. Też jestem za kompilowaniem Squida - można wyciąć co niepotrzebne i dołozyć trochę optymalizacji.Maciej K. edytował(a) ten post dnia 14.09.09 o godzinie 11:02

Temat: Proxy na linuxie

Zgadzam sie z przedmowcami, ale mysle, ze warto by zdefiniowac jaki "memory hit ratio" jest "znikomy".

Request Memory Hit Ratios:	5min: 39.6%, 60min: 37.8%

Request Disk Hit Ratios:	5min: 40.7%, 60min: 42.4%

Osobiscie nie zdefiniowalbym ~40% jako "znikomy".

Temat: Proxy na linuxie

Zależy od typu obciążeń.

Ale typowo jak nawet Squid dostanie 1/6 RAMu to 4/6 kernel sobie użyje do buforów dyskowych i wyjdzie podobnie (tylko pewnie squid niepotrzebnie skopiuje żądane dane do "swojej" części RAMu)

Temat: Proxy na linuxie

Łukasz S.:
Zgadzam sie z przedmowcami, ale mysle, ze warto by zdefiniowac jaki "memory hit ratio" jest "znikomy".

Request Memory Hit Ratios:	5min: 39.6%, 60min: 37.8%

Request Disk Hit Ratios:	5min: 40.7%, 60min: 42.4%

Osobiscie nie zdefiniowalbym ~40% jako "znikomy".

Zależy od koncentracji "zainteresowań" użytkowników. Jeśli masz dostęp okreslony polityką korporacji do trzech-pięciu witryn zewnetrznych albo cache'ujesz intranet, to będą oni pobierać wciąż te same zasoby - wciąż przechowywane w RAM-ie. Mi przy liberalnej uniwersyteckiej polityce dostępu plus kilku instytucjach zewnętrznych procent CACHE_MEM_HIT nie przekraczał 2%.

Temat: Proxy na linuxie

Maciej K.:

Łukasz S.:
Zgadzam sie z przedmowcami, ale mysle, ze warto by zdefiniowac jaki "memory hit ratio" jest "znikomy".

Request Memory Hit Ratios:	5min: 39.6%, 60min: 37.8%

Request Disk Hit Ratios:	5min: 40.7%, 60min: 42.4%

Osobiscie nie zdefiniowalbym ~40% jako "znikomy".

Zależy od koncentracji "zainteresowań" użytkowników. Jeśli masz dostęp okreslony polityką korporacji do trzech-pięciu witryn zewnetrznych albo cache'ujesz intranet, to będą oni pobierać wciąż te same zasoby - wciąż przechowywane w RAM-ie. Mi przy liberalnej uniwersyteckiej polityce dostępu plus kilku instytucjach zewnętrznych procent CACHE_MEM_HIT nie przekraczał 2%.

U mnie 6%.

Temat: Proxy na linuxie

Zależy od koncentracji "zainteresowań" użytkowników. Jeśli masz dostęp okreslony polityką korporacji do trzech-pięciu witryn zewnetrznych albo cache'ujesz intranet, to będą oni pobierać wciąż te same zasoby - wciąż przechowywane w RAM-ie. Mi przy liberalnej uniwersyteckiej polityce dostępu plus kilku instytucjach zewnętrznych procent CACHE_MEM_HIT nie przekraczał 2%.

Powyzsze dane sa z bardzo duzej (/16) uniwersyteckiej sieci.

Temat: Proxy na linuxie

Łukasz S.:

Zależy od koncentracji "zainteresowań" użytkowników. Jeśli masz dostęp okreslony polityką korporacji do trzech-pięciu witryn zewnetrznych albo cache'ujesz intranet, to będą oni pobierać wciąż te same zasoby - wciąż przechowywane w RAM-ie. Mi przy liberalnej uniwersyteckiej polityce dostępu plus kilku instytucjach zewnętrznych procent CACHE_MEM_HIT nie przekraczał 2%.

Powyzsze dane sa z bardzo duzej (/16) uniwersyteckiej sieci.

Moja też była /16, co nie zmienia faktu, że mało trafień było w RAM. Faktem jest, że tego RAM-u też nie było w GB, co na pewno zmniejszało szanse trafienia. Przy "celku" z 512 MB z pierwszego postu też ich za wiele nie będzie, zresztą na taki zestawie waskim gardłem będzie dysk - i tam też będzie można najwięcej zyskac w wyniku optymalizacji.