Вопрос об освобождении памяти в php-скрипте - PullRequest
1 голос
/ 03 августа 2009

Я только что видел это в сценарии

mysql_free_result($rawdb);

Я видел это где-то в скрипте, он выполнял запрос mysql и сохранял результаты в массиве, сразу после добавления в массив он запускал то, что, как я полагаю, свободно, - это память, используемая из запроса mysql.

Я просто прошу проверить, это хорошая идея, чтобы сделать это? У меня есть пара запросов MySQL, которые возвращают большой результат, который сохраняется в массиве, я должен запустить этот код после него?

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

Ответы [ 6 ]

2 голосов
/ 03 августа 2009

Я думаю, что это хорошая практика - поместить на уровень абстракции данных, так как это делает его хорошим гражданином с обработкой памяти. Тем более, что большого количества PHP-кода нет. : - /

Проблема использования памяти была намного хуже в PHP 4, чем в 5, но она все еще может быть проблемой. Если вам нужно постоянно увеличивать максимальный объем памяти, доступный для вашего сценария PHP (по умолчанию это 8 МБ, но в большинстве сред, которые я использую, это составляет 64 МБ), то вам, вероятно, следует подумать о том, как ваш сценарий использует и использует память слишком много. Использование mysql_free_result() - это одна часть этого арсенала, но само по себе это довольно бессмысленно. Обработка огромных наборов данных может быть значительно более эффективной, если вы используете mysql_unbuffered_query() и обрабатываете каждую строку, когда извлекаете ее с помощью mysql_fetch(). Я видел, что возможности сценариев для обработки данных сильно увеличиваются при перезаписи для использования этого подхода.

2 голосов
/ 03 августа 2009

Я бы не волновался об этом. Все ресурсы результатов освобождаются в конце скрипта, и, если у вас нет проблем с памятью при выполнении запросов с большими наборами результатов, разница будет незначительной.

Тем не менее, если бы я читал ваш код и увидел mysql_free_result, я бы точно знал, что вы не собираетесь использовать этот ресурс где-то еще в коде, так что это может добавить немного читабельности .. .

1 голос
/ 03 августа 2009

Также в сознании производительности среда это хорошая практика сбросить большие сессии и переменные когда закончили с ними?

Обратите внимание, что если вы удалите переменные из $_SESSION, вы фактически удалите их из сеанса: их не будет в следующий раз, когда ваш пользователь зайдет на страницу вашего сайта.

Итак, вы можете быть осторожны с этой идеей: удаляйте данные из $_SESSION только тогда, когда они вам больше не нужны.

О unset данных и / или использовании таких функций, как mysql_free_result: учитывая, что ваши скрипты (я полагаю, поскольку PHP предназначен для веб-разработки, и пользователи не будут часами ждать загрузки страниц) , работающий всего несколько сотен миллисекунд, освобождение памяти таким способом, вероятно, немного излишним: если вы не получаете ошибок, связанных с * 1015, вам, вероятно, не следует беспокоиться.

1 голос
/ 03 августа 2009

Об этом говорится в документации по PHP API . В зависимости от вашего варианта использования (то есть размера результатов, которые вы извлекаете), mysql_free_result() может повысить или понизить производительность. Как говорит комментатор в нижней части этой ссылки, позвоните memory_get_usage(), чтобы получить представление о том, следует ли освобождать результат или нет. Ничто не сравнится с проверкой вашего ресурса.

0 голосов
/ 03 августа 2009

Страница руководства по PHP для этой функции отвечает на большинство ваших вопросов:

http://us.php.net/manual/en/function.mysql-free-result.php

0 голосов
/ 03 августа 2009

Из руководства :

mysql_free_result() нужно только называется, если вы обеспокоены тем, как много памяти используется для запросов которые возвращают большие наборы результатов. Все связанная память результатов автоматически освобождается в конце выполнение скрипта.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...