Перейти к содержанию

Рекомендуемые сообщения

Добрый вечер Гуру =)

 

Подскажите какую подсистему выбрать для 2.0 с товаром тыс в 12 со временем может вырости до 25 и категориями штук 100 примерно.

 

Начал гуглить и тут столкнулся что кто-то хвалит одно кто-то другое.

 

Сейчас имею базу в innobd пока к серваку не лез все стоково, но имею задержки 3-5 сек при обращении к странице.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Сейчас имею базу в innobd пока к серваку не лез все стоково, но имею задержки 3-5 сек при обращении к странице.

1. Дальше будет только хуже. Так как базовые конфиги даже на VPS заточены под более менее быструю работу с MyIsam.

2. Если почитаете внимательно референс Mysql про типы таблиц - то там достаточно ясно написано что MyIsam намного быстрее работает с операциями чтения. А чтение - как раз узкое место базы данных в интернет-магазине.

3. Прелесть InnoDb состоит в более надежном хранении данных, за счет транзакционных блокировок. Т.е. шансов покрашиться у таблицы InnoDB меньше. Но. Для того чтобы использовался транзакционный механизм в полной мере, необходимо чтобы база изначально была спроектирована с учетом транзакционных зависимостей между полями таблиц.

А есть ли такой механизм в Opencart? Правильно - нету. Сответственно использование InnoDb для Opencart - это редачйшая глупость. Большей глупостью может быть только кеширование результатов всех mysql запросов всредствами php.

И еще. InnoDb не подддерживают индексы FullText, с помощью которых в Opencart реализован поиск по описаниям товаров и выборка тегов.

  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Сейчас имею базу в innobd пока к серваку не лез все стоково, но имею задержки 3-5 сек при обращении к странице.

1. Дальше будет только хуже. Так как базовые конфиги даже на VPS заточены под более менее быструю работу с MyIsam.

2. Если почитаете внимательно референс Mysql про типы таблиц - то там достаточно ясно написано что MyIsam намного быстрее работает с операциями чтения. А чтение - как раз узкое место базы данных в интернет-магазине.

3. Прелесть InnoDb состоит в более надежном хранении данных, за счет транзакционных блокировок. Т.е. шансов покрашиться у таблицы InnoDB меньше. Но. Для того чтобы использовался транзакционный механизм в полной мере, необходимо чтобы база изначально была спроектирована с учетом транзакционных зависимостей между полями таблиц.

А есть ли такой механизм в Opencart? Правильно - нету. Сответственно использование InnoDb для Opencart - это редачйшая глупость. Большей глупостью может быть только кеширование результатов всех mysql запросов всредствами php.

И еще. InnoDb не подддерживают индексы FullText, с помощью которых в Opencart реализован поиск по описаниям товаров и выборка тегов.

 

Подскажите пожалуйста на сколько повышается процент возможности краша базы?

И есть ли возможность безболезненно и с наименьшими потерями перевести базу?

 

Сори за вопросы не гуглил, но может подтолкнете в нужное направление =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Подскажите пожалуйста на сколько повышается процент возможности краша базы?

И есть ли возможность безболезненно и с наименьшими потерями перевести базу?

 

Сори за вопросы не гуглил, но может подтолкнете в нужное направление =)

 

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

На моей памяти из 500-600 магазинов, которые я видел, таблицы крашились от силы пару раз.

 

Таблицы переводятся безболезненно - или гуглите скрипт.

Или в разделе операции в phpmyadmin потаблично руками.

  • +1 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

На моей памяти из 500-600 магазинов, которые я видел, таблицы крашились от силы пару раз.

 

Таблицы переводятся безболезненно - или гуглите скрипт.

Или в разделе операции в phpmyadmin потаблично руками.

 

Спасибо большое  за то что поделились опытом!

Буду сейчас переводить свое детище =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

На моей памяти из 500-600 магазинов, которые я видел, таблицы крашились от силы пару раз.

 

Таблицы переводятся безболезненно - или гуглите скрипт.

Или в разделе операции в phpmyadmin потаблично руками.

 

 

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

На сколкьо я понимаю они на работоспособность влиять не должны верно?

 

И второй вопросик по оптимизации mysql  накопал вот такие данные 

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

 

  1. key_buffer = 400M
  2. max_allowed_packet = 48M
  3. table_cache = 1024
  4. sort_buffer_size = 4m
  5. read_buffer_size = 4m
  6. read_rnd_buffer_size = 2m
  7. myisam_sort_buffer_size = 64m
  8. tmp_table_size = 96m
  9. query_cache_type = 1
  10. query_cache_size = 64m
  11. thread_cache_size = 16
  12. max_connections = 300
  13. wait_timeout = 120

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

 

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

На сколкьо я понимаю они на работоспособность влиять не должны верно?

 

И второй вопросик по оптимизации mysql  накопал вот такие данные 

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

 

  1. key_buffer = 400M
  2. max_allowed_packet = 48M
  3. table_cache = 1024
  4. sort_buffer_size = 4m
  5. read_buffer_size = 4m
  6. read_rnd_buffer_size = 2m
  7. myisam_sort_buffer_size = 64m
  8. tmp_table_size = 96m
  9. query_cache_type = 1
  10. query_cache_size = 64m
  11. thread_cache_size = 16
  12. max_connections = 300
  13. wait_timeout = 120

 

Все зависит от параметров сервера и входящего трафика.

кроме wait_timeout = 120 все остальные параметры настраиваются индивидуально. (я бы делал wait_timeout и вовсе 10-15 макс).

 

Также открою секрет. Одной настройкой сервера - вы ничего не добьетесь. На простом примере, если у вас широкая ровная дорога но медленная машина - вы быстрее не поедете, чем она может.

 

Настройка магазина под большой трафик и быструю работу - это несколько слоев оптимизации:

  • настройка железа
  • оптимизация базы
  • кеширование повторяющихся блоков магазина
  • полное кеширование html
  • анализ и устранение узких мест в модулях
  • устранение избыточного кеширования (например кеш сеопро на большом количестве товаров, работает на порядок медленнее чем 200-300 атомарных запросов в базу данных). А на примере 250 000 товаров и 10 000 производителях, кеш сеопро укладывает генерацию страницы секунд на 60
  • перенос всех повторяющихся тяжелых однотипных операций, не связаннх с фронтендом в cron.

И это я говорю только о лежащих на виду мероприятиях, которые необходимо сделать для уменьшения TTFB страниц.

Есть еще настройка отдачи статики.

 

Реструктуризация подключения внешних скриптов.

Реструктуризация подключения контента из CDN.

 

Использование собственного CDN для изображений.

 

Внедрение дополнительного слоя обработки для индексирования данных (sphinx), для быстрого релевантного поиска.

 

Также нужно проводить аудит по используемым модулям. Есть из ряда вон выходящие примеры, отключения которых дают + (2-3 секунды) скорости загрузки, просто на голом месте практически. Типа глупо написанные модули редиректов. Или кривые формирователи сео-ссылок. Про авторов и сами модули умолчу, дабы не разводить холивар.

 

Также во многих модулях присутствуют свои настройки кеширования, про которые многие забывают (Mega Filter Pro, SeoBlog и так далее).

 

Если совсем глубоко занииматься тюнингом. То можно еще отключать инкрементальный счетчик просмотра товаров, слежение за покупателями, перевести весь контент изображений на фронтенде в Lazy-load. Настроить Since-modified.

 

Вобщем если заморачиваться - можно придумать себе развлечений на пару-тройку месяцев легко.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

не удержался, стало интересно...

 

 

 

  • перенос всех повторяющихся тяжелых однотипных операций, не связаннх с фронтендом в cron.

 

можете навести пример, не совсем понятно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

не удержался, стало интересно...

 

 

можете навести пример, не совсем понятно.

карта сайта, yml, импорт товаров, массовые рассылки пользователям

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

 

 

Использование собственного CDN для изображений

А проку городить свой ? Щяс много компаний предоставляют готовые серверы

 

 

 

  • оптимизация базы

хотел спросить нюансы, но нашел интересное чтиво на ночь https://habrahabr.ru/post/116142/ =) 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А проку городить свой ? Щяс много компаний предоставляют готовые серверы

 

хотел спросить нюансы, но нашел интересное чтиво на ночь https://habrahabr.ru/post/116142/ =) 

 

Готовые сервисы - я и имел ввиду. Иногда использование CDN под картинки, намного экономически оправдано, чем покупка большого пространства на хостинге. + более быстрая доставка контента в регионы.

 

 

Чтиво - бредовое. Оптимизация базы - не должна приводить к денормализации дефолтной структуры, и вносить изменения в код базовых запросов, чтобы максимально исключить конфликты со сторонними дополнениями (больше ничего не расскажу, коммерческая информация).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Чтиво - бредовое. Оптимизация базы - не должна приводить к денормализации дефолтной структуры, и вносить изменения в код базовых запросов, чтобы максимально исключить конфликты со сторонними дополнениями (больше ничего не расскажу, коммерческая информация).

Хотя бы чтиво подкинет  :oops:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу

×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.