Модератор
Yui
(@fierevere)
永子
на статьях по оптимизации WordPress не одну клавиатуру сломали.
Нужно масштабироваться? Ну так вперед, *.wordpress.org все сайты по сути масштабированы на одну базу и являются сетью сайтов, думаете что у вас будет посещений больше?
А вообще проблемы стоит решать по мере их поступления.
Это верно, я хочу, немного за ранее, понять что нужно будет делать, в случае такого поворота событий. Думаю для начала как-то сделать загрузку картинок к примеру на другой домен, который бы работал только хранил и отдавал картинки. Уже будет хоть какае-то разгрузка ?
Модератор
Yui
(@fierevere)
永子
это смотря что разгружать, если у вас сайт занимается в основном тем, что отдает медиа-контент, то CDN это ваш первый выбор. И самый простой.
Чуть сложнее будет разнести PHP и обеспечить общий обьектный кеш, потому что заниматься шардингом БД будет еще чуть сложнее
- ну, во первых нагрузка не на сайт, а на хостинг/сервер…
- грубо, основных источников нагрузки в общем-то два. а) нагрузка на процессоры сервера из-за динамического формирования страниц, б) нагрузка на память сервера, забиваемую очередью запросов на отрисовку страниц из-за, обычно, относительно медленной работы базы данных и соответственно большой очереди запросов к ней.
- соответственно и борьба с нагрузкой сводится к нескольким относительно простым приемам: а) в первую голову страничный кэш, снимающий очередь запросов к базе и нагрузку на процессоры, б)межстраничный объектовый кэш, частично снимающий очередь запросов к базе, когда страничный кэш пустой, но есть общие для страниц объекты.
- ну можно еще добавить кэш браузера пользователя, но он больше важен для многостраничных посещений сайта
При грамотной настройке этих компонент с помощью одного-двух стандартных плагинов, на виртуальном сервере с апачем, скажем, 8х8, сайт на wordpress вполне держит 1M просмотров страниц в сутки. Шаред хостинги обычно не выделяют такой объем ресурсов.
на всякие CDN и «современные форматы изображений» не ведитесь, пустая трата времени, особенно в РФ.
Я про CDN читал, он мне не подходит, так как расчёт на пользователей только одной страны.
По этому как вариант для картинок, купить отдельный под них «сервер» и заливать их туда, они же им и будут отдаваться, по типу img.site.com я просто как-то видел, когда проект один начинающий именно так и начал делать, перенес загрузку из главного сервера, на отдельный.
Конечно всё это интересно, но, как ту выше сказали, нужно решать по мере поступление проблемы.
На счет обьектного кэша ничего не понял, о кэше читал, использовал для статики wp super cache кажется, вполне на сколько я помню работал нормально.
насчет объектного, по сравнению со статикой… ну вот заходит пользователь на страницу, у нее генерится html код, со срабатыванием всех плагинов и темы, с их десятками обращений к базе, выдается посетителю и кладется на диск. следующему посетителю той же страницы выдается практически сразу html код с диска.
но хорошо, когда страниц мало, они нечасто изменяются, и по этой причине спокойно себе лежат на диске из расчета 100-500 кб на страницу днями и месяцами. а если сайт содержит, например, под сотню тысяч страниц или они обновляются несколько раз в час или на сервере тупо нет места под нужный кэш…. тогда большое количество посетителей получает динамические версии страниц.
с другой стороны, каждая страница содержит, к примеру, общее для сайта меню. пользуем это меню как объект, кладем в объектовый кэш на десяток секунд, и вот уже на «соседней» странице меню уже не генерится динамически с десятком запросов к базе, а выдается готовой структурой данных.
Понял, ложить статику в кэш, т.е то что не меняется, чтобы это потом не генерировалось
Модератор
Yui
(@fierevere)
永子
CDN это вынос медиа-контента за пределы хостинг сервера, иногда это может быть даже тот же хостинг-провайдер с отдельным сервером для статики. Заниматься этим стоит только если у вас сайт с кучей фото или видео, т.е. как я уже упомянула, медиа-контент составляет значительный обьем трафика сайта. Делать так называемый шардинг медиа у себя нет смысла (img.site.x) возни много, а выигрыш — 3 копейки. Если используется HTTP/2 протокол, а на всех сайтах с https:// он сейчас должен использоваться, то тем более нет смысла в мышиной возне.
На кеш я бы смотрела более скептически, не каждый сайт кешируется в статику, если он очень динамичен, кажется я что-то видела про доску обьявлений? или интернет-магазин, то эффективность кеша страниц стремится в ноль. Если сайт новостной — да, страничный кеш это прекрасно. Опять же время кеша сутками и месяцами — это дело бредовое, представьте что у вас есть панель с виджетами, динамическими, они не будут обновляться месяцами. Статические страницы на новостных сайтах и блогах с коротким (менее часа) временем жизни кеша — мне нравится такой вариант. Но опять же стоит смотреть специфику сайта. Кеш страниц — не панацея.
Кеш объектов — must have. На любом сайте. Особенно если страничный кеш плох (магазины, доски обьявлений). При наличии возможности. Redis.
Опять же мало какой шаред хостинг дает нормальные _возможности_. Если есть знания и умения — VPS и изящество ходить но граблям, хотя сейчас и на шаблонных панельках управления можно добиться многого.
(img.site.x) возни много, а выигрыш — 3 копейки
Почитал немного о hightload — как я понял, если делать что-то серьёзное что лучше это делать на своих собственных VPS. Это что касается отдачи статики и разгрузкой БД.
А вот за обьектный кэш — хорошо подсказали, читаю буду вникать
На счёт страниц магазина, к примеру, почему это статика так себе ? К примеру страницы товаров размещаются раз и потом редко изменяются, чем не статика ? Конечно нужно будет потом разобраться что и как будет отдаваться, где он нужен, а где нет.
Модератор
Yui
(@fierevere)
永子
магазин = залогиненный пользователь/отслеживание корзины.
реализовать выдачу полностью кешированных страниц тут будет сложно.
Думаю как-то реализовать можно для logged и нет, но опять же, это будет трудно отслеживать да и если что-то пойдёт не так в общем затея так себе — это точно. Если что, начну с базовой оптимизации и рекомендаций, закинуть на отдельный VPS хотя бы медиа контент, уже часть нагрузки будет снята.
Я помню как то давно, находил одно видео, где продвинутые админы, как я понял, тестили wordpress посещалку на одном из средних VPS серверов, было интересно, правда детали кроме как статы в аналитике типа 450 онлайн или что-то вроде этого мне вполне хватило, там смысл был показать как оптимизировать чтобы wp вытягивал даже на средних впс чуть больше
закинуть на отдельный VPS хотя бы медиа контент, уже часть нагрузки будет снята.
да нет там никакой нагрузки — апач запрос получил — файл отдал, та же статика, даже меньше, потому что без движка. если прокси стоит, дак вообще… lazy load на порядок полезней
магазин = залогиненный пользователь/отслеживание корзины.
ну да, ну да… там до логина как до луны, основной трафик зеваки создают. ну и во фрагментный статический кэш поиграться никто не мешает.
Как это нет ?
Может повторюсь, я просто видел как один подобный проект сделал в точке когда видать один сервер не выдерживал, они просто картинки и вообще всю статику перекинули на отдельный сервер, т.е в сурсах на сайте можно было увидеть типа img.site.com/…/imgage.jpg
Почему до логина как до луны ? Ну, тут не совсем верно, если реализовать разностороннюю регистрацию, то будет достаточно пару кликов..
Модератор
Yui
(@fierevere)
永子
да нет там никакой нагрузки — апач запрос получил — файл отдал, та же статика, даже меньше, потому что без движка. если прокси стоит, дак вообще… lazy load на порядок полезней
очень дорого через апач отдавать файлы статики, ладно сейчас оптимизировали PHP и сам апач, стало чуть полегче, араньше на каждый запрос грузился httpd, все его модули и mod_php
отдавать статику надо через nginx, пусть даже как прокси к апачу
