У меня есть настройка nginx + php-fpm + apc. Нет БД. В папке данных у меня есть простой скрипт php, который при вызове с параметром имени файла проверяет, существует ли файл, если он существует, он отдает его, если нет, он загружает его в ту же папку, а затем отдает. Скорость очень важна, теперь для вывода файла в браузер требуется 70 мс.
Файлы представляют собой изображения размером 1-2кб. При такой скорости через несколько месяцев в этой папке будет несколько тысяч изображений. И этот скрипт будет вызываться десятки раз в секунду (а может и больше). Так что я боюсь, что сервер начнет бороться.
Вы можете мне посоветовать:
-Твики Nginx
-Системные настройки
-Можно ли время от времени проводить какое-либо обслуживание жесткого диска?
Что еще вы посоветуете в этой ситуации?
Оперативная память: 386 МБ (с возможностью обновления) ЦП: Xeon E5506 @ 2,13 ГГц CentOS 6
Обновление # 1 Интересная идея: не проверять PHP, существует ли файл - пусть nginx попытается обслужить файл напрямую, а затем вернется к PHP в качестве обработчика 404. Если вы оставите nginx делать свое дело, он должен легко обслуживать ~ 1000 изображений 2 КБ / сек без каких-либо настроек.
Не проверяйте PHP, существует ли файл - пусть nginx попробует обработать файл напрямую, а затем вернется к PHP в качестве обработчика 404. Если вы оставите nginx делать свое дело, он должен легко обслуживать ~ 1000 изображений 2 КБ / сек без каких-либо настроек.
Трудно быть конкретным, поскольку для этого потребуется гораздо больше информации. Если изображения не генерируются динамически при каждом запросе, имеет смысл не передавать их через скрипт каждый раз, т.е. делать их статическими. Если изображения не меняются часто, я бы попытался кэшировать большинство из них в памяти. Вы можете избежать частого дискового ввода-вывода, так как многие маленькие изображения могут быть помещены в память из-за того, что они такие маленькие.
У нас очень хороший опыт использования Лак для этого. Это так называемый обратный прокси-кеш, что означает, что он будет получать входящие запросы от клиентов, проверять свой кеш, а затем обслуживать запрошенный объект непосредственно из кеша или сначала получать его с внутреннего сервера nginx. Varnish может легко обрабатывать многие тысячи запросов в секунду с очень низким использованием ЦП и операций ввода-вывода. Время отклика очень быстрое. Время отклика составляет 20–30 мс, и половина этого времени приходится на электроны, чтобы путешествовать туда и обратно.
Поместите Varnish перед nginx и убедитесь, что каждое уникальное изображение имеет уникальный URL. Поместите несколько гигабайт оперативной памяти на свой сервер и настройте Varnish для использования большей ее части для своего кеша. Если ваши изображения имеют размер 1-2 КБ, 1 ГБ или ОЗУ может кэшировать около 500-1000 изображений. Varnish будет хорошо работать со своим набором правил по умолчанию, однако его можно легко настраивать, что дает ему преимущество перед большинством других прокси-кешей.
Убедитесь, что ваше приложение не устанавливает файлы cookie в домене, или настройте Varnish для удаления файлов cookie для URL-адресов, которые указывают на изображения, поскольку оно будет проявлять осторожность и не кэшировать запрос, если он содержит файлы cookie. Кроме того, пусть ваше приложение возвращает заголовки с истекшим сроком действия (см. «Cache-Control: max-age»), которые достаточно далеко в будущем, чтобы сделать кеширование полезным. Легко установить максимальный возраст в недель, и если объект должен быть истек раньше, ваше приложение может очистить объект из кеша Varnish или просто предоставить новое изображение по новому URL-адресу.
Честно говоря, если вы полагаетесь на базовую ОС, чтобы узнать, существует ли файл ... у вас будут проблемы, когда вы достигнете большого количества файлов. Чем больше файлов у вас в каталоге ... тем дольше длится такой поиск. Различные форматы файловых систем могут лучше справиться с этой задачей ... но это все еще требует больших временных затрат.
При проверке существования файла ... файловая система будет проверять каждый файл сверху вниз, пока не найдет тот, который вы ищете. с ext2 (например) Если вы ищете zzzz ... вы должны просмотреть каждый файл от a -> zzzz, прежде чем найдете его ..
Было бы лучше сделать длинный список настроек, чтобы обойти эту кучу головной боли. то есть кеширование результатов поиска ... ограничение количества файлов в каталогах ... анализ файлов в несколько каталогов ... и т. д.