Производительность ФС зависит от рабочей нагрузки и тут нельзя выдать конкретный рецепт.
Но можно привести некоторые примеры.
Например восстановление после сбоя, а конкретнее - низкая производительность при работе с каталогами в которых очень много файлов. В этот пример попадают ext2, ext3 (хотя тут все стало немного получше)
Я бы выбирал файловые системы с журналированием, иначе проверка ФС после сбоя может неплохо затянуться. Это может быть ext3, XFS, ZFS, JFS или ReiserFS.
Время монтирования ФС, если у вас терабайты данных. ReiserFS в таком случае долго монтируется и восстанавливается.
Например у ext3 есть различные режимы журналирования, и включения каждого из них имеет свои плюсы и минусы (в разрезе движка InnoDB).
writeback - журналирует только изменения метаданных. Считается самой быстро конфигурацией для InnoDb, так - как изменения мета данных не синхронятся с записью инфы.
например режим journal, где данные сначала пишутся в журнал и только потом в место назначения, как правило, это излишне.
ну и т.д.
Можно тюнить много чего, чтобы дать прирост InnoDB. Например отключение регистрации времени последнего доступа, упреждающее чтение.
Если юзать LVM (например резервные копии) хорошо бы посмотреть что нет траблов у ФС и они хорошо "дружат".
<FilesMatch xmlrpc.php> Order Allow,Deny Deny from all </FilesMatch>
XMLRPC по дефолту закрыт, кажется, с версии 3,5
На производительность мускуля могут оказывать влияние железо, ОС и т.д.
Но как правило, узкое место - перегрузка проца и подсистем ввода/вывода (оптимизацию запросов к базе, пока что не берем во внимание)
Насчет проца - нужно смотреть на версию базы, где лучше реализована работа с ядрами. Почему только Mysql? Может есть смысл посмотреть в сторону Percona, Maria DB. Эти решения работают и поддеррживают практически весь стандартный функционал мускуля "с коробки".
Вы можете взять проц с кучей ядер, а релизация текущей версии мускуля, к примеру, может не работать эффективно с таким количеством ядер.
SSD для базы всегда лучше, чем обычные винты :)
Выбор операционой системы + файловой системы, тоже немаловажный аспект.
Опять такие - файловую систему нужно выбирать в идеале, в зависимости от типа движков ваших таблиц. Что-то лучше для InnoDB, что-то для MyIsam лучше и т.д.
Как бы делал я:
1) Разобраться почему именно возникает такая нагрузка. Это стандартный набор вордпресса или там стоят какие-то дополнительные плагины и т.д. Что именно создает нагрузку, какой конфиг базы используется и т.д. Но в условиях хостинга, такое не сделаешь, как я понимаю :)
2) Рассмотреть вариант кеширования. Тут все зависит от типа информации и инвалидации кеша. Если задержка появления новой инфы на сайте в пределах 20-30-60 минут и т.д. не критична то можно кешировать ВП плагинами. Если время критично, то кеш придется инвалидировать часто и снижение нагрузки тут при таком трафике, скорее всего будет не очень большое.
3) Доступа к серваку нет, как я понял. Можно было это выносить на уровень nginx, apache где сразу отдавалась бы готовая статика и это было бы очень быстро.
А вообще это нужно смотреть все индивидуально. Есть какие-то общие принципы, но всегда нужно рассматривать ситуацию отдельно, учитывая ньюансы. :)
Как подметили выше, очень часть узким местом является база данных. Только скорее всего не сама база, а использование не оптимальных структур, схем индексирования и т.д. Не оптимальная настройка конфига MySQL, как правило, стоит стандартная.
Для наблюдения за базой я использую zabbix + утилиту mytop (если у вас конечно есть доступ).
Причин может быть просто море - начиная от плохих запросов и схем индексирования, заканчивая тем что база свопится и т.д.
Попросите админов включить лог медленных запросов и лог запросов, которые не используют индексы.
Для отладки php можете заюзать xdebug, возможно где-то выбираются большие массивы информации в память и т.д.
Про вашу проблему и аналогичные слышу уже не первый раз от этого биллинга и их суппорта.
Дал ответ. Принимается еще 1 заказ на четверг!!!! Действует небольшая система скидок для хороших людей 🚬
Спасибо! Набираю заказы на четверг, стучите в аську :)
я уже заждался вашего комментария ) Ответ я вам дал почти через день, так как ваш скрипт плохо структурирован - это раз, во вторых - он не продуман, в третьих - 5 вкладок в каждой нужно было сохранять по 20-40 значений, и как оказалось данные даже не в базе а в файле то ли в JSON то ли еще каком-то. И над заданием же трудится уже как пару дней другой программист, что не успевает? Я имею полное право отказаться от задания, предоплаты я у вас не брал, ответил в короткие сроки, вы были уведомлены о том, что у меня есть еще заказы.
Я посмотрел работу и отказался. Что вас не устраивает? Или вы думаете что вы справедливо поступаете? Все мои заказчики остались довольны, один только вы, начинаете писать мне какие-то кляузы в связи с тем, что программисты не хотят браться за ваше задание.
Да, и цена была установлена очень лояльная )
Всего хорошего.
Всем спасибо за отзывы, кто заказывал скрипты отпишитесь в аське, так как некоторые "клиенты" заказывают а потом очень быстро исчезают.🙅
