Переход с технологии виртуализации OpenVZ на новомодные облачные серверы KVM могут ли увеличить скорость сайта?

да 1500 если читать один большой файл. но игры (а сайты еще в большей степени) обычно состоят из кучи мелких.

есть самая тяжелая задача - читать в один поток случайные мелкие блоки 4кб

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

так вот в первом случае у дисков с +/- одинаковым типом флэш памяти результат будет около 50мб/с, что даже близко не 1500 и не 500.

в реальности же обычно происходит болтанка где-то между этими крайностями 50-500 или 50-1500. и чем более дешманская ssd'шка, тем меньше шанса увидеть более вторую цифру, чем первую.

и соотв. более качественные и дорогие будут раньше "разгоняться" до макс. скоростей. тот же optane с ходу в 1 поток 4k читает на 400мб/с и не смотря на то что потолок 2500 "всего" и может показаться, что какой-то там самсунг или еще что-то с 3000+ макс скоростью будет быстрей, но нет. не будет даже близко. почти во всех ситуациях все будут сливать оптану.

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

короче я лишь хочу донести, что ну не надо смотреть на цифры максимальной скорости и думать, что всегда при всех условиях будут именно эти скоростя - НЕТ!

вышеприведенное видео какраз подтверждает факт что не будет сильно заметна разница между sata и nvme дисками, если оба на дешманских TLC ячейках. даже пусть там хоть макс. 5000мб/с будет написано в характеристиках. в задачах типа запуска приложения (из кучки файлов/библиотек) или работе сайтов (тоже одни лишь мелкие файлы) все они будут выдавать лишь все те же около 50мб/c. может изредка будут попадаться файлы по-крупней и лишь за счет них nvme диск может на крохи уйти вперед. но никак не в 3 раза как может казаться из характеристик... или как обещают nvme-хостеры в рекламе.

короче... смотрите в первую очередь на тип памяти, а не на nvme оно или нет, pcie 3.0 или 4.0

ну или не заморачивайтесь и не задавайте лишних вопросов, все равно хостеров на правильных nvme дисках практически нет... тут снова просится бредор 😐

вот:

https://habr.com/ru/news/t/524870/

в комментариях народ тоже бомбит от фейковости всех этих современных nvme дисков.

но в который раз повторюсь, это касается лишь дешевых моделей.

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

Корявые настройки сервера

Неправильный формат таблиц Mysql

Сломанные скрипты WP из-за косячных импортов товаров

Забытые настройки robots.txt

Без кэшевые перебирающие 30К товаров каждый раз скрипты

Какие нафиг KVM? Куда там  NVMe? Люди берут 16 ядерную машину, с NVMe, 64 ГБ памяти, а у них opencart по 5 секунд грузится с базой в 200 МБ.

Это как, если гоночная машина не едет как надо, возможно надо прокладку поменять между рулём и сиденьем. 

Месяц назад спас клиента жены, который хотел бизнес закрывать из-за криворуких админов, которые не могли настроить сервер под 3 млн. товаров, за 6 месяцев. И уверяли, что 128 ГБ памяти это мало для такого сайта.

А что сделали на сервере где 3 млн товаров?

b2b решение какоето?

Ох уж эти сказочки, ох уж эти сказочники.

Да нет... вы просто масштабы некомпетентности не понимаете старых админов.

Там cs-cart, загрузка информации туда сюда идёт из 1С. У каждого товара по 5-15 характеристик.

Все таблицы в MyISAM и полностью дефолтные настройки mysql. Хотя нет... там размер кэша запросов установили:

query_cache_size=999999999999999999999999

Ну чисто, чтобы хватали. 9 ТБ памяти или 90 ТБ, не помню.

Загрузка 10 000 товаров могла идти сутки из-за того, что таблицы полностью блокировались. Сайт при этом ложился. И так каждый день изо дня в день. На вопросы админам, какого хера, ответы были такие:

- Ну наверное ДДОС идёт

- Ну наверное там что-то 1С делает

- Да само пройдёт ща

- 3 млн товаров, что вы ещё хотите?!

Я когда это всё слушал в течении 3-х месяцев, вообще был в шоке. Потом уже договорились о предоставлении доступов.

Процедуры были обычные, это настройка mysql/php под параметры сервера, БЕЗ выделения 9ТБ памяти, главное это перевод таблиц в InnoDB. И о чудо! Оказывается товары могут грузится в 10 раз быстрее и при этом сайт может не падать.

А, ясно, 9Тб памяти это супер железо! )))

У меня просто тоже есть один проект с тяжелой базой порядка 20 Гиг и товаров порядка 3млн.

Когда идет обновления тора из xml файла цен и характеристик, этот файл предоставляет производители.

Структура таблица Innodb.

То база просто парой замирает, нагрузка на проц 85-90%.

Где-то писалось на офф сайте мускула, что чем меньше значение  query_cache_size, тем лучше.

Я его практически отключил на всех проектах.

Именно так. Я просто говорю не про сказки, как тут некоторые пишут, а просто про жизнь. Каждый день с таким сталкиваюсь, ничего особенно.

Выключать кэш надо, если много идёт записей в таблицы т.е. очень живой проект. Тогда просто кэш будет сильно тормозить т.к. много времени тратиться на его сброс, запись, проверку и т.д.

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

Если идёт загрузка данных, там просто надо устанавливать приличные лимиты для всяких tmp данных. Также очень сильно зависит как вообще идёт импорт. А то у cs-cart там при импорте в 1с, после каждого добавления товара идёт COUNT(*) в категорию... ппц... Приходится с этим жить.

Увеличивать join кэш выборок не хочется, жуткий костыль.

Или отключать в мускуле резервируемости транзакций тоже не хочется.