mysql_free_result и mysql_close? В каких случаях это нужно делать а в каких не обязательно.
Если я обновляю одну табличку каждую минуту надо ли запрывать и чистить память каждый раз?
Спустя 4 минуты, 14 секунд (12.03.2012 - 17:30) vital написал(а):
Надо оторвать руки.
Спустя 9 минут, 30 секунд (12.03.2012 - 17:39) php-down написал(а):
Мне? Зачем? Может еще пригодятся. Ну ладно так и быть одну бери.
Спустя 1 час, 4 минуты, 56 секунд (12.03.2012 - 18:44) sergeiss написал(а):
php-down - не знаю, почему у тебя такой вопрос возник 
Но ответ однозначный: не надо так делать! Будешь попусту "дёргать" БД, что приведет к бОльшей нагрузке на неё и к бОльшему времени выполнения скрипта.
Но ответ однозначный: не надо так делать! Будешь попусту "дёргать" БД, что приведет к бОльшей нагрузке на неё и к бОльшему времени выполнения скрипта. Спустя 1 минута, 27 секунд (12.03.2012 - 18:45) Invis1ble написал(а):
Можно, имхо, чистить память если скрипт например зациклен и никогда не останавливается. А так - не нужно.
Спустя 1 час, 55 минут, 10 секунд (12.03.2012 - 20:41) twin написал(а):
Ну чему человека учите...
Это нужно и очень полезно делать на высоконагруженных проектах с правильной архитектурой. Смысл прост. Первым делом стараемся сделать все необходимые запросы, вытаскиваем результат на сторону PHP, очищаем память, рвем соединение и дальше спокойно обрабатываем полученный результат. Зачем держать открытым коннект и занимать память, пока молотит скрипт. При больших нагрузках это может привести к плачевным результатам.
Опять же нужно учитывать два момента. Это совсем неоправдано когда:
1. После получения результата обработки почти нет и скрипт работает очень недолго. Тут нет смысла делать дополнительных движений, сборщик мусора справится сам.
2. Если посещаемость предполагается небольшой. Тут тоже эти движения только загромождают код.
Т ак что все как обычно. Дорога ложка к обеду. Все хорошо на своих местах.
Это нужно и очень полезно делать на высоконагруженных проектах с правильной архитектурой. Смысл прост. Первым делом стараемся сделать все необходимые запросы, вытаскиваем результат на сторону PHP, очищаем память, рвем соединение и дальше спокойно обрабатываем полученный результат. Зачем держать открытым коннект и занимать память, пока молотит скрипт. При больших нагрузках это может привести к плачевным результатам.
Опять же нужно учитывать два момента. Это совсем неоправдано когда:
1. После получения результата обработки почти нет и скрипт работает очень недолго. Тут нет смысла делать дополнительных движений, сборщик мусора справится сам.
2. Если посещаемость предполагается небольшой. Тут тоже эти движения только загромождают код.
Т ак что все как обычно. Дорога ложка к обеду. Все хорошо на своих местах.
Спустя 3 часа, 9 минут, 53 секунды (12.03.2012 - 23:50) inpost написал(а):
Когда долгая обработка между окончанием запросов к БД и окончанию работы скрипта: - убиваем коннект. Чтобы освободить очередь для других соединений с БД.
Когда скрипт обрабатывается долгое время, допустим пару минут готовит списки для общей загрузки. Допустим, у меня пересчёт статистики за пару дней работает около 30 секунд, убил коннект, отработал скрипт, ещё один коннект, только уже для добавления в БД.
Кроме того долгая работа может быть и будет с работой GD библиотеки, где так же НЕОБХОДИМО обрывать коннекты, а когда работа с графикой будет завершена, тогда снова открыть соединение.
Почему? Да всё просто, у мускула есть очередь, и 10-20 открытых соединений положат сайт, остальные запросы будут ждать, пока освободится место. Читайте FAQ разницу в настройке MySQL. Точное название, где используется 10 открытых соединений вместо 100 дать не могу, не помню
Что насчёт второго - освобождать ресурсы надо, когда скрипт ещё долгое время работать будет, а из БД загрузил много данных. Тут поделиться практикой не могу, не было такого, чтобы ресурсы забивали всю память на моём сайте.
Ну, или, как сказали выше, в случае цикличности, иначе будет утечка памяти.
Когда скрипт обрабатывается долгое время, допустим пару минут готовит списки для общей загрузки. Допустим, у меня пересчёт статистики за пару дней работает около 30 секунд, убил коннект, отработал скрипт, ещё один коннект, только уже для добавления в БД.
Кроме того долгая работа может быть и будет с работой GD библиотеки, где так же НЕОБХОДИМО обрывать коннекты, а когда работа с графикой будет завершена, тогда снова открыть соединение.
Почему? Да всё просто, у мускула есть очередь, и 10-20 открытых соединений положат сайт, остальные запросы будут ждать, пока освободится место. Читайте FAQ разницу в настройке MySQL. Точное название, где используется 10 открытых соединений вместо 100 дать не могу, не помню
Что насчёт второго - освобождать ресурсы надо, когда скрипт ещё долгое время работать будет, а из БД загрузил много данных. Тут поделиться практикой не могу, не было такого, чтобы ресурсы забивали всю память на моём сайте.
Ну, или, как сказали выше, в случае цикличности, иначе будет утечка памяти.