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

Тема в разделе "OpenCart", создана пользователем ZloyShadow, 24 фев 2013.

  1. ZloyShadow

    ZloyShadow

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

    Baco Антихронофаг Команда форума

    Регистрация:
    9 окт 2012
    Сообщения:
    648
    Симпатии:
    327
    Ну... 500 К товара, это уже не ИМ, это портал получается, прям гиперинтернет магазин... если вы на опенкарте планируете плятформу развернуть, то больше внимания следует уделить к оптимизации запросов в БД и самого кода магазина, думаю алгоритм кеширования надо индивидуально писать, на этом сайте (http://глобальные-ресурсы.рф) я оптимизировал движок под 30К...
    P.S. Дизайнерское оформление - ещё впереди...
     
  3. ZloyShadow

    ZloyShadow

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

    nix php, MySQL, UNIX, MikroTik ROSAPI

    Регистрация:
    16 янв 2013
    Сообщения:
    1.000
    Симпатии:
    889
    Если 1 секунда с таким кк-вом то че тут отимизировать?
    Посмотри сначала что больше грузится, если БД спокойно дишит то нечиво ее настраивать
    вобшем всегда помогает увеличивания параметра query_cache_size
    вобшем здесь нужно смотреть, вести логи и тогда делать настройку

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

    P.S. С юниксами помогу настроить
    --- добавлено: 24 фев 2013 в 14:12 ---
    для 30к оптимизировать то и ненадо)
    вот без оптимизации кода http://www.10tochka.org.ua/

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

    ZloyShadow

    Регистрация:
    12 фев 2013
    Сообщения:
    104
    Симпатии:
    6
    Да нет, про параметры то я сам знаю уже давно) Меня интересует не у кого не было практики создания сайта на 250к+ позиций на опенкарте?

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

    nix php, MySQL, UNIX, MikroTik ROSAPI

    Регистрация:
    16 янв 2013
    Сообщения:
    1.000
    Симпатии:
    889
    Около 100к делал
    обошолся настройкой мускуля и подключениям APC
     
  7. ZloyShadow

    ZloyShadow

    Регистрация:
    12 фев 2013
    Сообщения:
    104
    Симпатии:
    6
    В винду есть из тех кто поддерживает 5.4 PHP вот такой аккселератор -
    eAccelerator

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

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


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

    nix php, MySQL, UNIX, MikroTik ROSAPI

    Регистрация:
    16 янв 2013
    Сообщения:
    1.000
    Симпатии:
    889
    Memcached ето и есть оптимизация БД )
    Вот что тебе нужно для него
    APC,eAccelerator на твой вибор, я остановился на APC

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

    ZloyShadow

    Регистрация:
    12 фев 2013
    Сообщения:
    104
    Симпатии:
    6
    С еаккселератором пролёт, есть Xcache и APC. Сейчас буду оба тестировать, какие есть параметры у APC или апц просто как модуль подключить?
     
  10. sitecreator

    sitecreator

    Регистрация:
    1 фев 2013
    Сообщения:
    291
    Симпатии:
    65
    Несколько лет работаю с APC на FreeBSD на выделенном сервере. ничего не настраивал в APC. Да и нужды не было.
     
  11. sanyaberkut

    sanyaberkut

    Регистрация:
    11 дек 2012
    Сообщения:
    94
    Симпатии:
    19
    В качестве эксперемента пробовал использовать другой драйвер для работы с базой данных MySQLi магазин был небольшой, но реально на глаз відно біло увеличение производительности, другие замеры не делал, но страничка реально в раза 2 быстрее загружалась
    Вот можно попробовать
     
  12. alexsofdev

    alexsofdev

    Регистрация:
    13 янв 2013
    Сообщения:
    239
    Симпатии:
    46
    Вставлю и свои пять копеек, так как чуствую себя экспертом в оптимизации пых\мускуль решений.

    В качестве оси рекомендую 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 со сведениями о проблемах.

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

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

    sitecreator

    Регистрация:
    1 фев 2013
    Сообщения:
    291
    Симпатии:
    65
    А всегда ли нужна самая свежая MySQL? Например, 5.6 в реальности по производительности хуже на 12% чем 5.5 несмотря на заверения производителя об обратном.
     
  14. nix

    nix php, MySQL, UNIX, MikroTik ROSAPI

    Регистрация:
    16 янв 2013
    Сообщения:
    1.000
    Симпатии:
    889
    sitecreator, Верно, не нужна самая последняя. Нужна стейбл версия!)
    А обновиться можно на любой ОСи
     
  15. Luxy

    Luxy

    Регистрация:
    24 янв 2013
    Сообщения:
    175
    Симпатии:
    91
    А я залила магаз в 30К товаров на хостинг за 3 бакса и все нормально грузится без оптимизации менее секунды. Что я делаю не так?))
     
  16. alexsofdev

    alexsofdev

    Регистрация:
    13 янв 2013
    Сообщения:
    239
    Симпатии:
    46
    Не смотришь статистику посещений :Smile: Я залью сейчас тримульйон товаров в магазин, который никто не использует кроме меня. И буду радоваться скорости загрузки ГЛАВНОЙ страницы.
     
  17. nix

    nix php, MySQL, UNIX, MikroTik ROSAPI

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

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

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

    alexsofdev

    Регистрация:
    13 янв 2013
    Сообщения:
    239
    Симпатии:
    46
    Ты наверное имеешь в виду SSD? SAS не панацея в общем-то.



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

    nix php, MySQL, UNIX, MikroTik ROSAPI

    Регистрация:
    16 янв 2013
    Сообщения:
    1.000
    Симпатии:
    889
    Нет не т и еще раз нет! SSD ето твердительный диск.
    SAS ето почти тот же жосткий тока оборотов больше и скорость передачи больше, обычно нормальные люди в качестве хранилища БД ставлять SAS диск
     
  20. alexsofdev

    alexsofdev

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