Производительность запросов HEAD

Question

В настоящее время мы тестируем выступления на наших веб-серверах и получаем очень разные результаты между производственными серверами и тестовыми серверами.

тестов мы делаем следующий:

• Загрузить XML RSS Feed доступно на сайте
• Сделать запрос ГОЛОВЫ всех ссылок, присутствующий на в корм XML, чтобы проверить, если URL правильно

Удовлетворительно среднее время отклика на тестовых серверах составляет около 15 мс, когда одно и то же измерение считывает 900 мс на серверах prod. Поскольку оба сервера (предположительно) настроены одинаково, я очень озадачен этими результатами.

1. Я правильно понял, что HEAD-запросы на .CFM-страницы фактически не связаны с сервером ColdFusion, а только с IIS?
2. Если я прав с первой точкой, где я могу проверить уровень IIS, что может повлиять на время ответа?

Следуя рекомендациям, которые я получил от вас, я просто попытался добавить запись журнала на тестовую страницу cfm, чтобы узнать, выполняется ли CFLog или нет.

Удивительно, что тот же запрос HEAD в том же файле генерирует запись журнала в prod. и не в тесте. Очевидно, что конфигурация должна быть разной между тестом и prod, но я не знаю, на каком уровне.

Answer 1

Я не знал ответа на этот вопрос, но я сбил код, чтобы проверить его и получить некоторые результаты. Caveat: Я использую только внутренний веб-сервер Tomcat, и я использую CF10 (я отмечаю, что вы используете CF8). Я не думаю, что их оговорки недействительны мои выводы в контексте вашей конкретной ситуации.

<!--- headMe.cfm ---> 
<cflog text="hit" file="headMe"> 


<!--- doHead.cfm ---> 
<cfhttp method="head" url="http://localhost/headMe.cfm" result="httpResponse" /> 
<cfdump var="#variables#"> 

Так я просматриваю к doHead.cfm, что делает HTTP глава headMe.cfm. Если headMe.cfm был фактически выполнен, тогда мы получим запись в headMe.log. Если нет: нет записи в журнале.

Переменная httpResponse была законна и, как и следовало ожидать, для запроса HEAD и ... Я получил запись в журнале.

Итак, я пришел к выводу, что при получении запроса HEAD, к сожалению, все CFML фактически выполняются. Я действительно не думаю, что это должно быть. В спецификации HTTP нет ничего, чтобы предположить, что он должен или не должен вызывать «динамические» запросы для полного выполнения, но было бы неплохо, если бы этого не произошло, я думаю.

В любом случае, HTH.

Answer 2

Ваше первое предположение неверно. Ответ на запрос HEAD должен быть закодирован и не обрабатываться автоматически. A HEAD запрос должен отвечать идентичной информацией заголовка как запрос GET, что обычно означает выполнение того же кода, что и запрос GET, а затем опускающий тело сообщения в ответе.

От the HTTP spec, section 9.4:

Метод ГОЛОВА идентичен GET, за исключением, что сервер НЕ ДОЛЖЕН возвращение тела сообщения в ответе.Метаинформация, содержащая в заголовках HTTP в ответ на запрос HEAD, ДОЛЖНА быть идентичной информации, отправленной в ответ на запрос GET. Этот метод может использоваться для получения метаинформации об объекте, подразумеваемой запросом , без передачи самого объекта-объекта. Этот метод часто используется для тестирования гипертекстовых ссылок на достоверность, доступность, и недавнюю модификацию.

Ответ на запрос HEAD МОЖЕТ быть кэшируемым в том смысле, что информация, содержащаяся в ответе, может использоваться для обновления ранее кэшированного объекта с этого ресурса. Если значения нового поля показывают, что кешированный объект отличается от текущего объекта (поскольку будет отображаться изменением Content-Length, Content-MD5, ETag или Last-Modified), то кеш ДОЛЖЕН обрабатывать запись в кеше как устаревший.

Я думаю, что очень редко можно увидеть динамические сайты, CMSs или структуры, которые на самом деле реализовать большинство вещей, как HEAD ответы, действительный ETags и т.д. - так вообще вы получите одинаковые ответы от GET и HEAD, включая тело сообщения, которое предполагается удалить из запроса HEAD.

Я предполагаю, что то, что вы испытываете в разнице во времени, связано с различиями в содержании между серверами. То есть тестовый сервер может иметь только минимальный контент и, следовательно, выполняется быстрее, чем полные серверы создания контента.