На нашем выделенном сервере работает большой магазин Magento с базой данных MySQL размером примерно 250 МБ.
В спецификации сервера указано 5 процессоров Xeon 2 ГГц (кэш 4 МБ) и 12 ГБ памяти.
Я бы подумал, что вышеупомянутой спецификации достаточно для очень быстрой работы даже Magento, однако, хотя сайт не медленный, на самом деле он не так быстр, как должен.
Текущий файл MySQL my.cnf выглядит следующим образом:
skip-innodb
ft_min_word_len=3
query_cache_limit = 4M
query_cache_size = 16M ## 32MB for every 1GB of RAM
query_cache_type = 1
max_user_connections = 50
max_connections = 50
interactive_timeout = 300
wait_timeout = 200
connect_timeout = 200
thread_cache_size = 32
key_buffer_size = 64M ## 128MB for every 1GB of RAM
join_buffer_size = 1M
max_connect_errors = 20
max_allowed_packet = 12M
table_cache = 1024
record_buffer = 1M
sort_buffer_size = 1M ## 1MB for every 1GB of RAM
read_buffer_size = 1M ## 1MB for every 1GB of RAM
read_rnd_buffer_size = 1M ## 1MB for every 1GB of RAM
thread_concurrency = 4 ## Number of CPUs x 2
myisam_sort_buffer_size = 32M
tmp_table_size = 16M
max_heap_table_size = 12M
[safe_mysqld]
open_files_limit = 2048
[mysqldump]
quick
max_allowed_packet = 12M
Я видел предлагаемый my.cnf для выделенного сервера БД Magento (2 ГБ оперативной памяти):
query_cache_size = 512 МБ
query_cache_limit = 256 МБ
tmp_table_size = 256 МБ
key_buffer_size = 64 МБ
read_buffer_size = 128 МБ
read_rnd_buffer_size = 128 МБ
bulk_insert_buffer_size = 64 МБ
myisam_sort_buffer_size = 128 МБ
myisam_max_sort_file_size = 128 МБ
myisam_max_extra_sort_file_size = 128 МБ
myisam_repair_threads = 2
myisam_recover
innodb_additional_mem_pool_size = 256 МБ
innodb_log_buffer_size = 128 МБ
innodb_log_file_size = 128 МБ
innodb_log_files_in_group = 2
innodb_flush_log_at_trx_commit = 0
innodb_buffer_pool_size = 512 МБ
innodb_data_home_dir = / вар / библиотека / mysql /
innodb_data_file_path = ibdata1: 256M: автоматическое расширение
innodb_autoextend_increment = 32
Мне было интересно, сможет ли кто-нибудь предложить лучшие значения для параметра my.cnf с учетом нашей спецификации?
Также, если есть что-то, о чем я должен знать, когда возился с ними, например: установите слишком большое значение и ожидайте катастрофического отказа.
Любые мысли были бы очень признательны. Ура.
MySQL обычно последний узкое место в магазине Magento, когда вы тестируете производительность для отдельного пользователя. Тем не менее, ваш my.cnf не выглядит оптимальным ни для магазина Magento, ни для этой спецификации сервера. Я написал подробный ответ о загрузке MySQL для Magento здесь,
https://serverfault.com/a/367856/113375
В настоящее время ваши лучшие усилия будут заключаться в том, чтобы сосредоточиться на улучшении времени загрузки вашей страницы с помощью других средств (изменить хост / оптимизировать шаблон и т. Д.) И обратиться к базе данных в последнюю очередь; это действительно применяется только для тестирования параллелизма и транзакционной нагрузки.
Из http://docs.sonassihosting.com/go_dedicated.pdf
В зависимости от архитектуры вашего процессора и скорости шины - используя приведенные ниже рисунки, НАИЛУЧШЕЕ, которого вы можете достичь, - это время рендеринга PHP-страницы 0,8 с (исключая images / js / css).
Дает вам общее представление о том, какое оборудование выбрать
При выборе сервера, параллелизма и времени загрузки страницы необходимо учитывать две цифры. Параллелизм - это количество клиентов, которое ваш сервер может поддерживать в любое время. Время загрузки отдельной страницы - это скорость фактической загрузки страницы для отдельного клиента.
Возможны:
- Медленное время загрузки страницы и низкая поддержка параллелизма (низкая тактовая частота процессора (ГГц), мало ядер)
- Быстрое время загрузки страницы, но низкая поддержка параллелизма (высокая тактовая частота процессора (ГГц), несколько ядер)
- Медленное время загрузки страницы, но высокая поддержка параллелизма (низкая тактовая частота процессора (ГГц), много ядер)
- Быстрое время загрузки страницы и высокая поддержка параллелизма (высокая тактовая частота ЦП (ГГц), много ядер)
Исходя из этого, вы можете выбрать свое оборудование.
Параллелизм
а) Стандартный демонстрационный магазин Magento способен доставлять примерно 230 уникальных посетителей на ГГц в час.
б) В типичном интернет-магазине с активностью пользователей-администраторов, разработкой, добавлением / удалением продукта это может снизиться примерно на 100%, до 115 уникальных посетителей на ГГц в час.
c) Магазин с плохо построенным / тяжелым шаблоном может дополнительно снизить показатель еще на 100-200%, до 50 уникальных посещений на ГГц в час.
Когда мы приводим цифры, мы используем вариант б).
Время загрузки отдельной страницы
Стандартный демонстрационный магазин Magento (CE или EE - когда FPC отключен) может загружать домашнюю страницу в:
0.7 seconds 2.4GHz CPU 0.6 seconds 2.8GHz CPU 0.51 seconds 3.3GHz CPU 0.48 seconds 3.46GHz CPUНо опять же, плохо построенный / тяжелый шаблон приведет к экспоненциальному увеличению этой цифры. При цитировании цифр мы используем шаблон демонстрационного магазина с примерами данных в качестве примера.
Выше источник извлечен из http://docs.sonassihosting.com/go_dedicated.pdf
Я бы предположил, что, поскольку у вас 5 процессоров - вы используете VPS (облачный или другой), в таком случае ввод-вывод, вероятно, будет вашим узким местом как для диска, так и для сети. К сожалению, из-за состязательной природы VPS - они никогда не бывают идеальными для хостинга Magento - если только человек / компания, управляющая им, не имеет очень глубоких знаний об оптимизации Magento, а оборудование не является предметом споров.
Минусы VPS для Magento
У каждого пользователя есть root-доступ. Это означает, что другие узлы VPS в вашей системе могут запускать bonnie / iperf / hping и впоследствии забивать ресурсы, которые нельзя разделить / разделить - ввод-вывод жесткого диска, сеть или прерывания. Так что даже если у вас есть гарантированный CPU / RAM - вы подчиняетесь общей подсистеме.
У вас ограниченный процессор и оперативная память. Да, вы можете увеличивать / уменьшать масштаб, но, в конце концов, небольшое хранилище Magento извлекает выгоду из минимум 2 ГБ ОЗУ, выделенных только для экземпляра MySQL, в сочетании с практическим правилом 1 ГБ ОЗУ / логическое ядро ЦП. Таким образом, VPS должен иметь как минимум 3 ГБ ОЗУ и 1 ядро ЦП, что при большинство (при правильной настройке) будет способен обслуживать около 1500 уникальных посетителей в день для магазина Magento, совершающего транзакции, - при условии отсутствия узких мест ввода-вывода жесткого диска или сетевого ввода-вывода.
Вы должны сами управлять этим. Странно, что в настоящее время владелец и оператор веб-сайта электронной коммерции также должны нести ответственность за настройку, мониторинг и управление своей инфраструктурой хостинга. Владелец магазина должен сосредоточиться на том, в чем он хорош - на ведении своего бизнеса, а не на попытках исправления ошибок, настройки производительности или администрирования Linux-сервера с командной строкой. Худший вариант развития событий приводит к слепой панике, когда что-то идет не так, с чем у них просто нет опыта.
Выше источник извлечен из http://www.webhostchat.co.uk/dedicated-servers-vps-colocation/27555-magento-hosting-please-advise-what-i-may-need-2-sites-1-magento-install.html
Чтобы получить лучший / более точный ответ, опубликуйте дополнительную информацию о своем магазине. -
Я пропущу большой объем текста, который мог бы написать, и сразу перейду к делу.
Взгляните на них на мгновение:
max_user_connections = 50
max_connections = 50
Apache по умолчанию запускает 500 подключений. На данный момент, если 50 запросов пойдут в MySQL / MySqlI, то больше будет отклонено.