Про H - да, зеркальщик, но по мне они все краулеры, собственно я употребил "индексатор" в этом смысле. А зачем ему убеждаться в том, что страница отдается и так и так - это интересно.
Сейчас посмотрел логи более тщательно:
- блоггерный индексатор (короче чтобы не путать людей - вот этот: YandexBlog/0.99.101 (compatible; DOS3.30; Mozilla/5.0; B; robot)) ест страницы периодически в сжатом виде, периодически не в сжатом.
- I бот - индексатор - тоже ест и так и так, но последовательного забора как у зеркальщика - действительно нет.
Разработчики говорят что если боты просят gzip - то так и нужно им gzip отдавать.
Браузер выдает свое сообщение "Невозможно отобразить страницу..." в случае, если приезжает пустой контент и заголовок содержит код возврата 404, или вообще ничего не приезжает. Если заголовок содержит код 404, но контент не пустой, то браузер считает, что страница содержит сообщение со смыслом "Такой страницы нету", сгенерированное на серверной стороне и спокойно показывает содержимое страницы. А что уж там в странице - нормальный контент выдается или сообщение об ошибке типа http://www.twl.ru/404 или http://yandex.ru/dgfdg - это уже не его дело.
Lisa, разница понятна но я решительно против специального обучения в какой-бы то ни было форме (без необходимости!). Мой посыл очень прост - Вы читали хэлп к Ворду или Вас кто-то ему обучал для того чтобы начать использовать примерно 30% самых частоиспользуемых функций? А продукт то на порядок посложнее будет. И потому я не вижу ни одной реальной причины чтобы обучать клиента простейшим и самым частоупотребимым функциям.
Изучить как пользовать можно все что угодно, если припрет, даже PCAD будь он неладен со своим интерфейсом. Но хоть убейте я не считаю ни интерфейс Битрикса, ни интерфейс Неткета интуитивно понятными и логично выстроенными. Поэтому я тут не ратую ни за "красных" ни за "большевиков". Это системы для программеров, созданные программерами. End-user же, к сожалению, unfriendly.
Ну, никому, конечно не должен :). Но Майкрософт рекомендует кэширование для увеличения производительности в целом. У меня также Activestate Perl под IIS и естественно кэш написан свой. В любом случае, даже если 10-50 генераций страницы избежать - это может быть приличной экономией по производительности, в зависимости от нагрузки на скрипт. "Перекэшировать" 10К страниц не нужно - Вы можете писать в кэш страницы по мере их генерации, что тут сложного? Гемора никакого тоже вроде нет, простой кэш пишется за полчаса с отладкой.
Кстати, если у Вас приложение частно обновляет страницы, то вероятно обновление затрагивает не всю страницу а только определенные части. Так что наверняка есть возможность применять блочное кэширование.
В общем каждый сам решает, что ему выгоднее - кто-то софт оптимизирует, а кто-то просто мощнее железку ставит. Впрочем от основной темы топика мы ушли куда-то в сторону.
Вы чего это такое написали? Причем тут вообще транзакция в БД и вывод готовых данных в порт? Это же не мясорубка Вам, чтобы пока фарш из шнека не вышел нельзя было мясо запихать в неё.
Генерация страницы это ОТДЕЛЬНАЯ вещь, которая зависит от скорости работы процедур в БД и скорости работы скриптов. Все. Точка. Никак с каналом и тем более с моделью вывода это дело не связано вообще.
Небуферизированный вывод тоже имеет свой буфер. Продолжим пример с мясорубкой:
Имеем мясорубку (приложение) и конвейерную ленту (канал), на которую падает фарш (данные). Конвейерная лента ссыпает готовый фарш в кастрюлю (браузер клиента).
БУФЕРИЗИРОВАННЫЙ ВЫВОД
Конвейер стоит. Мясорубка молотит мясо. По окончании перемалывания лента включается и ГОРКА фарша едет к кастрюле куда и высыпается. Не мгновенно высыпается, но быстро. Имеем задержку между началом перемалывания и началом поступления фарша в кастрюлю равную времени приготовления фарша (времени работы мясорубки). Итого время получения последнего байта данных (TTLB) на клиенте будет равно времени работы скриптов (мясорубки) + времени доставки всех данных.
НЕБУФЕРИЗИРОВАННЫЙ ВЫВОД
Мясорубка рубит фарш, конвейер включается СРАЗУ по попаданию фарша на него. Таким образом фарш попадает в кастрюлю постепенно, то есть первые кусочки фарша попадут в кастрюлю раньше чем при буферизированном выводе. Но время прихода остатков фарша будет ТАКИМ ЖЕ.
То есть другими словами НЕБУФЕРИЗИРОВАННЫЙ вывод только уменьшает время ожидания первого байта клиентом. Если файл большой, то он будет отображаться "постепенно", по мере генерации контента на серверной стороне. А при буферизированном - все и сразу после задержки.
Про GZIP - проблему с объемом надежно так решить нельзя, т.к. далеко не все клиенты поддерживают gzip сжатие, несмотря на заявления производителей (из личной статистики).
Это не принадлежность Апача, хотя я не уверен что в его настройках нельзя это включить/выключить. В Perl достаточно выставить строку $|=1 чтобы выдача была небуферизированной. Поищите поиском.
Вообще, я бы посоветовал как-то более системно подойти к решению задачи, а то Вы мечетесь из угла в угол. Может быть стоит что-то почитать из теории?
Про интуитивность интерфейса Битрикса не нужно только сказок. Все попытки клиентов самостоятельно разобраться в описанной операции без хелпа обычно кончаются неудачей, причем об этом пишут достаточно часто и приводят как пример безграмотного построения интерфейса.
У нас тоже не статических страниц, какая разница? Кэш все равно должен быть.
Ты не понял, я написал выше что именно так и сделали, потому как иначе сделать как - не знаю.
Тоже верно. Хотя лично я был против в свое время создания своего велосипеда. Но вышло так, что другой альтернативны на тот момент не было. Сейчас мы бы ни за что этого делать не стали - есть ряд уже развитых продуктов и просто коммерчески оправданнее использовать их.
Цены немного задраны искуственно, нам невыгодно заниматься интеграцией самим, это семечки а не бизнес. Вроде бы нет проблем интегрировать все самостоятельно, у нас даже ребята из РПЦ сами себе сайты собирают (http://www.theepiphany.ru/) - вполне себе хорошо получается.
Я не видел пока своё логирование не прикрутил. В стандартных логах IIS я не уверен что логируется тип передаваемого контента, по-моему там нельзя этот параметр увидеть.
