Оптимизация конфига MySQL под OpenCart с большим кол-вом товара.

И так, собственно вопрос знатокам, какие настройки MySQL оптимальны под OpenCart с 500.000 товара.
И вообще, какую ОС посоветуете для этих целей?
Сразу скажу чтобы не было вопросов - будет дедик, я пока склоняюсь к Windows Server 2008 потому что могу всё решить "на лету с ним" какие предложите варианты вы?

 

Проблема в том что это именно им, причём небольшой им, в больших магазинах по этой тематике порядка 5-8 млн товаров.
Собственно сейчас без оптимизации загрузка страницы около секунды, впринципе устраивает но хотелось бы побыстрее чтобы была возможность увеличить кол-во товара.
В какой именно области посоветуете оптимизировать запросы? В каких файлах?

 

Если 1 секунда с таким кк-вом то че тут отимизировать?
Посмотри сначала что больше грузится, если БД спокойно дишит то нечиво ее настраивать
вобшем всегда помогает увеличивания параметра query_cache_size
вобшем здесь нужно смотреть, вести логи и тогда делать настройку

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

P.S. С юниксами помогу настроить
--- добавлено: 24 фев 2013 в 14:12 ---

для 30к оптимизировать то и ненадо)
вот без оптимизации кода http://www.10tochka.org.ua/

А вобшем оптимизация кода(запросов) дело тонкоє, ето уже не опенкарт получится а твой кард на 50 %
--- добавлено: 24 фев 2013 в 14:17 ---
ZloyShadow, Вот статья для понимания всех параметров мускуля, юзай

 

Да нет, про параметры то я сам знаю уже давно) Меня интересует не у кого не было практики создания сайта на 250к+ позиций на опенкарте?

Какие пакеты посоветуете?

 

Около 100к делал
обошолся настройкой мускуля и подключениям APC

 

В винду есть из тех кто поддерживает 5.4 PHP вот такой аккселератор -
eAccelerator

кто нибудь работал с ним?

Да, забыл спросить, нашёл под оконный сервер Memcached x64 ( найти что то х64 на винду это долбанутся... ) что нужно помимо самой конфигурации мемкеша делать? прсото я ещё не разу не оптимизировал PHP, только MySQL


Так, нашёл APC,eAccelerator и мемкеш, что из них посоветуете для более продуктивной работы движка?

 

Memcached ето и есть оптимизация БД )
Вот что тебе нужно для него
APC,eAccelerator на твой вибор, я остановился на APC

Подключал мемкеша но увеличения производительности так и неувидел, так что делай виводи сам...

 

С еаккселератором пролёт, есть Xcache и APC. Сейчас буду оба тестировать, какие есть параметры у APC или апц просто как модуль подключить?

 

Несколько лет работаю с APC на FreeBSD на выделенном сервере. ничего не настраивал в APC. Да и нужды не было.

 

В качестве эксперемента пробовал использовать другой драйвер для работы с базой данных MySQLi магазин был небольшой, но реально на глаз відно біло увеличение производительности, другие замеры не делал, но страничка реально в раза 2 быстрее загружалась
Вот можно попробовать

 

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

В качестве оси рекомендую ubuntu 12.04 LTS. Потому что это всегда самое свежее ядро и самый свежий софт, включая MySQL. Собственно под виндой mysql не очень мне понравился.

Далее предлагается поставить какую-то систему мониторинга жизнеспособности системы, чтобы она вам не просто показывала плохо серверу или нет, но и показывала где у вас затыки - винт, память, блокировки и т.д. Лично я рекомендую zabbix, потому что решение проверенное и все такое.

Далее лично я порекомендовал бы успокоиться и посмотреть как сайт отработает первую неделю. Вполне возможно, что обычный тазик за 100 баксов, содержащий 24 гига памяти на борту, справится без всяких оптимизаций.

Но если пятки горят, то можно сделать еще несколько телодвижений:
* перевести веб сервер на nginx ( апач тяжеловат, даже сейчас ), а пых на php-fpm
* добавить кешер опкода ( это чтобы php каждый раз не транслировался в полумашинные инструкции, все таки это не компилированный код )
* выделить мускулю 80% памяти от общесерверной, которой должно быть не менее 16, а лучше 32 ( сейчас это дешево ).

И вот далее предлагаю подождать, потому как грамотная оптимизация делается по проблемам, а не в слепую. Когда нагрузка появится и сервер станет тяжеловато реагировать ( а это вполне легко можно отслеживать по access-логу веб сервера ), то далее мы уже будем понимать где проблема - в конкретных пых файликах ( тогда ищем и оптимизируем ) или в железе ( банально может не хватать памяти, ибо если системка сконфигурирована не верно, то мускуль запросто может уводить всех в своп ) или в базе ( например не хватает индексов или неправильно распределены буфера ).

Например если проблема с базой, то log_slow_query на единичку и мы будем видеть все запросы, которые длятся больше секунды, а соответтсвенно будем видеть как их можно подтюнить за счет индексов ( mysql explain в руки ). Очень часто бывает что есть 1-2 дурацких запроса, которые достаточно затюнить и нагрузка спадет в ноль. А если задница по всем подряд запросам, то вполне может быть что мускуль сконфирурирован неверно и тут поможет либо mysqltunner, который по логу работы сервера может выдать вполне неплохие рекомендуемые параметры, либо для более тонкого тюнинга - страничка из pma со сведениями о проблемах.

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

Удачи, будут вопросы - обращайся.

 

А всегда ли нужна самая свежая MySQL? Например, 5.6 в реальности по производительности хуже на 12% чем 5.5 несмотря на заверения производителя об обратном.

 

sitecreator, Верно, не нужна самая последняя. Нужна стейбл версия!)
А обновиться можно на любой ОСи

 

А я залила магаз в 30К товаров на хостинг за 3 бакса и все нормально грузится без оптимизации менее секунды. Что я делаю не так?))

 

Не смотришь статистику посещений Я залью сейчас тримульйон товаров в магазин, который никто не использует кроме меня. И буду радоваться скорости загрузки ГЛАВНОЙ страницы.

 

Luxy, хостнг нормальный(а нормальных 10-20% осталось)
На хостинге есть грамотный админ который сконфигурировал сервера на УРА
В качестве хранилища для БД используеться SAS диск
И ето все (повторяю) грамотно настроено!

30к товаров не так уж и много, у меня главная на таком к-ве откликается меньше чем за 0,1 секунды
Вы создайте больше 1000 категорий, да не только 1 и 2 уровня а и 3 и 4, потом в все категории товары импортнинте и посмотрите как работает, потом и про запросы в БД откуда то узнаете и про рекурсию кто то вам скажет...))

И было бы неплохо ссылку на сайт для примера?

 

Ты наверное имеешь в виду SSD? SAS не панацея в общем-то.

+100500 А еще в панель мониторинга сервера, чтобы видеть какие там ресурсы

 

Нет не т и еще раз нет! SSD ето твердительный диск.
SAS ето почти тот же жосткий тока оборотов больше и скорость передачи больше, обычно нормальные люди в качестве хранилища БД ставлять SAS диск

 

Извини, я уже давно не нормальный и SAS мне не хватает У SSD просто чумовой отрыв от обычных дисков для целей БД ввиду большого объема операций произвольного доступа. В некоторых случаях SSD является единственно необходимой оптимизацией.