suffix, Мемкешд он будет эффективен при большой нагрузке. Кроме того, там тоже много чего можно крутить. Просто поднять не достаточно. Ну и опять же, сам по себе мемкешд используют прежде всего потому, что он значительно предсказуемее и он управляем, в отличие от кэша ФС.
SrvBuy, Артём, похвально, на самом деле, что хочешь заниматься чем-то вместо тупого сидения в ВК, к примеру. Но (!). У нас здесь были многие личности, которые начинали так же, а потом сливались. Непосредственно хостинг - слишком низкомаржинальный бизнес, и затраты окупаются при достаточно больших объемах. Кроме того, твой подход ошибочен и слишком неудобен для клиента.
Окружающие здесь тебя товарищи - представители других компаний. Некоорые из них начинали подобным образом, как и ты. Но вся данная тема - предостережение клиентам, чтобы они знали, кто ты и что ты. На практике, доверия к гораздо более серьезным дядькам часто нет, а здесь все в общем нашли. Ну и следует понимать, что хостинг - далеко не то, что ты себе представляешь. Это достаточно сложная, нервная и кропотливая работа, а ты будешь в ближайшее время терять деньги и время. Займись лучше сначала доведением всего до ума, биллинг тебе пока не нужен (пока нет клиентов). Сделай лаконичный и понятный сайт, разберись в том, как это работает, посчитай экономическую целесообразность. Если ты думаешь, что ты можешь заработать демпингом - это ошибка. Те, кто так делают - сливаются так или иначе. Всё это вопрос времени.
Собственно, если клиентов нет - сворачивайся, бери и делай на локалхосте всё. Тестируй, бери заказы на биржах фриланса. Серьёщные сотрудники к тебе не пойдут, а чтобы что-то серьёзное делать - мало быть просто сообразительным, нужен опыт. Вот когда у тебя будет опыт - тогда и приходи в эту сферу.
P.S. Я ещё молчу о том, что всё, что ты делаешь - не законно. И если кому-то наступишь на хваост - твои родители будут очень долго разгребать то дерьмо, которое может возникнуть.
На практике, насколько я понимаю, если раздача статики происходит через CDN - кэшировать её на стороне сервера не имеет смысла. Если это Wordpress, да и вообще любой кэш на уровне CMS - он помогает только до определённых пределов. Тут есть такое, что у сайта могут быт миллионы страниц, и создавать кэш для страниц, которые запрашиваются крайне редко - бывает даже накладнее, чем отдавать их без кэширования.
Использование PHP.Opcache и прочих акселераторов - весьма и весьма не однозначно. Вообще, все эти акселераторы кэшируют опкоды PHP в памяти, время кэширования, размер кэша и всё остальное - тоже в общем-то можно долго и много настраивать, однако следует учитывать, что производительность очень сильно зависит и от версии PHP и начиная с PHP7, как правило, рекомендуется использовать PHP APC, вместо других способов кэширования. Обычно этого достаточно.
Вообще же, кэш на уровне CMS имеет смысл выключать полностью, особенно, когда в качестве веб-сервера используется Nginx и PHP-FPM. Непосредственно Nginx (да, на самом деле, и апач так умеет) имеет продвинутые режимы кэширования. Например, запрашиваемая страница превращается в статику, и отдаётся уже без участия PHP-интерпретатора: до него запрос просто не доходит: весьма круто снижает нагрузку. Но как быть с динамическим контентом? И это тоже решается, т.к. сама CMS может подавать сведения для Nginx, что вот, мол, эту страничку кэшировать не надо (Cache control). ВОт статейка на тему: должна пролить свет лучше, чем я тут объясняю: https://ruhighload.com/Кэширование+статики+и+cache-control
Собственно говоря, вывод такой: при правильной настройке серверного окружения использовать внутренние стандартные плагины для кэширования в CMS - не оптимально: при правильном подходе лучше сварганить плагин, который будет работать с Nginx и использвать для кэширования страниц его. Кэширование php-opcache и подобные - да, желательны. Кэширование статики на стороне CDN - ну, только елси используется CDN: этопросто ещё один уровень кэширования. Следует учитывать, что непосредственно CDN обычно предназначен не столько для кэширования и снижения нагрузки на сервер, сколько для более быстрой раздачи контента конечному клиенту, где бы он ни находился (из наиболее близкой точки).
Многие CMS имеют проблемы спроизводительностью из-за кривых тем оформления и/или плагинов. Бывает так, что проявляется огромная нагрузка на MySQL, делаются большие выборки и всё это потом отдаётся перевариваться в PHP. Для PHP же сериализация данных - весьма и веьма затратная операция. Так вот, если какие-то скрипты выполняются долго по времени - следует посмотреть, какие запросы выполняет MySQL, с какими объемами данных работает PHP. Мне встречались случаи, когда выборка из MySQL 12 млн строк передавалась в PHP и он начинал задыхаться, ради отображения самых популярных статей в вордпрессе.
Оптимизация MySQL, как правило, сводится к тому, чтобы вся БД влезала в ОЗУ и в правильной расстановке буферов. Плюс если больше селектов - тогда переезжают на MyISAM, если не нужна транзакционная целостность. В случае, если трафик MySQL очень большой, а так же достаточно большая БД - имеет смысл отключать кэширование MySQL и переписывать скрипты, для того, чтобы использовался Memcached, вместо кэширования мускула. Но всё это жутко индивидуально для каждого проекта.
В общем же случае следует использовать как можно меньше сущностей и создавать максимально низкое количество точек отказа. Особенно не желательно дублировать функционал компонентов системы, к примеру, с кэшированием. Кроме того, кэширование статики (я не знаю, подменяет ли CDN заголовки) в ISPManager галочкой - означает лишь кэширование на стороне браузера. Обычно, при не сильно большом трафике это не снижает нагрузку на сервер никак, это лишь позволяет браузеру клиента повторно запросить содержимое без запроса к серверу. Кроме того, дефолтные правила не всегда охватывают всякую экзотику, которая может использоваться. Например, .woff, .webp, .svg - часто из стандартных правил исключены.
Если задача не снизить нагрузку на сервер, а оптимизировать отдаваемые страницы - крайне имеет смысл рассмотреть модуль google_pagespeed - он есть и для Nginx, и для Apache. Этот модуль, кроме всего прочего, тоже умеет кэшировать данные, и при должной нагрузке весьма не плохо оптимизирует отдаю страниц и статики, а так же позволяет снизить нагрузку на сервер.---------- Добавлено 25.04.2019 в 14:43 ----------
Не совсем так. Сама по себе проверка, есть ли страница в кэше и её отдача - выполняются с помощью PHP. В случае кэширования Nginx - ну, тут такое, что запрос до PHP может просто и не дойти. Зависит всё от подхода и от непосредственно задач.
Могу лицензию Pro направить куда надо.
GlobaNet, Да. У меня были случаи, что на этапе установки ОС диски рассыпались. Просто меняли и работаем дальше. Это softlayer если что. Знаете, что за ДЦ?
Заявленный на сайте проц стоит в арендованной железке. Если железка неисправна - сообщаем владельцу, псть чинит и компенсирует в рамках договора. Если нет - тогда кидалы. А пока я вижу только одного балабола, который делает вид что строит бизнес и умнее всех тт находящихся вместе взятых.
С лоукостом именно так. На крайняк можно попросить денежку обратно. Другое дело, что правильным подходом я считаю проводить им предпродажную подготовку перед сдачей клиенту - как минимум запускать нагрузочные тесты, чистить от пыли и т.п. Но, может, и платформа хреновая. В любом случае они закупили железо и могут не знать о проблемах. С другой стороны судя по тому, что это лоукост - "не гнался бы ты поп за дешевизною". Наверное, так. И в любом случае надо написать в саппорт и выяснить, что за хрень. 99% что компания бы исправила ситуацию тем или иным способом. Ну и да, если человек покупает железо "то там, то сям", а не собирается сотрудничать длительный срок - естественно, ему в ломы сообщить партнёру о проблемах.
Я вам даже больше скажу. В одной компании, которая здесь присутствует - нам по ошибку отформатировали весьма важный узел кластера, поставили другую ОС. Ну в тот момент ситуация была такова, что на нём всё держалось, ибо остальные узлы были выведены из обслуживания. Поставили другую ОС... А для меня лично неприятность оказаась в том, что мне было быстрее восстановить информацию с сервера (благо, в рейде поставили только на один диск, а второй всего лишь форматнули) в предыдущее состояние, чем разворачивать бэкапы. И ничего, никаких истерик с нашей стороны. Порешали вопрос и пользуемся железкой дальше. Вот уже несколько лет прошло и ни одного разрыва...
А вы бы как белка-истеричка пошли не решать вопрос, а кричать на всех форумах, что они уроды и кидалы?
WapGraf, Может потребоваться редактирование fstab и перегенерация initrd.
LoadAverage - количество процессов, ожидающих выполнения в единицу времени. Измеряется за минуту, 5 минут и 15 минут (обычно). Прямого отношения к нагрузке эта штука вообще не имеет, лишь косвенное. Мне известны специфические серверы с LoadAverage 200+ единиц, при этом работающие вполне нормально. Просто софт там такой запущен... Временной лаг в данном случае минута максимум. Если это много- оцеивайте нагрузку по другим показателям.
f0b0s, Вариант 2. На оставшемся объёме создать ещё один RAID-1 массив, смонтировать его в файловую систему и пользоваться.
