По ссылке видна та же проблема - вы некорректно ставите вопрос и сами путаетесь при этом. Собственно ничего в этом треде нового, по сравнению с тем что написал Вам я - нет.
Если у вас страница полностью приезжает за 10 секунд, а у другого человека на быстром канале за 2, то это время можно описать формулой:
ВремяОжиданияЧеловекаВБраузере = ВремяОтсылкиДанных + ВремяОбработкиДанных + ВремяВозвратаОтвета.
Естественно, что ВремяОтсылкиДанных можно не рассматривать из-за очень малого объема данных в запросе (обычно). Время обработки данных на сервере будет одинаковое для Вас и Второго человека что бы тут Вам не писали. ВремяВозвратаОтвета у Вас будет =КоличествоКилобайтВОтвете/СкоростьПередачиДанных.
Естественно, что если Вы увеличиваете количество выдаваемых сервером данных, то и общее время ожидания будет увеличиваться пропорционально. Поэтому если у вас канал на 64Кбит/сек, а у вашего приятеля 1024Кбит/сек, то при объеме страницы в 320Кб у Вас она будет грузиться 40 секунд, а у Вашего приятеля 2.5 секунды.
Если Вы увеличите размер страницы до 720Кб, то у Вас она будет грузиться уже 80 секунд, а у него - 5. Он просто не заметит разницы. Это должно быть очевидно даже школьнику, высшего образования для этого не нужно.
Если же Вы замерите время генерации страницы, то оно будет одинаковым на любой скорости связи.
Послушайте, не путайте людей, и так тут у многих каша в голове из-за нежелания разбираться в деталях. Даже при таком понимании времени генерации страницы процесс её создания НИКАК НЕ СВЯЗАН С ЕЁ ВЫВОДОМ. Вообще. Мясорубка будет молоть мясо с одной и той же скоростью независимо от того, будет фарш из-под нее уезжать в кастрюлю или он будет там скапливаться. Вот и все.
Возьмите и почитайте как реализованы веб-приложения на системном уровне, а то пишете какую-то ересь прикрываясь умными словами типа "паттерн" и "транзакция". Или напишите свое приложение такого плана хотя бы раз. Тогда никаких теоретизирований на пустом месте не будет.
Я из дискуссии на эту тему выхожу, надоело доказывать очевидные вещи.
Вы неправы в корне, перечитайте мой пост еще раз. Время генерации страницы - это время от совершения запроса к серверу до конца его ответа. Время на транзакции в БД туда входят. И время на транзакции к БД никак не зависит вообще от способа вывода данных, см. пост выше.
Существенно никак не отличаются по реализации. Просто в одном случае цикл вывода в сокет запускается сразу и умеет ждать сигнала об окончании потока, в другом - запускается по сигналу и ничего не ждет кроме факта опустошения буфера.
Про gzip - я не спорил о методах реализации, у нас в системе все так и сделано как вы перечислили за исключением третьего пункта - он не нужен. Просто я сказал что gzip может не спасти, если клиенты его не понимают. А в остальном возражений нет.
Вообще-то эта строка обычно сервером самостоятельно генерируется. Принудительно её делать нужно в особых случаях, если переопределяются все заголовки (для CMS обычно так делается) или если переопределяются некоторые заголовки но имеем дело с IIS у которого не выставлен один хитрый флажок в реестре, из-за чего он лепит свои заголовки и принудительно ставит свой перенос строки после них.
А как же фотографии? :). У меня вообще все собранные рецепты как правило единым текстом "приготовление", ингридиенты там по ходу вписаны. Иногда удобно, иногда - нет.
Эээ.... такой простой вопрос, а поставил меня в тупик. Ну вообще-то я не задумывался особо. Просто собеседник, а кем Вы по профессии (должности, призванию) - как бы все равно, поскольку в каком-то конкретном треде каждый занимает свою позицию по убеждениям и аргументирует ее с позиции своих умений и навыков. В этом треде Вы выступаете как представитель компании-партнера битрикса (или частного лица что сути не меняет). В другом можете выступать как контент-менеджер. Если Вы реально занимаетесь и тем и другим - то и аргументация будет сильная и там и там.
Хотя я вряд ли открыл Америку.
Немного не так. Когда приходит запрос на сервер там пишется в заголовке Accept-Encoding, что типа я клиент умный, gzip понимать умею. Сервер в зависимости от своих возможностей может отдать gzip (пометив заголовком Content-Encoding что контент пожатый), а может отдать и просто plain/html.
То есть примерно так -
Берем текстовой редактор, типа MSWord где удобно набить тексты и их прокатать через проверку орфографии и пунктуации. Набиваем полную директорию файлов называя их стандартизированным образом, поскольку разбирать тело документа, которое будет содержать тайтлы или другие признаки - лишнее. Пишем VBScript (или еще что-то подобное) для перегона всего этого безобразия в CSV формат и импортируем в битрикс.
Ключевой вопрос: зачем тут тогда нужен хваленый битрикс, если ВСЕ УПРАВЛЕНИЕ КОНТЕНТОМ ВНЕ СИСТЕМЫ. Таким образом можно использовать ЛЮБУЮ CMS, поддерживающую импорт из CSV в каталог.
Именно об этих радостях жизни думает контент-менеджер, он же иногда и владелец сайта. А разработчик системы управления и внедренец думает об этом редко. А должно быть все НАОБОРОТ.
"Поллитра воды это бутылка воды из-под поллитровой водки" - шедевр.
С детства убивал меня вопрос - а 200 грамм это по полосочку или полный до краев граненый стакан?
Набивать тексты в Экселе любой человек будет только от безысходности.
О чем и речь.
