Имеется следующий вопрос.
Был у нас EProxy 3 на Сервере P4 с оперативкой 1 Гб Операционка Windows Server 2003 Web Server x32 Перестал справляться с нагрузкой.
Купили новый Xeon С Windows Web Server 2008 x64. Там тоже поставили EProxy 3.
Оба сервака стоят в отдельной сети (DMZ).
Проблема в следующем. На новом сервере (Xeon) Прокся безбожно тормозит. Страничка появляется не раньше чем через 5 секунд после нажатия на ссылку. Потом не спеша картинки подгружаются. Такая ситуация имеет место, если идешь через прокси из локальной сети, отделенной от DMZ маршрутизатором. Если подключить клиента в DMZ, прокси срабатывает быстро и четко.
На старом сервере (P4+Win2003) таких проблем не наблюдается.
Когда возникла проблема, все эксперименты провел и на E4. Результат тот-же.
Может кто уже сталкивался?
Еще посмотрите — может быть DNS на этих двух серверах настроен на разные IP.
ред: 25.06.2010 13:59
Штука в том, что ничего кроме EServ не тормозит. RDP моментально соединяется, да и остальные тоже нормально.
Провел пару экспериментов. Назовем новый сервер LocalNEW (XEON), а старый LocalOLD (P4)
На каком этапе задержка — можно попробовать поймать, включив "vDebugRules ON" (раскомментировать в конфиге и перезапустить). Тогда он в Eproxy.log (E3) или acWEB.log (E4) будет писать этапы выполнения правил — соединение, обработка, ответ — с меткой времени для каждого этапа. Вот сравнением таких логов на двух серверах наверное найдём причину.
И в первом и во втором опыте трафик идет через маршрутизатор.
Меняется только прокси (E3 на TCP-Logger). В первом тормозит а во втором нет. Возможно винда мешает EProxy что-то проверить. Поэтому он так долго думает.
В принципе видны места задержек. С логом второго сложнее. Им народ пользуется.
<30>
Эксперимент 3.
В CommonPlugins\IpMacAuth.rules.txt закомментировал единственную строчку.
Тормоза пропали.
Написал там CLIENT_MAC TYPE CR. Тормоза вернулись.
В Windows прописал arp -s IP_клиента MAC_клиента
Тормоза пропали.
Вывод. У EProxy проблемы с определением MAC адреса. Что понятно. Клиент за маршрутизатором. Тем не менее. В Win2003 такой проблемы не возникало. Не мог, но и не тормозил.
Все абсолютно одинаковое.
Блуждают. Вот как это обойти. Мол не смог определить — не надо. Не ждать эти 7-10 секунд.
ред: 25.06.2010 16:23
Наверное это сейчас единственный выход. Это будет и в E4?
p.s. Сейчас убрал функцию Client_MAC из файла. Но это не есть хорошо. Лучше действительно флаг.
ред: 25.06.2010 16:47
http://msdn.microsoft.com/en-us/library/aa366358(VS.85).aspx
"On Windows Vista and later, the ResolveIpNetEntry2 function can used to replace the SendARP function. An ARP request is sent if the Address member of the MIB_IPNET_ROW2 structure passed to the ResolveIpNetEntry2 function is an IPv4 address. "
Еще неплохая альтернатива — это GetIpNetTable.
Теоретически должна работать значительно быстрее. Так-как не посылает ARP запросов. А просто проверяет локальную таблицу. А если с компьютером установлено соединение (как в нашем случае) и адрес возможно получить, то он будет в локальной таблице.
Вообще, если верить тому же MSDN'у, то Vista и W2008 должны кэшировать ARP-информацию, и не отправлять лишние ARP-запросы. На практике, как видите, это не так. Из вашего эксперимента можно сделать вывод, что скорее W2003 кэширует, а W2008 нет.
Можно просто проверять поле "MAC клиента" в файле. Если 0 или *, Client_MAC не вызывать.
И все. Задача с блеском решена