MySQL 5.1 -> 5.5 -> PerconaDB упала запись в 3 раза.

sstyle, почему бы и нет? в Percona никто не обещал ускорения. Обещали диагностику и масштабируемость.

Но вообще, я полагаю, и у вас просто методика измерений зависит от внешних условий.

Cделайте тест битрикс не на VPS и 20 раз в разное время дня, усредните - тогда о чем-то можно будет рассуждать.

Почему поставил mysql 5.5? Установи 5.6 и протестируй.

https://www.percona.com/blog/2011/10/10/mysql-versions-shootout/

http://www.sql.ru/forum/1034085/percona-vs-mysql

5.6 будет еще медленнее судя по тестам. Вобщем солидарен с автором темы на sql ru. Оставлю 5.1, раз она быстрее всех.

Надо изучать триггеры mysql, наш программист изучил и прирост на 5,6 +350%.

Иннодб всегда был есть и будет самым медленным движком его нужно использовать только если у машины слабы процессор.

впервые слышу чтобы innodb было медленнее myisam. На нагруженных серверах это 100% не так.

Зависит от специфики использования, но при всех прочих равных будет значительно медленнее, и это не пустые слова, а практика в виде активных 1.5Тбайт данных на SSD-массивах Intel DC S3700 🍿

К слову, XtraDB реализован на InnoDB Plugin, только первый быстрее второго значительно, а второй в быстрее встроенного InnoDB. Но это только в теории, на практике, логика работы там иная, дефолтные значения типа innodb_io_capacity могут быть весьма интересными (по умолчанию IOPS'ов всего 200), в итоге это выливается в ситуацию когда более быстрое решение (но криво настроенное) проигрывает в пух и прах более старой реализации (в виде встроенного InnoDB).

И попробуйте потюнить:

# временные файлы в ОЗУ

tmpdir = /dev/shm

# если ОЗУ позволяет, то выставляем равным объему всех таблиц

innodb-buffer-pool-size = 2G

# чем выше предыдущее значение, тем выше устанавливаем это значение

innodb_buffer_pool_instances = 2

# оптимизируем логи

innodb_log_file_size = 1G

innodb_log_buffer_size = 64M

# тюним работу со сторэджем (пример для SSD)

innodb_read_io_threads = 32

innodb_write_io_threads = 32

innodb_io_capacity = 1024

# оптимизируем сброс логов

innodb-flush-log-at-trx-commit = 2

Посмотри на табличку в статье:

https://habrahabr.ru/post/242337/

MyISAM определенно значительно быстрее там, где частые апдейты и вставки данных.

Многократно проверено лично тестовыми скриптами и на реальной базе, где много счетчиков у объектов лежат в тех же таблицах.

Нашел кстати небольшой хак для InnoDB, но не пробовал

https://www.drupal.org/node/1661608

Парни, MyISAM блокирует при вставке всю таблицу целиком, а InnoDB по строкам. Битрикс сам в своих рекомендациях настаивает на InnoDB

Фикс этот я уже сделал, значения и выросли до ~8тыс. Но на хостинге за 300рублей (не буду говорить каком, чтобы не рекламировать), на такой же версии PHP 5.3 результат такой:

Сегодня пытался поставить MariaDB. Как-то долго, нудно, особенно с конфигом. Подзабил на время.

Главное сейчас оптимизировать скорость "процессора" по битрикс-тесту. Почему то медленно. На этом же хостинге вместо апача видимо php-fpm используют.

А зачем ? Вы нанимались именно попугаи поднимать ?

Я всегда думал, что для вебмастера главное это выгода и стабильность

.

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

Но а если ее просто выключить ? Остальные то таблицы не сильно меняются. ( И не надо рассказывать, что у вас по 30 постов в секунду происходит ) . Так многие делают. Сайт останется сайтом . Посещаемость в Метрике посмотрите.