vinoff

Как сделать сайт на WordPress с высокой производительностью?

Вначале необходимо определить, что такое "высокая производительность". Обычно, под производительностью сервера (WP сайт это как раз тот самый сервер) подразумевается показатель RPS (Requests Per Second) - максимальное количество запросов к серверу в секунду. Именно максимальное, т.е. в какой то "час-пик". Предположим, что сайты на WP обычно используют небольшие, ну максимум средние компании, с соответствующим ожиданием по нагрузке в своем сегменте.

Возьмем голую тему без плагинов, которая выводит 10 изображений, с подключением 5 статических файлов (css/js), итого около 20 запросов от одного не кэшированного визита посетителя. Если на наш сайт зайдут 5 посетителей в секунду, они сгенерируют 100 RPS (5 * 20). Может показаться, что 5 визитов в секунду - это мало, но в минуту это будет уже 300 визитов, а в час 18000 визитов, что как бы дохрена, для малого-среднего бизнеса. Повторюсь, речь идет про "час-пик", т.к. нагрузка в другой промежуток времени нас не интересует.

По моим наблюдениям, WP без проблем выдерживает 50-100 RPS на нормальном хостинге с начальным тарифом без кэширования.

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

Я придерживаюсь следующего плана оптимизации WP сайта, от простого к сложному:
1. Кэширование плагином - самое быстрое и относительно дешевое решение, гуглить WordPress caching plugins. Обычно, вместе с такими плагинами идет опция с оптимизацией изображения до .webp или .avif формата и оптимизацией css/js файлов, если же нет, то это должен быть следующим пунктом оптимизации. Например, для W3 Total Cache имеются плагины Smush и ShortPixel.
2. Хостинг - арендовать более производительный shared-хостинг и подключить CDN.
3. VDS/DS хостинг - переезд на производительный VDS/DS хостинг, настройка обратного прокси Nginx и перекладка на его плечи задачи кэширования. Иногда получается сделать так, что до WP вообще не доходит запросов, все отрабатывает Nginx (это идеальный сценарий, но не всегда выполнимый). Здесь можно снять несколько сотен-тысяч RPS, что уже очень прилично, для такого уровня сайтов.
4. Больше серверов - докупка VDS/DS серверов с балансировкой, либо руками, либо средствами хостера. Здесь можно снять ЕЩЕ несколько сотен-тысяч RPS дополнительно к п3. Обычно, такая производительность нужна каким то интернет-каталогам/магазинам.

Конечно, можно переписать саму тему с плагинами (написать с нуля), но не факт, что это будет дешевле и быстрее, чем пункты выше. Бизнесу вообще глубоко фиолетово, на чем написан инструмент (сайт), главное, чтобы он приносил деньги, стоил максимально дешево и мог быстро нарастить производительность под новую нишу, если это понадобится.

Ну и как уже сказали другие, elementor противоречит слову "производительность", хотя и его наличие можно на время закидать кэшированием-серверами-деньгами.

Рекомендую почитать:
WordPress Developer Resources - Optimization
The Ultimate Guide to Boost WordPress Speed & Perf...
Page Speed Optimization for WordPress

Как понять, где лучше использовать плагин, а где лучше разобраться и вставить код?
Какие плагины обязательны? А какие замедлят сайт?

Отслеживать производительность можно плагинами New Relic и Query Monitor, а тестировать нагрузку Load Impact и Apache Benchmark. Это поможет понять, где узкие места.

Видит. Телефон сообщает. И сам оператор слушает, есть ведь еще и обратный сигнал. Регулирует мощность передатчиков, исходя из общей картины. Приказывает абонентским устройствам сменить частоту или базовую станцию (если абонент видит несколько) исходя из собственных соображений и чувства оптимальности. Приказывает абонентскому устройству поднять или снизить мощность передатчика.

Примерно так: у БС есть 25 клиентов, из них 10 рядом, 10 далеко, а 5 ближе у другой БС, которая не перегружена.
Тогда логика будет такой:
- 10 ближайшим приказать перейти на одну (или несколько) общих частот. Снизить на этих частотах выходную мощность. Приказать абонентам понизить мощность своих передатчиков.
- 10 дальним - приказать перейти на другую (или несколько) частоты, и поднять на них свою мощность. А клиентам так же подрегулировать мощность их передетчиков вверх - до достижения уверенной слышимости на БС.
- 5 которые у другой БС - велеть переключится на другую БС и одну из ее частот.

Режим зануды:
1. Нанять амина / стать им.
2. Научится различать проблемы и не валить все в одну кучу.
3. Читать документацию по используемым технологиям.

По сути:
1. В одном сегменте сети должен быть только один DHCP сервер. В ограниченный случаях допустимо иметь несколько, но тогда они должны иметь непересекающиеся пулы адресов. Выключите все dhcp сервера, которые не планируете использовать.
Windows показывает какой dhcp сервер выдал ip адрес (ipconfig /all ) . Проверьте, совпадает ли это с вашими планами.

2. Пул адресов должен быть больше, чем число компьютеров, которые получают адрес по dhcp.
3. Если используются статические адреса, они не должны включаться в dhcp pool.

Проблема петель решается аудитом сети.
t1600-28ts это коммутатор, а не маршрутизатор.
Dlink 1016 —это неуправляемый коммутатор, а не hub.

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

175 (SMI Program fail count in worst die) - какое-то гигантское число, более 600 триллионов))

Используемая вами программа некорректно интерпретирует SMART.

Для SSD Intel атрибут 175 (AF / AFh) - это Power Loss Protection Failure.
Интерпретируется он вот так:
• Last test result as microseconds to discharge cap, saturates at max value. Also logs minutes since last test and lifetime number of tests.
— Raw value:
Bytes 0-1: Last test result as microseconds to discharge cap, saturates at max value. Test result expected in range 25 <= result <= 5000000, lower indicates specific error code.
Bytes 2-3: Minutes since last test, saturates at max value.
Bytes 4-5: Lifetime number of tests, not incremented on power cycle, saturates at max value.
— Normalized value:
Set to 1 on test failure or 11 if the capacitor has been tested in an excessive temperature condition, otherwise 100.

debconf: Fatal IO error 11 (Resourse temporarly unavailable) on X server :0

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

что теперь с ним делать: на помойку или как-то можно исправить

Можете подключить этот ССД другим SATA-кабелем к другой машине с Windows?

Вы ставите ОС, как я понимаю, важных данных на диске нет. Хорошо бы сделать сначала полный тест записи (уничтожит всю информацию), затем полный тест чтения (именно Read).
Это можно сделать в нашей программе для тестов (бесплатная, без установки), либо другой "не попсовой", которой вы доверяете.
В R.tester'e графики можно сделать максимально детальными, это даст хорошее представление о состоянии памяти.

Также можете показать S.M.A.R.T. целиком, если сомневаетесь в ещё каких-либо параметрах. Р.тестер это тоже умеет, к тому же мне было бы интересно посмотреть на его output для семейства DC S3500.

Очень жалко диск, если придется выбрасывать, вроде это довольно хорошая модель для серверных нужд...

Именно так.
ССД выглядит весьма стОящим, особенно на фоне китайщины и массовых моделей на дешёвой памяти. Да и Интел, как-никак.
DC S3700 был бы ещё лучше, из-за более высокого ресурса (DWPD / TBW), но и этот очень даже неплох.

Я полагаю, что такие магазины сохраняют всё, например в postgres или greenplum, а затем передают в аналитические базы (или пишут параллельно), типа в кликхаус или oracle?

XX век прошел под флагом реляционных СУБД. Вокруг них строились все системы.
Для любой банковской системы БД - абсолютная царица дизайна. Именно от нее шло
техническое задание. От базы а не от Хибернейта и синтетических таблиц как щас.
Таблицы любили. Вокруг них строили красивые теории. Модели. EAV. Подгоняли
аппарат алгебры (Эдгар Кодд со своими формочками).

В появлением NoSQL и стриминговых систем - пришлось всем признать что реляционка
исчерпала возможность линейного роста. У Майкла Стоунбрейкера есть статья где
он меряет БД под нагрузкой и доказывает что треть ресурсов CPU просто сгорает
в блокировках и защелках и прочих механизмах синхронизации.

Какой софт использует розничная торговля - сложно сказать. Там будет десяток систем которые
работают просто всместе как Grid. Например сообщения от кассовых аппаратов и платежных
систем могут в первую очередь падать в JMS/MQ систему. А уже потом процесситься и ложиться в
БД операционного дня. И по проишествии периода - сливаться Warehouse и в BigData
Есть еще вариант что в аналитику сразу попадают данные со стриминга. Я такое видел.
И это не последняя часть стека. Аналитика в свою очередь является источником для всяких
BI, витрин данных. ОЛАП-кубиков и прочее что любят смотреть и показывать на презентациях.
С красивой инфографикой.

Что использует Магнит - чорт его знает. Это можно поискать по всяким конференциям. Но само
знание или название продуктов вам ни о чем не скажет. Если они используют допустим
Kafka+Clickhouse - из этого не следует что вам это пригодится.

Были странные архитектурные решения. Uber например пытался выжать максимальные мощности
из Postgres и не смог. Перешел на MySQL. Видимо им было достаточно MyISAM и брали лишь
только те фичи что надо.

Facebook строил Rocksdb (Key-Value) с очень сильной оптимизацией по диску. Там уже было
не R+Tree а другой тип дерева. Тоже видимо у конторы так "пригорело" что им надо было
штучную NoSQL делать.

СБЕР по слухам строил на Apache Ignite прослойку между Ораклом и клиентами потому что Оракл
не справлялся с нагрузками. Впрочем я не могу это нигде доказать. Просто слышал в разговорах
архитекторов. И это очень штучное и очень деликатоное решение. Другим оно может вообще не подойдет.
Нужно много думать о механике инвалидации кешей.

Хедж фонд BridgeWater строит свои хранилища ассетов на базе Amazon S3. Реально эти ребята пихают
в С3 все что можно. И в этом есть своя стратегия. S3 стоит дешево. И масштабируется. Дешевле чем DBMS.

Также, я думаю, что множество магазинов могут быть обслуживаться отдельными кластерами, чтобы работа всей сети не остановилась, если какая та БД выйдет из строя?

Эту задачу тоже можно решать на разных уровнях. Мне нравится решение от Cassandra. Там все
таблицы имеют 1-2 реплики. И убить всю систему в целом в принципе невозможно пока последний
датацентр стоит. Но Кассандра платит за это отказом от consistency и вообще она считается не-реляционкой.
Хотя базовый диалект SQL поддерживает. Фактически она - умный NoSQL c хорошим сетевым протоколом
обхода сбоев и конфликтов. Кажется Netflix ее активно использует.

Вобщем можно дизайнить системы по разному усиливая одни части и ослабляя другие.
Это как тот треугольник дешево-медленно-дорого но в углах стоят разные качества. Например
CAP-свойства систем. Или приоритеты. Тебе что важно. Быстро записать в БД платеж? Но при этом
чтение оперативных данных потребует лагов. Или наоборот писать медленно зато чтоб все по ящичкам
и по коробочкам лежало да и еще в разных копиях и вариациях.

bash скрипт с набором нужных команд. Либо Ансибл - если надо массово устанавливать(хотя можно и parallel-ssh использовать)

Vless элементарно упаковывается в докер. Нужный файл json монтируется в файле docker-compose yml

Итого...
ставим нужный софт - докер,компос, fail2ban итд по желанию
копируем файлы для докер компос
стартуем docker-compose up -d -f my.yml

всё...

краткий пример yml -

version: '3'
services:
  xray-turk:
    image: teddysun/xray:latest
    volumes:
      - /opt/xray-turk/config.json:/etc/xray/config.json
      - /opt/xray-turk/geosite.dat:/usr/local/share/xray/geosite.dat
    ports:
      - "443:443"
    restart: unless-stopped

краткий bash для установки софта (который лично мне нужен) (да я знаю что там старый докер, но меня устраивает) -

#!/bin/bash

# Обновление пакетов
sudo apt-get update -qq && sudo apt-get install jq fail2ban mc htop vnstat wget git curl rsync apt-transport-https ca-certificates software-properties-common -qq -y;

# Добавление ключа репозитория Docker
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

# Получение кодового имени текущей версии Ubuntu
codename=$(lsb_release -cs)

# Добавление репозитория Docker
sudo add-apt-repository -y "deb [arch=amd64] https://download.docker.com/linux/ubuntu $codename stable";

# Обновление пакетов после добавления репозитория
sudo apt-get update;

# Установка Docker
sudo apt-get install docker-ce -qq -y;

# Установка Docker Compose
sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

# Добавление прав на выполнение для Docker Compose
sudo chmod +x /usr/local/bin/docker-compose

Желание комерческой поддержки - милости просим в ТГ )

Для 443 (https) - реверс-прокси. Порт пробрасывается на него, а он уже перенаправляет запросы к серверам по имени в запросе.
Для 25 (smtp) - всё принимается одним сервером и пересылается дальше по правилам маршрутизации почты.

Как настроить нагрузоспособность Nginx из расчета процессоров для стабильной работы?

Т.к. четкого ТЗ не указано, то выдумаю свой конфиг, с 4 ядрами и 8 гигами оперативы, тогда следующие действия:

Передадим параметры железа nginx-у, nginx.conf:

worker_processes  4; # cores
events {
    worker_connections  1024; # 1024 * 4 ram = 4096 (max all rps)
}

Настроим ограничения так, чтобы каждый ip мог делать не более 10 rpm (в минуту), nginx.conf:

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/m;

    server {
        location / {
            limit_req zone=mylimit burst=20 nodelay; # we put no more than 20 requests in the queue over the limit (anti DDoS)
        }
    }
}

Эти настройки помогут контролировать общую нагрузку на сервер и предотвратят его перегрузку за счет ограничения количества обрабатываемых запросов как в целом (через worker_connections), так и на уровне отдельных IP-адресов (через limit_req_zone и limit_req). Это эффективный способ защиты от спама и DDoS, а также обеспечивает равномерное распределение ресурсов сервера между всеми пользователями.

Многие провайдеры при истощении баланса перенаправляют все клиентские http-запросы на свою страничку с уведомлением о необходимости оплаты и каким-нибудь эквайрингом. Очевидно, что для их работы нужен работающий DNS, а зачастую ещё и доступ к CDN. Провайдеры поумнее оставляют доступ к своему DNS и запросы к CDN тоже через себя проксируют, но некоторые не заморачиваются и просто оставляют часть доступа в дикий интернет.

У меня так настроено в ~/.bashrc:

# History search with Up/Down keys.
if [[ $- == *i* ]]; then
    bind '"\eOA": history-search-backward'
    bind '"\e[A": history-search-backward'
    bind '"\eOB": history-search-forward'
    bind '"\e[B": history-search-forward'
fi

Насколько я понимаю раньше шеллы использовались в качестве примитивных высокоуровневых языков. Сейчас у нас есть Perl, Python, nodejs, php...

Ну давайте вместо рабочего стола пользователю дадим сразу Visual Studio, ведь какая разница как программу запускать - иконкой на рабочем столе, или форкать из высокоуровневого языка?

shell - это оболочка операционной системы. То, что кроме графической есть еще и command line interface - это совершенно нормально и адекватно. И шелл позволяет пользователю и администратору работать в операционной системе гораздо удобнее, чем через язык программирования.

То, что sh/bash и другие, настолько развиты что сами по себе являются неплохими языками программирования - это просто следствие того, что командый интерфейс и создавался тогда, когда каждый пользователь был немного программистом, и следствие того, что cmd line удобен для автоматизации просто по своей архитектуре.
Поэтому Powershell, bash/zsh/ksh будут продолжать развиваться.

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

Использование таймеров systemd вместо заданий cron

ещё не называли? кажется нет...
unbound.