уменьшение нагрузки на бд

[freelancer]

тема подумать/обсудить.

 

сейчас двиг в стоке на 1 страницу товара выполняет ~100 запросов, 99% из которых повторяются для каждого товара

я думаю почему бы не сделать так что бы двиг выполнял ровно 1 запрос, который тащит инфу только о конкретном товаре.

прошу в этой теме не обсуждать page cache'и, тут суть в другом

 

[splka]

28 минут назад, nikifalex сказал:

нужен пример. непонятно про что речь. что будет в этом одном запросе?

Запрос продукта

[SooR]

1 час назад, freelancer сказал:

почему бы не сделать так что бы двиг выполнял ровно 1 запрос

Зачем это извращение? База должна работать и отрабатывать свое, нужен баланс количества/сложность, один запрос может положить базу, 1000 запросов могут отработать за 0.5 сек.

Чтобы убрать повторы одних и тех же запросов можно обойтись чем-то таким:

public function query($sql) {
  $cached = strtolower(substr(ltrim($sql), 0, 6)) == 'select';

  // not cached select from a variable
  if ($cached) {
    $cached = (false !== stripos($sql, 'from'));
  }

  if ($cached) {
    $key = md5($sql);

    if (isset($this->cache[$key])) {
      $query = $this->cache[$key];
    } else {
      $query = $this->driver->query($sql);

      $this->cache[$key] = $query;
    }
  } else {
    $query = $this->driver->query($sql);
  }

  return $query;
}

 

1 час назад, freelancer сказал:

прошу в этой теме не обсуждать page cache'и, тут суть в другом

 

Ну, если без кэшей, тогда только html5 history + ajax загрузка конкретного блока, того же контента, но и тогда одним запросом не обойтись.

[freelancer]

есть порядка 100 доменов на одном инстансе и у каждого порядка 100 поддоменов

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

[Yoda]

Нормальная мысль у frelancer, только не применима к опынкарпу, в силу  изначальной реляционной модели. 

Из того что я понял, речь идёт о преобразовании хранилища в объектную nosql структуру и дальнейшую работу с товаром как с готовой коллекцией. 

Можно в таком же ключе рассматривать промежуточное решение и остаться в рамках все той же mysql, грн использовать json коллекцию вместо всех этих таблиц special, review и так далее. И возможно это здравая мысль была с точки зрения оптимизации работы вывода товарных предложений. 

Но у нас очень много базовых сущностей и достаточно сложных связей между ними. И при таком варианте nosql формат при попытке сделать представление чуть иного вида, чем товар, сразу превратится в ад. Использовать оба подхода это неоправданная избыточность.

 

Ну и не стоит забывать про персистеность, крути верти, а информация хранится про деньги о деньгах. И все финансовые институты почему то предпочитают oracle или ms sql а не многодб или эластик.

[100napb]

10 hours ago, freelancer said:

почему бы не сделать так что бы двиг выполнял ровно 1 запрос, который тащит инфу только о конкретном товаре.

прошу в этой теме не обсуждать page cache'и, тут суть в другом 

 

Однако, по-прежнему нужно как-то выводить еще и хидеры\футеры, хлебные менюшки с корзинами и прочую вроде как повторяющуюся, но, все-таки, динамическую информацию. Пофантазируем, откуда их можно брать, если не из базы.

 

Ок, про query_cache со стороны мускуля мы забыли. Хотя можно точечно развесить на конкретные запросы при type = ondemand.. Так же как и про кеэширование страницы целиком.

Забыли про кэширование непосредственно результатов запросов в то или иное хранилище, будь то файлик, редис, или мемкеш.

Всякие server side include'ы ?

Инициализировать и хранить в глобальных переменных? ))))

А может, а может... аякс? Даешь, что бы менялось только то, что должно изменится. Главное сео не прибить случайно.

 

Последний вариант с аяксом, а? Этакий лэзи-лоад на весь движок

 

10 hours ago, SooR said:

База должна работать и отрабатывать свое, нужен баланс количества/сложность, один запрос может положить базу, 1000 запросов могут отработать за 0.5 сек.

Пожалуй, с этим можно только согласиться.

 

Вот, к примеру: 100, да бог с ним, пусть будет 200 запросов к базе на страницу. Вы писали, что на одном сервере БД крутится 100доменов. Допустим,

(1000 уников в сутки с домена * 10 страниц глубины просмотра с уника * 100доменов * 200 запросов к базе со страницы) / 24 часа / 60 минут / 60 секунд ~~~ 2300qps. Плюс еще боты - пусть столько же. Пусть будет почти придуманные 5kqps. Не ентерпрайз ведь даже или прям хайлоад. Да, круто. Да, от таких задач у большинства предлагаемых vps виртуальные ядра перегреются. Но это не проблема, согласитесь.

 

9 hours ago, freelancer said:

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

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

Слоулог тут советовать бессмысленно. performance_schema = on и explain для отладки: по самым медленным, по самым частым, по тем, что делают фуллскан, по тем, что вешают долгие блокировки, по тем, что свапятся на диск...