Как заставить apache+nginx отдавать контент клиенту?

В первую очередь апач не отдаст этот результат - он ждет пока весь скрипт выполнится. На уровне nginx отключи сжатие, на уровне php - всякие буферы. Хотя точно не скажу - это из серии «сделал и забыл»

Так отож...

Поясню. Предположим страница магазина, на ней 50 товаров и «умный фильтр» (типа яндексовского, когда ты допустим отмечаешь какое-то свойство и сразу же становятся не активными другие свойства которых нет у оставшихся товаров.

Этот фильтр расчитывается не очень быстро и генерит прилично запросов. Вместе с тем, он нафиг не нужен в начале загрузки страницы - клиент же еще не увидел списка товаров. Поэтому задержка в его показе, не сильно важна. Можно бы было выбросить клиенту страницу с товарами, и пусть бы браузер рендерил, подгружал картинки, а мы бы пока считали фильтр.

Обычно такое делается ajax'ом. Но это тоже не гуд - это же еще один запрос + еще один запуск фреймворка + еще одна выборка товаров по уже устанавленному фильтру (мы бы ее не делали - мы же сделали ее уже для страницы). Короче ajax снимает только проблему быстрой отдачи, а нагрузку на сервер не снижает (((

Поэтому вот захотелась такая фигня.

50 товаров

Копейки же

и пусть бы браузер рендерил

Т.е. подстраивать разметку во вьюхе под оптимизацию? Типа фильтр ниже на странице? А если завтра дызайнер нарисует фильтр сверху?

Обычно такое делается ajax'ом, а нагрузку на сервер не снижает

Ну не могу поверить чтобы на 50 товаров БД начинала пыхтеть. И сколько ж там запросов? 300? 500? Вангую что можно уместиться в 4-7 запросов на весь твой умный фильтр, если конечно структура таблиц нормальная, и все это будет быстренько отдаваться.

Nginx на фронте, апач за ним

Ну да, если бы просто апач, то еще ладно - можно флашить (flush), но если он под проксей то хз как оно себя ведет, будет ли флашить? Предполагаю нжинкс будет отдавать равными кусками, а не так как ты зафлашишь. А еще не все браузеры флаш хавают (кажись хромой и хромает в этом месте).

Так-что лучше алгоритмы свои оптимизируй, а не костыли придумывай.

Копейки же

Ты предлагаешь вывалить на страницу все over9000?

Т.е. подстраивать разметку во вьюхе под оптимизацию? Типа фильтр ниже на странице? А если завтра дызайнер нарисует фильтр сверху?

Ну и что? Мы покажем вместо него картинку, его подгрузим в скрытый div винзу страницы, а потом js'ом переставим на положенное место.

Ну не могу поверить чтобы на 50 товаров БД начинала пыхтеть.

50 на одной странице

И сколько ж там запросов? 300? 500?

Примерно в 100 раз больше

Вангую что можно уместиться в 4-7 запросов на весь твой умный фильтр

Не мой, а битриксовский.

если конечно структура таблиц нормальная, и все это будет быстренько отдаваться.

Структура нормальная. API в данном месте больной.

Но с фильтром я проблему давно решил другим способом (пропатчил ядро битрикса, здоровым API и запретил обновляться). Просто привел для примера случай. У меня на самом деле сейчас несколько другое, гораздо более сложное в описании, но смысл тот же - можно посчитать отдав 90% контента...

все over9000?

С чего вдруг все? Ты думаешь БД по все пробегает? Если лимит стоит то остановится когда найдет все что нужно. Еще и закеширует и при повторном запросе будет уже шустрее.

а потом js'ом переставим на положенное место

Ну да - решать серверную проблему на клиенте, костылище же.

битрикс

Ну так бы сразу и сказал.. Не завидую. А что он не умеет кастомные запросы делать? Или другая задача уже не про битрикс?

С чего вдруг все? Ты думаешь БД по все пробегает?

Для фильтра нужно достать все.

Ну да - решать серверную проблему на клиенте, костылище же.

Web костылен by design - с этим уже ничего не поделаешь.

А что он не умеет кастомные запросы делать?

Да можно сделать - какие вопросы. Только в обход API - не гоже это - совместимость нарушается. Завтра клиент сам что-то поменяет или необдуманно обновит и все развалится...

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

Для фильтра нужно достать все

Если нужно показать «нашлось N совпадений» то пусть БД и возвращает этот N. А сами товары уже с лимитом выдавать.

Web костылен by design

Так зачем его еще больше закостыливать?

Завтра клиент сам что-то поменяет или необдуманно обновит

А ты ему скажи что сюда и сюда не лезь. Если залезет - сам будет виноват, а ты чист - предупреждал же его.

подумалось на ночь глядя вернуться к старой идеи

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

Если нужно показать «нашлось N совпадений» то пусть БД и возвращает этот N. А сами товары уже с лимитом выдавать.

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

А что до задачи вообще - ну сделай как получается.

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

И да - костыль это ждать завершения всего скрипта чтобы показать результат который уже давно можно бы было показать.

В этом костыле тоже есть свои плюсы, например - у меня есть скрипт, который логинит пользователя, после логина и подгрузки нужных данных в куки редиректом в хедере пользователя перенаправляет на другую страницу. Во время этой операции на странице может крутиться какой-нибудь лоадер или надпись показываться что «сейчас все сделаем и перенаправим». Если я отдам эту надпись, потом скрипт отработает и отдаст хедер пользователь никуда не перейдет. Так что тут тоже нужно смотреть с той стороны, не повредит ли отключение этой фичи функционалу.

Разумеется. Но в том и смысл, что фича должна быть управляемой.

Офтопим

Дай примерную структуру таблиц