Имеется следующий вопрос.
Был у нас 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)
Из этого я делаю вывод, что связь с LocalNEW нормальная. Маршрутизация не причем.
Остается DNS. Но а) DNS у обоих серверов настроен одинаково. Только на DNS провайдера. Локальные DNS не доступны обоим. б) Если открыть ya.ru на самом LocalNEW (через IE) тормозов нет.
Следовательно. Путь из сети до сервера чистый, от сервера в инет тоже. Остается вывод, задержку дает EProxy.
На каком этапе задержка — можно попробовать поймать, включив "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
"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 не вызывать.
И все. Задача с блеском решена