Влад Животнев

> Меня смущает производительность, она болтается в районе 150 RPS.
Самая тяжелая операция - хендшейк, всё остальное мелочи жизни.
У вас производительность не 150 RPS, а 150 хендшейков.

По сабжу, как-то так:

ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/cert.pem;

ssl_dhparam /etc/nginx/ssl/dhparam.pem;

ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2;
ssl_session_cache shared:SSL:64m;
ssl_session_timeout 28h;

#add_header Strict-Transport-Security "max-age=31536000; always";

A-rate при оптимальной производительности, 1 хендшейк на клиента раз в 28 часов, если клиентов много разных - крутите размер ssl_session_cache.

Кроны все проверили?

На такие "вопросы" принято отвечать глядя в консоль сервера от рута.
Скорее всего, у вас OpenVZ (тогда можно попробовать свалить на KVM с SSD), либо прикручен миллион плагинов к WP, которые в сумме тормозят, либо вы сами уже перемудрили с настройкой, сделав хуже, чем дефолт.
А может WP до сих пор ходит в удаленную базу. Причин много может быть.
А по имеющимся данным ответит только телепат уровнем на пару порядков выше нас здесь собравшихся.

highload - это, скорее, не про нагрузки/RPS, а про доступность 24/7 и отсутствие точек отказа. Ну и про возможности масштабирования.

То есть, в большинстве случаев, highload - это _возможность_ принимать большие нагрузки без проблем (покормив проект железом), а не их реальное присутствие. Естественно, подтвержденное нагрузочным тестированием.
А так, всё что меньше 20 тысяч запросов в секунду - мелочи жизни.

Если тег highload поставлен не от балды (вообще-то база на 30 гб - никакая) и в базу действительно идет перманентная нагрузка, от которой избавиться нельзя, то:
1) если есть возможность переключить базу и сервис в read-only - переключаем.
1.1) если нет - пишем в приложении прослойку к mysql-базе, которая сначала делает запрос в новую базу с utf8, потом в старую с cp1251, мерджит результаты.
2) перегоняем построчно/потаблично данные в новую базу, конвертируя на лету. Проверяем, что строка есть в новой базе, удаляем строку из старой базы,

Если же у вас highload поставлен от балды, то дамп, iconv, restore в базу с новым именем. Приложение перед этим потушить, чтобы данные не потерялись (или в read-only базу перевести).

Статические страницы (не ходят в базу) + AJAX - вот и весь секрет.

Но если так посмотреть - то у меня обычный WP грузит не сильно дольше - https://vlad.pro/.

В Hetzner и OVH есть failover-ip-адреса.
Переключаются между машинами секунд за 10.

Ну а дальше - heartbeat и погнали.

Зависит от хостера.
Если хостер использует актуальную версию openvz с корректно настроенным и используемым vswap (когда лимит вешается только на количество страниц ram/swap, а не на всякие крутилки) - то всё хорошо.
Если хостер лимитирует что-то, кроме страниц - бедапечаль.

То бишь в конфиге должны быть заданы:
PHYSPAGES="65536:65536"
SWAPPAGES="65536"

(это 256 мб, что ли)
А всё остальное, что грепается по -i mem должно стоять в unlimited.

> 3) на текущий момент под урлы для гифок забито 10 поддоменов. Просто брать и постепенно мигрировать их на разные сервера с параллельной подменой ip? Ручной вариант, не очень нравится.

Зато самый простой (и в вашем случае - работающий).

Вообще же можно сделать вместо 404-ки 301й редирект на соседние сервера (шардированные по поддоменам) + proxy_store/proxy_cache для особенно популярных картинок (чтобы они везде валялись).

Коннект к базе вы персистентный держите?
Если держите - то пока вы не окунетесь в highload (больше 1k rps на вашу страницу), то вообще без разницы.
Если не держите - то будут дополнительные накладные расходы на установление коннекта. Но их там тоже немного при небольшой нагрузке.

Так что в данном случае исходить нужно из того, как будет читаемее и удобнее вам самим.

haproxy не подойдет, если вы не собираетесь модифицировать приложение (то бишь, внутри него описывать логику куда ходить селектом, а куда инсертом).
MysqlProxy подойдет. Но у него проблемы с кодировками, отличными от utf8.

Свалите с этого хостинга. Виртуалки на ssd даже в России стоят уже по 250 рублей, не говоря уж про 150-рублевых европейцев.

my.mail.ru/corp/morozova/video/16
Записи YaC
www.highload.ru (за деньги, 23 мая трансляция + записи).

Вообще на русском по этой теме мало кто чего рассказывает, тем более бесплатно. По английски книг написано много, но большая часть - чушь. Можно почитать ru-highload.livejournal.com , чтобы понимать, что гуглить.

На английском книг много, но большая часть - ересь, фильтровать без опыта тяжело. Вообще же highload сегодня скорее про "быстро пишитенам горизонтально масштабируемое приложение! А мы его на 50 серверов положим и пусть работает. Не хватит - ещё железа добавим". Так дешевле.

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

> Как будет вести MySql при таких объемах?
Х**во он себя будет вести через пару месяцев (ну или через 4 месяца, если у вас будет 256 гов памяти).
С другой стороны, 100 гб в месяц у вас там и не будет. А если и будет - то прекратите хранить в базе картинки и другую чушь.

> Если создать несколько бд например для комментариев то как искать нужную бд для вывода?
if comment_id < 1000000 and commend_id > 0 then use mysql1
if comment_id < 2000000 and comment id > 1000000 then use mysql2
Примерно так. А вообще это называется шардированием, как его организовывать - решать вам. Обычно делают метабазу, в которой хранят диапазоны id-шников и соответствия с конкретным сервером. К тому же на сервера со старыми комментариями нагрузка со временем будет и меньше и их можно будет "решардировать" - т.е., например, сливать 3 старых базы в 1 и править id-ники в метабазе. А 2 освободившихся сервера ставить под запись для новых комментариев.

> Одну базу или несколько, одну для статей другую для комментариев..?
Тупиковый путь, если объём данных станет больше определенного порога.
Станет много статей - загнется mysql со статьями, станет много комментариев - ....
В любом случае, нужно и делить по типу хранимых данных, и шардировать.