DansGuardian - Internet bez pornografii

Akt małżeński - szansa spotkania z Bogiem i małżonkiem

Ostatnia zmiana: 11:20 07.07.2009

Optymalizacja DG

Optymalizacja DansGuardiana [j.ang.]

Squid potrzebuje szybkiego dysku i dużo RAM'u. DansGuardian natomiast zajmuje się głównie operacją porównywania słów kluczowych, zżera więc sporo CPU. Im większa sieć, tym wymagany szybszy procesor.

Praktyczne wskazówki (jeśli CPU nie nadąża)

  1. Wyłączamy skaner antywirusowy
  2. Filtrujemy tylko po Meta Tagach i znacznikach title. phrasefiltermode = 3 Nie filtrujemy zatem już całej treści strony! Niektóre strony pornograficzne zostaną przepuszczone. Warto jednak wytestować tę opcję.

Trudno powiedzieć, który z poniższych czynników jest najważniejszy. Czasem zmiana jednego daje świetny efekt.

  • częstotliwość pobierania bardzo dużych plików
  • częstotliwość używania mediów strumieniowych (np youtube, radia internetowe)
  • sposób filtrowania (szczególnie wielkość fraz filtrujących)
  • skanowanie antywirusem (np ClamAV)
  • używanie zewnętrznych anty-phishingowych serwisów
  • grupa użytkownków odwiedzająca te same strony
  • duże grupy userów kożystejące z tych samych stron w tym samym czasie
  • architektura i szybkość lokalnych DNS

Zarys Strategii Rozwiązywania Problemów

  1. Puszczenie całego ruchu bezpośrednio do Intrnetu (bez użycia DansGuardiana/Squida). Wyłapanie możliwych problemów wydajnościowych, nie mających nic wspólnego z DansGuardianem/Squidem.
  2. Przekierowanie całego ruchu, przez samego Squida. Strony powinnych ładować się tak samo dobrze jak przy bezpośrednim dostępie. I następnie optymalizacja Squida (rozmiar, liczba katalogów i podkatalogów cache). Prawdopodobne problemy:
    • duże czasy zapytań DNS. Uruchom dwa razy testdig google.plCzas drugiej odpowiedzi powinien być około 3ms!
    • niewystarczająca ilość RAMu
    • niepotrzebna, zbyt skomplikowana konfiguracja, niewłaściwe wyrażenia ragularne
  3. Dopiero teraz możemy uruchamiać DansGuardiana, puszczając przez niego za pomocą iptables cały ruch. Dodatkowe użycie pamięci i CPU przez DG może pogorszyć działanie Squida. Wracamy więc wtedy spowrotem do optymalizacji Squida.

Zwykle wszystkie ograniczenia powinny być konfigurowane w DansGuardianie.

Ogólnie o tuningu

Buforowanie DNS dla całej sieci

dla całej sieci i dodatkowo dla squida. Świetne rozwiązanie. Np dla dostawcy GTS Energis w named.conf.options buforujemy dnsy: forwarders {
217.8.168.244;
157.25.5.18;
}; dodatkowo /etc/resolv.conf powinien wyglądać tak: nameserver localhost nic więcej. Resztę wywalamy lub hashujemy. I poleceniem dig robimy test czasu odpowiedzi. Za pierwszym razem będzie kilkadziesiąt sekund. dig onet.pl
;; Query time: 52 msec za drugim jest już zbuforowana na lokalnym serwerze bind: dig onet.pl
;; Query time: 3 msec I jak widać czas odpowiedzi jest 20 razy krótszy.

Liczba procesów potomnych

Nie jest ona krytyczna. W przybliżeniu powinna być równa użytym przez Ciebie patternom ??? Może być pomnożona razy 2.

Jeśli procesów potomnych jest zbyt małą, sprawdzanie strony może potrwać długo z kilku powodów. Po pierwsze włączający się do sieci userzy będą musieli czekać na uruchomienie nowego obsługującego ich żądanie procesu. Po drugie może się zdarzyć, że jeden proces potomny będzie musiał obsługiwać kilku userów. Z drugiej strony jeśli liczba procesów jest za duża, będą one bezczynnie, niepotrzebnie zajmować RAM. System wtedy może zacząć zrzucać pamięć operacyjną na dysk swap, co paraliżująco pogorszy wydajność. (Zauważmy, że większa niż "potrzebna" liczba procesów potomnych nie podniesie szybkości obsługi userów.) Parametr maxagechildren_parameter rzadko ma wpływ na wydajność. Jest raczej zebezpieczeniem.

Kontakt: adymala@gmail.com
Materiały na licencji GNU GPL 2009
Reklamy Google