Кто-нибудь замечал, что TidHTTPServer медленно соединяется?

← →
It's not me (2009-03-11 13:08) [0]

Есть удаленная 1C"ка, которая посылает HTTP-запросы. Нужно написать программу по приему этих запросов.

Для тестирования возможет такой вариант - нажимаешь кнопочку и 1C высылает запрос по указанному IP и порту.

Так вот заметили странное. Если прием написать с помощью TIdHTTP, достаточно разместить idHTTP на форме, настроить порт и засечь время до возникновения события OnCommandGet. Так вот от нажатия кнопочки в 1C до возникновения события OnCommandGet в indy сервере проходит порядка 2-3 секунд. ОЧЕНЬ ДОЛГО в нашем случае и задержка видна невооруженным глазом.

На стороне 1C не очень понятно что делается, понятно что нажимаешь кнопочку - идет запрос. Можно было бы грешить на глюки со стороны 1C, ее компоненты и прочего.

НО. Если использовать не idHTTP, а idTCPServer и вручную принимать HTTP-трафик, то от нажатия кнопочки в удаленной 1C до полного приема данных проходят МИЛЛИСЕКУНДЫ, очень быстро.
Проблема только в том, что если HTTP информации много, она может приходить разными TCP-пакетами, соответственно надо вручную клеить, а этого хотелось избежать, используя стандартный idHTTP, но придется, видимо.

Но вопрос все равно интересует - почему же indy HTTP сервер такой медленный и так долго устанавливает коннект?! С чем это вообще может быть связано? Или это нормальное поведение indy, он просто такой тормозной? Вроде бы при этом эти 2-3 секунды нагрузки на процессор нету особо, откуда таой "лаг" берется - непонятно.

← →
DVM © (2009-03-11 13:13) [1]

> Вроде бы при этом эти 2-3 секунды нагрузки на процессор
> нету особо, откуда таой "лаг" берется - непонятно.

Не наблюдал такого. Проверь, не включены ли у тебя какие файерволлы или антивирусы типа Касперского. Сталкивался много раз с их некорректным поведением в этом плане. Касперский же вообще умудрялся портить заголовки HTTP запросов/ответов. И кеширование их тоже сильно мешает работе.

← →
Сергей М. © (2009-03-11 13:21) [2]

> Если использовать не idHTTP, а idTCPServer

Что за ахинею ты несешь ?

Как можно использовать серверный компонент вместо клиентского ?

← →
Сергей М. © (2009-03-11 13:24) [3]

> удаленная 1C"ка, которая посылает HTTP-запросы

Какими средствами она это делает - встроенными илим средствами какого-то http-клиента во внешнем 1С-компоненте

← →
test © (2009-03-11 13:24) [4]

Сергей М. © (11.03.09 13:21) [2]

>>Есть удаленная 1C"ка, которая посылает HTTP-запросы. Нужно написать
>>программу по приему этих запросов.

Помойму у него как раз сервер.

← →
Сергей М. © (2009-03-11 13:28) [5]

> Помойму у него как раз сервер

А причем тогда IdHTTP ? Это клиентский компонент а не серверный.

← →
It's not me (2009-03-11 13:29) [6]

мы обо всем этом думали. Но никакой файервол не может установить как мы принимаем пакеты - с помощью компонента TidHTTP или вручную через TidTCP.
И наблюдение строго повторяется на двух компьютерах как минимум.

Причем, кода нет как такового. Просто в событии OnCommandGet можно поставить beep; и забрекпоинтить. С момента нажатия кнопки в 1C до срабатывания BP проходит 2-3 секунды, это видно невооруженным взглядом. Если запускать без среды и отладчика - один фиг задержки те же.

Более того, проверяли и на разных Indy, и на разных средах. Проверяли на Delphi 7 (с инди HTTP-сервером по-умолчанию), а также проверяли на C++ Builder 6 (тоже по-умолчанию все компоненты). Один фиг одно и тоже.
И плюс еще на разных компах.

P.S. У меня два варианта пока:

1) инди реально такой тормозной. Вполне, кстати, может быть. Моя веб-админка, построенная на indy, не сказать что летает. Просто HTTP используется обычно там, где скорость не так уж принципиальна, многие могут просто не замечать. Ну подумаешь страница открылась на 2 секунды позже, все таки скорость рендеринга страниц, другие тормоза, сайты в интернете под апачем из-за нагрузки иногда по 10 секунд отвечают, как бы все привыкли.

2) 1C"ка как-то неправильно, не по стандарту высылает HTTP-пакет...
Но что может вызывать такой лаг, причем именно 2-3 секунды, стабильно, данные всегда доходят, данные правильные. При приеме информации через TidTCP никаких странностей не обнаружили в HTTP-трафике - заголовок, само тело пакета, вроде все как надо. Хотя могли что-то и пропустить.

В общем, непонятно нифига.

← →
It's not me (2009-03-11 13:32) [7]

> Помойму у него как раз сервер.

да, под idHTTP имеется в виду TidHTTPServer, под TidTCP меется в виду TidTCPServer. В общем, все серверное.

← →
Сергей М. © (2009-03-11 13:33) [8]

> в событии OnCommandGet можно поставить beep; и забрекпоинтить

OnConnect возникает раньше.

← →
It's not me (2009-03-11 14:03) [9]

да, OnConnect срабатывают сразу. А через 2-3 секунды только OnCommandGet.

← →
KSergey © (2009-03-11 14:03) [10]

как вариант, без фактов, фантазия: 1С шлет не тот заголовок, котрый ожидает инди, в части концовки. Инди какое-то время ждет, потом теряет надежду дождаться и вызывает OnCommandGet с тем, что есть. А если из браузера? или телнетом руками набить запрос?

← →
Сергей М. © (2009-03-11 14:16) [11]

Следы ведут в куки.

Чему равно SessionState в момент возбуждения OnCommandGet ?

← →
It's not me (2009-03-11 14:35) [12]

SessionState установлен в False на компоненте.
При возникновении OnCommandGet он также равен false.

Приведи "грязный" текст http-запроса

← →
It's not me (2009-03-11 15:09) [14]

Проверили мою теорию из [6] пункт 2. (ну в общем тоже самое, что KSergey в [10]) сказал.

Снифером оказалось, что HTTP-запрос приходит двумя TCP-пакетами. В первом по большей части содержится заголовок HTTP-пакета с директивой continue... Я так понимаю, это вопрос серверу типа готов ли он принять данные.

Но idHTTPServer один фиг на этот вопрос ничего не высылает. При этом все равно через 2 секунды идет второй TCP пакет, именно после этого TidHTTP считает HTTP-пакет завершенным и вызывает OnCommandGet.

При этом со стороны 1C делался POST-запрос, он вот такой странный, с continue и лагом. Переделали на GET-запрос со стороны 1C, сама информация теперь передается в заголовке HTTP-пакета в спец. поле ))) Некошерно, зато все заарбатало.

Засим можно сделать вывод, что на TidHTTP грешил зря, с ним все ок.
Ну или частично ок, если считать что он должен, но не умеет обрабатывает такие POST-запросы, где ставится директива в заголовке:

Expect: continue

Или он может разбирать такие ситуации, тогда мы просто не знаем как )
По идее по такой директиве сервер должен послать подтверждение, что готов принять данные или закрыть соединение. Непонятно, где в TidHTTPServer это реализовать.

И соответственно, почему при неподтверждении все равно через пару секунд 1C один фиг досылает данные.
Ну это чисто уже любопытство.

> Или он может разбирать такие ситуации, тогда мы просто не
> знаем как

см. внимательно на реализацию ф-ции HeadersCanContinue (IdCustomHTTPServer.pas) и еще внимательней на событие OnHeaderExpectations

Кто-нибудь замечал, что TidHTTPServer медленно соединяется? Найти похожие ветки