Меню
Что нового?

Что лучше для уменшения нагрузки и улучшения производительности.

dimitrius

Новичок
Что лучше для уменьшения нагрузки и улучшения производительности:
Вытянуть один раз все данные из таблицы перед for и передать их в массив и уже в for работать с массивом.
или каждый раз делать запросы к базе внутри цыкла?
ожидаемое количество итераций < 100
ожидаемое количество строк в базе < 1000
столбцов в базе < 10
вес поля < 5 байт

Почему возник вопрос, стала необходимость переделать фильтр в одной цмс, полез туда и увидел, что там однотипный запрос, только id разный, делается в цикле. Мне что-то кажется, что в этом случае лучше один раз вытянуть и работать с массивом, на оперативку это не должно повлиять. Или нет? если нет, то почему, как это вообще можно измерить?
 
Последнее редактирование:

dimitrius

Новичок
prolis написал(а):
зачем после запроса нужен массив и for, для каких вычислений? Эти вычисления так же можно возложить на БД
Нажмите для раскрытия...
Там используется подобие рекурсии - при неизвестном числе вход. параметров. Кроме того - переписывать весь скрипт у меня нет желания, он свою функцию исполняет, надо чуть откорректировать.
 
plusweb

plusweb

Новичок
Может, просто посмотреть распределение ресурсов и сделать выбор переложить нагрузку на скрипт или на базу, потому как это разные процессы на сервере.
Очевидно, если у тебя огромные таблицы, да еще с частыми обращениями (например аякс-запросы по таймауту) то лучше как можно больше на пхп свалить;
а если у основная нагрузка - сложные вычисления (например обработка графики, сложные математические вычисления ) с редким обращением к БД видимо нужно скриптовать мускуль запросы, чтобы не тратить ресурс на обработку данных.
Тоже самое применимо и к самим запросам - так же есть нюансы. Объемы данных, вычислительная мощность, объем кэша, и т.д. - влиеяет на построение обращений.
 
Последнее редактирование:

dimitrius

Новичок
почитав эту книгу http://it-ebooks.info/book/676/ понял почему разработчик так сделал. Если товаров будет очень много, то дешевле делать много запросов к БД с ID, чем выборку многих строк в самой БД
 

dimitrius

Новичок
Redjik написал(а):
и?
Нажмите для раскрытия...
Rows examined and access types

Many high-performance applications use join decomposition. You can decompose a join
by running multiple single-table queries instead of a multitable join, and then performing
the join in the application
Why on earth would you do this? It looks wasteful at first glance, because you’ve increased
the number of queries without getting anything in return. However, such restructuring
can actually give significant performance advantages:
• Caching can be more efficient. Many applications cache “objects” that map directly
to tables. In this example, if the object with the tag mysql is already cached, the
application can skip the first query. If you find posts with an ID of 123, 567, or
9098 in the cache, you can remove them from the IN() list. The query cache might
also benefit from this strategy. If only one of the tables changes frequently, decomposing
a join can reduce the number of cache invalidations.
• Executing the queries individually can sometimes reduce lock contention.
• Doing joins in the application makes it easier to scale the database by placing tables
on different servers.
• The queries themselves can be more efficient. In this example, using an IN() list
instead of a join lets MySQL sort row IDs and retrieve rows more optimally than
might be possible with a join. We explain this in more detail later.
• You can reduce redundant row accesses. Doing a join in the application means you
retrieve each row only once, whereas a join in the query is essentially a denormalization
that might repeatedly access the same data. For the same reason, such restructuring
might also reduce the total network traffic and memory usage.
• To some extent, you can view this technique as manually implementing a hash
join instead of the nested loops algorithm MySQL uses to execute a join. A hash
join might be more efficient. (We discuss MySQL’s join strategy later in this
chapter.)
и многое другое по ходу книги
акцентирую внимание на дешевле, а не лучше, удобней и т.д.
и еще поправлю, что под массивом я имел ввиду не массив индексов, а массив данных карточек товара - не уточнил в начальном посте.
 
Последнее редактирование:

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Ваще-то в процитированном фрагменте речь идёт скорее о том, чтобы сделать два запроса: один к первой таблице, второй --- ко второй используя "in (список id из первого запроса)". Уж делать запросы в цикле авторы не совсем идиоты советовать.
 

dimitrius

Новичок
Sad Spirit написал(а):
Ваще-то в процитированном фрагменте речь идёт скорее о том, чтобы сделать два запроса: один к первой таблице, второй --- ко второй используя "in (список id из первого запроса)". Уж делать запросы в цикле авторы не совсем идиоты советовать.
Нажмите для раскрытия...
как-то не совсем так, говорится, что лучше сделать несколько простых запросов чем один сложный и обрабатывать на стороне скрипта. а также по книге рассчитывают стоимость сложных запросов, где прослеживается, что дешевле сделать несколько итераций в цикле чем делать сложный запрос. Отсутствует только одно, стоимость обращения к базе.
 
Redjik

Redjik

Джедай-мастер
Я не думал, что такая книга может кому то во вред пойти...
 
  • Like
Реакции: Gas

dimitrius

Новичок
Redjik написал(а):
Я не думал, что такая книга может кому то во вред пойти...
Нажмите для раскрытия...
возможно, если не сложно, приведите аргументы, буду очень благодарен. А вообще, протестирую сам с большой базой и все будет видно по времени выполнения скрипта.
 

dimitrius

Новичок
Протестировал. И таки да, работает медленнее.((((( а я думал понял смысл.
 
Войдите или зарегистрируйтесь для ответа.
Сверху