Comments 34
Почему аватарки нельзя кешировать?
Есть данные по скорости отрисовки страницы при таком подходе? Например, на сотне картинок.
Есть данные по скорости отрисовки страницы при таком подходе? Например, на сотне картинок.
А почему бы на сервере не собирать из аватарок спрайт?
А если пользователей 100500?
Ну тут можно ход конем: форумы обычно постраничные, т.е. на странице 10-50 постов, в большинстве случаев с меньшим количество уникальных аватар. А значит, теоретически, можно создавать спрайты для популярных страниц, или даже веток обсуждения.
Ну или создавать спрайты самых активных/популярных юзеров/аватар…
Ну или создавать спрайты самых активных/популярных юзеров/аватар…
> Таким образом мы на порядок снижаем количество запросов к серверу, а значит повышаем стойкость сайта к DDoS-атакам
Я пропустил тот день, когда боты стали массово грузить еще и графику?
Идея интересная, но вся статья полна какой-то чуши, которую вы как-то уверенно так подаете. Например, с какого это перепугу блочная верстка вдруг заставляет браузер интенсивнее «бомбить» сервер запросами на отдачу мелкой фигни? Что за особенности стриминга текстовых данных? gzip что ли?
Как итог, вы перевесили всю тяжесть с клиента на сервер. К вам пришло разом, скажем, 100 человек. 100 одновременных PHP-процессов (дай бог, чтобы вы при этом не уперлись в лимит) из базы (нахрена здесь база?) собирают base64 в один огромный JSON-массив. Клиенты по-прежнему ждут, но уже не потому, что дохрена «мелкой фигни», а потому что дохрена тяжелых коннектов у сайта.
Если хотите немного ускорить отдачу статики, используйте, например, шардинг файлов на несколько доменов: www.stevesouders.com/blog/2009/05/12/sharding-dominant-domains/
Я пропустил тот день, когда боты стали массово грузить еще и графику?
Идея интересная, но вся статья полна какой-то чуши, которую вы как-то уверенно так подаете. Например, с какого это перепугу блочная верстка вдруг заставляет браузер интенсивнее «бомбить» сервер запросами на отдачу мелкой фигни? Что за особенности стриминга текстовых данных? gzip что ли?
Как итог, вы перевесили всю тяжесть с клиента на сервер. К вам пришло разом, скажем, 100 человек. 100 одновременных PHP-процессов (дай бог, чтобы вы при этом не уперлись в лимит) из базы (нахрена здесь база?) собирают base64 в один огромный JSON-массив. Клиенты по-прежнему ждут, но уже не потому, что дохрена «мелкой фигни», а потому что дохрена тяжелых коннектов у сайта.
Если хотите немного ускорить отдачу статики, используйте, например, шардинг файлов на несколько доменов: www.stevesouders.com/blog/2009/05/12/sharding-dominant-domains/
К вам пришло разом, скажем, 100 человек. 100 одновременных PHP-процессов (дай бог, чтобы вы при этом не уперлись в лимит) из базы (нахрена здесь база?) собирают base64 в один огромный JSON-массив.
Ну с этим-то проблем как раз нет — можно кешировать выдачу сервлета в memcached и отдавать всё это через nginx например.
Да, но в таком случае количество возможных ключей будет равняться x^n, где x — кол-во различных ID картинок, а n — кол-во мест их размещения на странице (если речь про один лейаут). Иными словами, это все возможные вариации одновременного появления n картинок из числа x. Даже для 100 картинок на 10 мест это уже нереальное количество. Другого варианта стандартный модуль memcached в nginx вам не предоставит.
Если же вы хотите прямо в nginx разбирать запрос на отдельные ID, лезти в кэш и склеивать все полученные данные (плюс, получать отсутствующие другим путем) и отдавать json, то я с удовольствием посмотрю на этот конфиг :) Perl, Lua?
Если же вы хотите прямо в nginx разбирать запрос на отдельные ID, лезти в кэш и склеивать все полученные данные (плюс, получать отсутствующие другим путем) и отдавать json, то я с удовольствием посмотрю на этот конфиг :) Perl, Lua?
Что-то я под утро плохо соображаю. Почему 100 картинок на 10 мест?
У нас есть лента новостей. Скажем из 20 блоков. Каждый блок это картика + текст со ссылкой. Страница запрашивает 20 картинок соответственно. Все 20 картинок собираются в одну JSON-стороку, которая и кешируется. Следующая страница — ещё 20 картинок ещё одним куском.
При изменении (при добавлении новости) страницы JSON в кеше пересобирается бэкендом принудительно.
У нас есть лента новостей. Скажем из 20 блоков. Каждый блок это картика + текст со ссылкой. Страница запрашивает 20 картинок соответственно. Все 20 картинок собираются в одну JSON-стороку, которая и кешируется. Следующая страница — ещё 20 картинок ещё одним куском.
При изменении (при добавлении новости) страницы JSON в кеше пересобирается бэкендом принудительно.
1) Почему «крафики»?
2)
Что вы имеете ввиду..?
2)
Особенно учитывая особенности блочной вёрстки, которая в отличие от табличной заставляет браузер интенсивнее «бомбить» сервер запросами на отдачу мелкой фигни
Что вы имеете ввиду..?
В итоге имеем невалидную вёрстку и идущих лесом посетителей с отключенным JS.
Да и само решение, если честно, весьма сомнительно.
Да и само решение, если честно, весьма сомнительно.
...WHERE ROWID IN (".trim($_GET['q']).") LIMIT 20...Вы бы так не делали.
По-моему, современные браузеры и серверы поддерживают атрибут
В итоге браузер создаёт всего один коннект и делает сразу десятки запросов к серверу.
Connection: keep-alive для подобной «мелюзги».В итоге браузер создаёт всего один коннект и делает сразу десятки запросов к серверу.
А что делать пользователям с медленным интернетом и отключенными изображениями? При таком подходе они их получат принудительно и не будут этому рады
Connection: keep-aliveрешает проблему только частично — пока текущая картинка не пришла, следующую запросить нельзя. По-хорошему надо использовать атласы: www.altdevblogaday.com/2012/09/17/building-an-html5-game-dont-shrug-off-atlases/
Вот как это прописать в css: css-tricks.com/css-sprites/
Если я правильно понял, то при вашем подходе поисковики не увидят кучу картинок на вашей странице что отрицательно скажется на трафике из поиска картинок (естественно, alt-ы у вас должны быть прописаны корректно).
Топ-10 советов о том, как увеличить скорость загрузки страницы
habrahabr.ru/post/137239/
1. Уменьшите количество HTTP-запросов…
habrahabr.ru/post/137239/
1. Уменьшите количество HTTP-запросов…
У меня вопрос, а почему нельзя эти картинки сразу отдавать в base64 в теле страницы? Если уж мы всеравно рассматриваем вариант хранить их в базе?
Я просто оставлю это здесь: ru.wikipedia.org/wiki/SPDY
Гугл в поиске по изображениям иногда отдает картинки через data:image.
Может кто сталкивался: зачем и как такое реализовать?
Может кто сталкивался: зачем и как такое реализовать?
Вроде ж современные браузеры не делают больше 6-8 коннектов на домен. Если keep-alive включить, то очень неплохо и так будет отдаваться, по 6 штук параллельно. К тому же у меня есть подозрение, что браузеры не в случайном порядке картинки подгружают, а сначала те, что помещаются на экран, а потом уже те, что есть на странице, но в данный момент пользователю не видны.
Имхо запихать все в css намного проще
изначально в css лежат ссылки, скрипт-склейщик, собирая общий css подставляет вместо ссылок сами картинки, потом все зипуется и отдается в один поток
изначально в css лежат ссылки, скрипт-склейщик, собирая общий css подставляет вместо ссылок сами картинки, потом все зипуется и отдается в один поток
А как насчёт
<img width="..." alt="..." src=«data:image/gif;base64,......» />
?
<img width="..." alt="..." src=«data:image/gif;base64,......» />
?
Sign up to leave a comment.
Отдача мелкой графики