Является ли file_exist () в PHP очень дорогой операцией?

Поскольку ваш веб-сервер уже будет выполнять множество (эквивалентных) операций file_exists () в процессе отображения вашей веб-страницы, повторный запуск вашего сценария, вероятно, не окажет заметного влияния. Веб-сервер, вероятно, сделает как минимум:

• по одному для каждого подкаталога корневого веб-каталога (для проверки наличия и наличия символических ссылок)
• один для проверки наличия файла .htaccess для каждого подкаталога корневого веб-каталога
• один для существования вашего скрипта

Это не означает, что PHP мог бы сделать больше из них.

file_exists () сам по себе не медленный. Настоящая проблема заключается в том, как сконфигурирована ваша система и где есть узкие места в производительности. Помните, что базы данных тоже должны хранить данные на диске, поэтому в любом случае вы можете столкнуться с дисковой активностью. С другой стороны, и базы данных, и файловые системы обычно имеют некоторую форму прозрачного кэширования для оптимизации повторного доступа.

Вы можете легко пойти по любому пути, поскольку есть вероятность, что узкое место в производительности будет где-то еще. Единственное место, где я вижу, что это очевидный выбор, - это если вы находитесь на каком-то перепроданном общем хостинге, где есть масса конфликтов за диск, но, возможно, доступ к базе данных находится в отдельном кластере и быстрее (или наоборот).

Раньше я сохранял метаданные изображения в базе данных (включая его имя), чтобы мы могли генерировать полезную статистику. Что еще более важно, для хранения данных изображения (не самого файла, а только метаданных) используется способствует переменам. Что делать, если в будущем вам нужно «утвердить» изображение, или вы захотите удалить его, не удаляя файл?

В соответствии с аватаром "по умолчанию" ... ну, если запись для этого пользователя не найдена, просто используйте значение по умолчанию.

В любом случае, file_exists () или db, это не должно стать проблемой. Однако одно решение гораздо более расширяемо.

Как и то, что говорили другие плакаты, результат file_exists () автоматически кэшируется PHP для повышения производительности.

Однако, если вы уже читаете информацию о пользователе из базы данных, вы можете сохранить ее там. Если пользователю разрешен только один аватар, вы можете просто сохранить один бит в столбце для «имеет аватар» (1/0), а затем иметь имя файла, такое же, как идентификатор пользователя, и использовать что-то вроде SELECT CONCAT(IF(has_avatar, id, 'default'), '.png') AS avatar FROM users

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

Если производительность - ваше единственное соображение, file_exists () будет намного дешевле, чем поиск в базе данных.

В конце концов, это всего лишь поиск в каталоге с помощью системных вызовов. После первого выполнения сценария большая часть соответствующего каталога будет кэширована в хранилище, поэтому фактических операций ввода-вывода будет очень мало, а «file_exists ()» является настолько распространенной операцией, что она и лежащие в ее основе системные вызовы будут сильно загружены. оптимизирован для любой распространенной комбинации php / os.

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

В реальном тестировании производительности вы обнаружите, что file_exists работает очень быстро. Как бы то ни было, в php, когда один и тот же URL-адрес дважды указан как "stat", второй вызов просто извлекается из внутреннего кеша статистики php.

И это только в области запуска php. Даже между запусками файловая система / os будет стремиться агрессивно помещать файл в кеш файловой системы, и если файл достаточно мал, не только тест на существование файла выйдет прямо из памяти, но и весь файл тоже.

Вот некоторые реальные данные, подтверждающие мою теорию:

Я просто проводил тесты производительности утилит командной строки linux «find» и «xargs». В процессе я выполнил тест на наличие файла для 13000 файлов, по 100 раз каждый, менее чем за 30 секунд, так что в среднем получается 43000 статистических тестов в секунду, поэтому уверен, что в мелком масштабе это будет медленно, если вы сравните его, чтобы сказать, нужно разделить 9 на 8, но в реальном сценарии вам нужно будет сделать это много раз ужасный, чтобы увидеть заметную проблему с производительностью.

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

По крайней мере, с PHP4 я обнаружил, что вызов file_exists определенно убивал наше приложение - он многократно делался глубоко в библиотеке, поэтому нам действительно пришлось использовать профилировщик, чтобы найти его. Удаление вызова увеличило вычисление некоторых страниц в десятки раз (вызов выполнялся очень часто).

Возможно, что в PHP5 они кешируют file_exists, но, по крайней мере, с PHP4 это было не так.

Теперь, если вы не в цикле, очевидно, что file_exists не будет иметь большого значения.