LINUX.ORG.RU
Форум — Admin  

Как спецы диагностируют тормоза прокси?


0

0
Есть умеренно толстый внешний канал. Роутер R прозрачно перенаправляет http трафик на соседнюю машинку P, где tinyproxy + dansguardian обрабатывают и засылают запросы снова через R наружу. Ну и ответы соотв. обратно по цепочке. Связка тормозит довольно сильно, по сравнению с прямым выходом наружу.

Вопрос к профессионально владеющим искусством администрирования: какие есть методы диагностики того, кто тормозит?

Если это важно - роутер wl500w, машинка под проксями - olpc под убунтой (с родным olpc-шным ядром). Есть ощущение(????), что под родным олпсшным линуксом оно тормозило меньше. Но, возможно, я ошибаюсь. Если верить top, проц olpc не сильно загружен.

Связку пробовал и wifi и eth/100 - разницы не вижу, если честно (что неудивительно, внешний канал все-таки поменьше 54мб).

Прозрачность прокси обеспечивается такими вот бессмертными строками:

iptables -t nat -A PREROUTING -i $LAN -s ! $httpproxy -p tcp --dport 80 -j DNAT --to $httpproxy:$httpproxy_port

iptables -t nat -A POSTROUTING -o $LAN -s $network -d $httpproxy -j SNAT --to $wifiap

Спасибо!

★★★★★
← Процесс kipmi0 ест ресурсы
ulog-acctd - коды протоколов? →
Если сделать прокси явным в браузере и убрать эти две строчки iptables с роутера - скорость практически не меняется.
svu ★★★★★
() автор топика
Ответ на: комментарий от Bers666
На "соседней машинке P" с каналом все ОК? попробуйте просто скачивать большие файлы из инета , залогинившись на нее -- как скорость?
Bers666 ★★★★★
()
Проксик, случайно, в своп не полез ?
А то, может памяти мало... Надо настройки подкрутить
ovax ★★★
()
Уточняющий вопрос - линейная скорость ПРИ ПЕРЕКАЧКЕ БОЛЬШОГО ФАЙЛА (важно!!!) в случае работы через transparent proxy заметно меньше чем при явном указании или такая же?

Если "нет, линейная скорость не меняется" - то проблема в многократном DNS: а) сначал запрос делает сам браузер б) затем прокси делает запрос обратного ресолвинга в) прокси делает запрос к заказанному сайту (определяется через поле Host запроса)

no-dashi ★★★★★
()
по частям диагностируй:

1) тачка внутри -> wl500w (NAT) -> интернет
2) тачка внутри -> сервер со сквидом (прямая закачка)
3) сервер со сквидом -> wl500w (NAT) -> интернет

про сам канал ни слова... хорошо бы конфигурацию днс уточнить, ну и схему сети тоже покажи, кто откуда растет.
chocholl ★★
()
Ответ на: комментарий от Bers666
Топ говорит, что практически вся система idle.
svu ★★★★★
() автор топика
Ответ на: комментарий от Bers666
Вроде ок. Но на всякий случай попробую, спасибо.
svu ★★★★★
() автор топика
Ответ на: комментарий от ovax
Да, на память я не смотрел, только на проц. Памяти в olpc конечно мало. Надо будет проверить.
svu ★★★★★
() автор топика
Ответ на: комментарий от no-dashi
О, вот это действительно хорошая мысль. Возможно, даже близкая к истине - потому что есть смутное ощущение, что тормоза именно в начальный момент запроса. Я, конечно, большой файл проверю - но если это именно так, куда дальше копать?
svu ★★★★★
() автор топика

Бессметрные строки.

>iptables -t nat -A PREROUTING -i $LAN -s ! $httpproxy -p tcp --dport 80 -j DNAT --to $httpproxy:$httpproxy_port

>iptables -t nat -A POSTROUTING -o $LAN -s $network -d $httpproxy -j SNAT --to $wifiap

А чем эти бессметрные строки отличаются от аналогичной с REDIRECT?

Camel ★★★★★
()
Тормозит сама прокси. Проц и прочее - не причем.

1. Прокси целиком получает файл, прежде чем передать его дальше. 2. Надо смотреть количество допустимых коннектов у прокси, есть вероятность, что оно сильно меньше, чем у браузера.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk
Кол-во коннектов проверю. Но вечером я тестировал это дело один, коннекций вроде как много не создавал...
svu ★★★★★
() автор топика
Ответ на: Бессметрные строки. от Camel
Тем что редирект делает на локальный порт, а нашем случае прокся не на роуетере находится.
zhiltsov ★
()
Доп. информация.

Загрузил с cdimage.ubuntu.com образ 700М. В результате прямой загрузки 12 минут, с tinyproxy - 31 минута, c dansguardian + tinyproxy - тоже 31 минута.

Значит, это вряд ли DNS. Потому что он на bandwidth не должен влиять.

Да, если это важно - между R и P wifi 54M (буква g). Ну... так получилось - потом сделаю езернет;) Между R и компутером, который делал wget - езернет 100М. Все равно, скорость даже напрямую едва переходит за 1Мбайт в сек.

Пойду попробую wget прямо с проксевой машины...
svu ★★★★★
() автор топика
Ответ на: комментарий от svu
А вот если делать wget прямо с прокси P, тогда независимо от того, используется ли прокси, и какой именно - получаются 24 минуты. Занятненько...
svu ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Процесс kipmi0 ест ресурсы
Admin
ulog-acctd - коды протоколов? →