realitycramp
  • 0
Новичок

Масштабирование сайта электронной коммерции WP

  • 0

В связи с этим вопросом.

Любые рекомендации по инструментам, плагинам для оптимизации крупного сайта электронной коммерции на WP. В настоящее время набралось 1000 предметов и ожидается еще 5000 предметов. Кажется, что оптимизация будет отличаться от стандартного блога, обслуживающего тысячи пользователей. Количество магазинов, разрабатываемых на WP, увеличивается, и сбор пакета оптимизаций может оказаться полезным.

ММ/RC

Share
  1. Моя первоначальная мысль заключалась в том, что вы захотите сосредоточиться на БД. Несколько быстрых заметок (позже постараюсь расширить). Смотрите, как и сколько опций хранится в БД. Также посмотрите, как вы можете индексировать параметры, по которым вы хотите отсортировать.

    • 0
  2. Я разработал сайт электронной коммерции с 55 000 продуктов, используя WordPress с плагином Shopp, и могу поделиться тем, что я сделал с MySQL, чтобы повысить производительность, YMMV и некоторые (или все) из них могут не применяться к вашей ситуации.

    Определите, насколько вам нужно увеличить буферы/кэши, посмотрев на вывод команды sql «show status» — есть инструменты, которые упорядочивают этот вывод, который может быть полезен, я часто просто использую phpmyadmin, чтобы получить представление. http://blog.mysqltuner.com/ также является удобным ресурсом и утилитой.

    Убедитесь, что кеш запросов включен и что он достаточно велик, чтобы иметь очень низкое число нехватки памяти. Убедитесь, что количество чтений ключей не слишком велико (это относительное значение), в этом может помочь увеличение key_buffer_size. Убедитесь, что количество создаваемых временных таблиц невелико, уменьшите это число, увеличив tmp_table_size.

    Включите журнал медленных запросов и регистрируйте медленные запросы, повторно запускайте эти запросы вручную с операторами объяснения, добавляйте индексы, изменяйте типы столбцов и т. д. по мере необходимости. Для одного запроса мы получали безумные операторы объяснения (например, при сравнении гораздо большего количества строк, чем «должно было»), обновление до более новой версии MySQL привело к тому, что тот же самый запрос был намного лучше оптимизирован (и намного быстрее) MySQL сам.

    Если вы используете полнотекстовое индексирование, я не верю, что таблицы InnoDB — это вариант — просто не обновляйте продукты в часы пик. Если ваш пакет электронной коммерции поддерживает это, вы можете свести к минимуму нарушение работы клиентов (производительность или иное), внеся изменения на промежуточный сервер, а затем переместив со сцены только таблицы продуктов с дампом и загрузив их в рабочую среду — это не будет работать без дополнительной работы для однако остальная часть вашей установки WordPress.

    Если дизайн вашего сайта и UX могут его поддерживать, направляя пользователей в режим «просмотра» по сравнению с режимом «поиска» (например, кликая по сайту или вводя поисковые запросы в поле поиска), вы можете воспользоваться очень простой базой данных. кэширование уровня и уровня WordPress.

    Предварительно загрузите свои кэши — простое кэширование, такое как кэширование запросов и кэширование на уровне WordPress, также может быть предварительно загружено путем сканирования вашего сайта с помощью wget. Вы также можете предварительно загрузить кеш для поиска, используя поведение пользователя при поиске (через ваши журналы) и повторно получая эти запросы, когда вам нужно заполнить кеши.

    • 0
  3. Мне был любопытен мой собственный комментарий, и я кое-что читал, вот где я нахожусь.

    Во- первых, я бы попробовал W3 Total Cache. Кроме того, установите расширение APC PHP на свой сервер и настройте W3 Total Cache для его использования. Он будет использовать APC для кэширования объектов базы данных, PHP и даже поможет минимизировать ваши CSS и JS. Это может дать достаточно. Особенно, если вы уже включили некоторый кеш MySQL. W3 Total Cache также может работать с Memcache в качестве кэширующего бэкенда.

    Для базы данных кэширование запросов очень полезно. Я нашел эту ссылку, и он объясняет, как он кое-что сделал для своего блога MU. Цитировать:

    Кэш запросов — это изящная маленькая функция в MySQL, где он сохраняет — в выделенной области в основной памяти — любые результаты запроса для таблицы, которая в последнее время не менялась.

    То есть, предположим, что поступил запрос на получение определенной строки в таблице — и эта таблица в последнее время не подвергалась каким-либо изменениям — и кэш не заполнялся, требуя очистки/очистки — запрос/ данные могут быть удовлетворены из этого кэша. Главным преимуществом здесь, конечно же, является удовлетворение запроса — базе данных не нужно обращаться к диску (который, как правило, является самой медленной частью системы), и она может быть немедленно удовлетворена.

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

    Он также говорит о типах таблиц и использовании MyISAM поверх InnoDB для таблиц, в основном предназначенных только для чтения, хотя это его рассуждение немного ориентировано на MU, это может быть полезно.

    Что касается настройки индексов. Если у вас их много, они могут замедлять вставку и занимать больше места на диске. Но поскольку я не думаю, что на регулярной основе будет добавляться большое количество продуктов, я думаю, что это приемлемо. А место на диске дешевое…

    • 0

Оставить ответ

You must login to add an answer.