В данном случае нет принципиальной разницы - для отказоустойчивости это или для распределения нагрузки. В любом разе оба сервера должны быть готовы принимать соединения.
Чтобы избавиться от точки отказа, принимающей нагрузку, есть ещё вариант с виртуальным сетевым интерфейсом с IP, который переключается с одного сервера на другой. Heartbeat обычно используют для настройки такой штуки. Это легко настроить и хорошо работает, если вы контролируете сети, в которых у вас работают системы.
Но очевидно, что у разных хостеров вам никто не даст это настроить, потому как вы не сможете использовать один IP на обеих системах. Поэтому остается только простая dns-балансировка.
Не морочьте голову одним прокси, точкой отказа. Как работают те же mail.ru, vk.com, google? Вот так:
Это просто dns-балансировка - несколько A-записей с разными адресами. Вот обсуждается как работает dns round-robin.
Там в первую очередь картинки надо оптимизировать. И google pagespeed, и отладчик хрома показывают в чем проблема.
Но 200-300 ms TTFB перед отдачей статики - это жутко долго. Нужно просто настроить чтобы nginx отдавал статику напрямую с диска, не обращаясь к бэкенду. Не только изображения, там и js, css тоже очень много и всё это отдаётся через php (apache?) похоже. Кроме того, есть битые css самого woocommerce, которые нужно отключить.
Клиентское кэширование тоже не настроено полностью, судя по тесту Google.
Была проблема с трафом из Google. Решилась. Вкратце - отмена мусорных ссылок, смена домена, добавление контента, простановка релевантных ссылок, внутренняя оптимизация. Подробно расписано выше по ссылке.
Ну что ж, отрадно это слышать, если действительно так. Я тоже халтуру не жалую, но, по правде сказать, действительно лень было разбираться в тонкостях настройки кэширования. Но недавно всё же сделал это.
Да, я заглядывал уже на ваш сайт, и узнал для себя ништяки кое-какие. За ссылку лойс вам. Хорошая статья, действительно кое-что прояснилось для меня, чего ранее не понимал.
Но, кое-что у вас там можно улучшить.
location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { root /images; }
Вот эта конструкция будет слабо работать. Согласно этому конфигу, nginx будет напрямую отдавать только то, что лежит в одной папке. На большинстве сайтов, изображения разбросаны по разным папкам. И уж тем более js и css там не окажется. Тот же wp, о котором мы говорим в контексте этого обсуждения. Поэтому, я бы рекомендовал заменить её на такое:
location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { try_files $uri $uri/ =404; }
Это надо смотреть. Может nginx, а может что-то ещё. 25гб - наверное не памяти, а диска? Сообщение лишь о том, что php не может подключиться к mysql. А почему не может - это нужно смотреть логи самого mysql. Сначала нужно выяснять именно это. Nginx здесь вряд ли, если и может быть "виноватым", то в самую последнюю очередь.
Я это понимаю. Буквально сегодня для другого клиента отлаживал конфиг с кэшированием ответов бэкенда с очень тяжелым приложением на ruby. Так там приложение отвечает 5-20 секунд, и без этого кэширования просто никак не обойтись.
Но это немного сложнее настроить и отладить, чем просто воткнуть wp-supercache. Соответственно, это будет дороже для клиента.
Сложнее в настройке. Под wp, скорей всего, отлаживать надо чтобы нормально работало, админку не кэшировало и.т.д. А плагин, в принципе, делает то же самое, но меньше заморочек. Для каждого сайта свой кэш, которым админу сайта легко управлять, в случае чего.
Для больших нагруженных проектов согласен - можно юзать кэширование динамики самим nginx.
Скорей всего сама ОС рестарт делает при крашах. Посмотрите системные логи (/var/log/syslog - если deb-based система или /var/log/messages - если rpm-based - centos). Хотя, в centos такой штуки насколько я знаю, нету. А вот в ubuntu вполне может быть. Там в /etc/init/mysql.conf есть настройки respawn - это вот оно. Какая ОС?
В общем, читайте логи. Системные и самой СУБД ( /var/log/mysql* ) Там всё написано - кто или что, когда и почему упало или было перезагружено. Ещё можете выключить mysql и запустить его не сервисом, а просто из консоли - mysqld & . В этом случае оно при падении скорей всего так и останется лежать.
Спасибо, подняли настроение с утра. 😂
Кстати, вчера разговаривал с клиентом, этот VPS за вчерашний день выдержал наплыв ~10k событийного трафа с глубиной просмотра 2 + возросшую активность поисковых ботов. При этом страницы открывались так же быстро, средняя утилизация ресурсов около 50-60%.
В общем, всё, как я и прогнозировал в кейсе, расписанном на answIT'e - vps минимального тарифа ( 1 cpu, 1 gb RAM), настроенный таким образом, будет держать нарузку в 15-20к трафа на стандартном wordpress с wp-supercache.
