Используются следующие переменные PHP:

upload_max_filesize - Максимальный размер файла, загружаемого с помощью PHP (используя закачку через HTTP)

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

memory_limit - ограничение памяти для отдельного PHP-сценария

Таким образом, чтобы поддерживать закачку файлов до, скажем, 50MB, вы должны задать что-то наподобие:

post_max_size = 51M

upload_max_filesize = 50M

Переменную memory_limit оценить сложнее, так как она зависит от того, что сценарий делает с файлом. Например, у roundcube была известна ошибка с объемом памяти, потребляемой вложением, но обычно приложения не так требовательны.

Документация по PHP рекомендует memory_limit больлше, чем post_max_size, так что, как правило, значения начиная с 16 + post_max_size (16MB – это значение по умолчанию) должно быть достаточно. Тем не менее, мы думаем, что документация неправа / устарела. Чтобы работать с тяжелыми приложениями можно начать со значения 16MB и начать разбираться уже в том случае, если ничего не работает. После изучения error_log станет понятно, хватает или нет сценарию памяти:

[warn] mod_fcgid: stderr: PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 4864 bytes)…

В наших тестах мы поняли, что простые способы управления файлами в веб-приложениях могут загружать большие файлы, без проблем используя значение memory_limit по умолчанию – 16 MB. (Протестировано на RHEL с php 5.1, смотрите здесь: http://www.php.net/manual/en/features.file-upload.php#78017)

Другие праметры

Директива apache LimitRequestBody тоже может ограничивать загрузку больших файлов. Тем не менее, ее значение по умолчанию 0 и она обычно отсутствует в httpd.cond. Таким образом, по умолчанию ограничения отсутствуют.

Документация по всем вышеизложенным функциям доступна на сайтах php.net и httpd.apache.org.

.

Ранее:  PHP, FCGID и Apache – неразбериха из-за ограничений загрузки,

PHP, FCGID и Apache, Зависимые от времени параметры

.

.

Источник:   http://blog.angulosolido.pt/2010/07/php-fcgid-and-apache-confusion-of.html

Следующие переменные PHP принимают участие:

max_execution_time – этот параметр устанавливает максимальное процессорное время в секундах, отведенное на исполнение сценария.

max_input_time – этот параметр устанавливает максимальное время в секундах, в течение которого сценарий обрабатывает входящие данные, типа POST, GET и закачка файла.

Эти переменные могут быть включены в php.ini файле виртуального хоста, например:

/home/DOMAINNAME/etc/php/php.ini

Точный путь к каждому php.ini зависит от вашей системы.

Следующие переменные Apache и mod_fcgid также задействованы и должны быть установленны в директиве виртуального хоста в httpd.conf:

Timeout – переменная Apache, которая используется для различных вещей, включая «время ожидания выхода из сценария CGI». По умолчанию это 300 секунд и используется на уровне apache, независимо от настройки PHP или других сценариев.

IPCCommTimeout/FcgidIOTimeout – этот параметр предназначен для mod_fcgid и не заменяет другие настройки. По умолчанию 40 секунд.

Примечание: FcgidIOTimeout заменяет изначальный IPCCommTimeout для тех же самых целей.
Таким образом, если широкий исходящий канал и размер файла поддерживается, то предполагаемое время загрузки до 10 минут, вы должны установить это в php.ini:

max_input_time = 600

и для соответствующих виртуальных хостов в httpd.conf

IPCCommTimeout 600

Timeout 600

Например, если клиент хочет закачать 50MB через линию ADSL с предполагаемой скоростью исходящего канала 1Mbps, время загрузки в идеальных условиях будет:

t = ( 50 * 1024 * 1024 * 8 ) / (1 * 1000 * 1000 * 0.8 ) ~ 524.29 секунд.

В изначальной формуле примерно 0.8 ‑ это потери для ADSL-канала, и предполагается, что трафик для ADSL-«окружения» достаточно низок, чтобы не влиять на передачу файла.

Что же касается max_execution_time, то сложно оценить его как процессорное время (т.е., считает только работа процесса, без ожидания «ввода-вывода»), но вы можете работать со значением по умолчанию, которое равно 30. В зависимости от общей загрузки сервера его можно как изменить, так и не трогать.

.

Начало:  PHP, FCGID и Apache – неразбериха из-за ограничений загрузки

Далее:  PHP, FCGID и Apache, Size related parameters

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

Все становится сложнее, если речь идет о хостинге в среде apache + mod_fcgid + php, так как там есть куча параметров, которые нужно настроить для работы с большими загрузками.

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

Кратко об архитектуре

Традиционно интерпретатор PHP запускается и процессе apache. Apache загружает библиотеку PHP (mod_php.so) и использует ее для разбора страниц на PHP. Использование обертывания для исполнения PHP открывает новые возможности. Вот так разработчики mod_fcgid увидели подход к проблеме:

mod_fcgid – это высокопроизводительная альтернатива для mod_cgi или mod_cgid, которая запускает достаточное количество экземпляров программы CGI для обработки параллельных запросов, и эти программы по прежнему работают для обработки следующих запросов. Это благоприятствует PHP-разработчикам, например, как предпочтительная альтернатива запуску mod_php в процессе работы, обеспечиваю похожую производительность.
Не углубляясь в длительные дискуссии по поводу производительности (в наши дни производительность не так уж и дорога), мы увидим безопасность, как главную причину принять архитектуру на основе mod_fcgi. На самом деле, ее можно объединить с SuExec, чтобы каждый виртуальный хост Apache выполнял PHP с отдельным пользователем. Это действительно может спасти жизнь, с точки зрения предотвращения ущерба и анализа доказательств попыток взлома.

.

Далее: PHP, FCGID и Apache, Зависимые от времени параметры

Окончание:  PHP, FCGID и Apache – Параметры, связанные с размером

Step 3 – Завершение

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

sudo /etc/init.d/nginx restart

Перезагрузка должна пройти без проблем.

После инсталляции php5-fpm, он должен запуститься. Если вы изменяли файлы php.ini,  то php5-fpm тоже нужно перезапустить.

sudo /etc/init.d/php5-fpm restart

Все правильно. Теперь они оба должны быть запущены.

Step 4 – Тестирование

Для проверки, что выполнение PHP работает, создайте файл index.php file в /var/www со следующим содержимым:

<?php phpinfo(); ?>

Посетите ваш веб-сервер и вы должны увидеть сгенерированный phpinfo. Если его нет, то что-то сделано неправильно.

Step 5  Поиск и исправление неисправностей, а так же заключительные заметки

Если вы не видите phpinfo, то что-то сделано неправильно. Чтобы отследить, в чем же ошибка, вы можете проверить лог ошибок nginx:

sudo tail /var/log/nginx/error.log

Запомните, если вы меняете php.ini, то вам нужно перезапустить php5-fpm. Перезапуск nginx не нужен.

В своем примере конфигурации я включил перехват ошибок fastcgi. Если происходят серьезные ошибки (например, «невозможно переопределить класс xyz»), nginx может перехватить эту страницу и показать «хорошую» страницу ошибки, если что-то идет не так. Таким образом, в случае серьезных неполадок меньше информации выходит наружу.

Если вам это не нравится, то вы можете это отключить.

Если php5-fpm не запущен, то ваши файлы PHP не будут обработаны и nginx покажет пользователю страницу ошибки.

Ну, мы все сделали и вы можете обслуживать PHP с помощью вашего нового веб-сервера на основе nginx. Nginx неплох, и вы можете настраивать его как угодно. Если вам нужна перезапись, то знайте, что nginx не работает с файлами .htaccess. Вам будет нужно изменить настройки виртуального хоста, чтобы перезапись заработала.

.

Начало: Установка Nginx с PHP 5.3 и PHP-FPM на Ubuntu без компиляции чего-либо.

.

Источник:  http://www.howtoforge.com/installing-nginx-with-php-5.3-and-php-fpm-on-ubuntu-lucid-lynx-10.04-without-compiling-anything

Так как Apache все чаще пожирает много памяти, люди начали искать другие способы хостинга сайтов. Apache, очевидно, не единственный доступный веб-сервер. Хорошими примерами служат lighttpd и nginx. В этом руководстве я покажу вам, как установить его на сервер Ubuntu. Однако это руководство относится и к Debian. Между ними существует лишь небольшая разница.

Готовы? Так начнем.

Step 0 – Предварительное замечание

Для работы с этим учебником, я надеюсь, у вас установлена система Ubuntu Lucid (10.04). Как это сделать вы можете прочесть в других руководствах. Это же руководство сосредотачивается на запуске nginx+php без особых хлопот.

Step 1 – Nginx

Первый шаг, который нам нужно сделать, – это инсталляция nginx. Это просто сделать, скачав его из репозитория.

Виртуальный хост по умолчанию для правильной работы нужно изменить.

Хорошей отправной точкой для вашей конфигурации является:

server {

listen   80;

server_name  localhost;

access_log  /var/log/nginx/localhost.access.log;

## Default location

location / {

root   /var/www;

index  index.php;

}

## Images and static content is treated different

location ~* ^.+.(jpg|jpeg|gif|css|png|js|ico|xml)$ {

access_log        off;

expires           30d;

root /var/www;

}

## Parse all .php file in the /var/www directory

location ~ .php$ {

fastcgi_split_path_info ^(.+\.php)(.*)$;

fastcgi_pass   backend;

fastcgi_index  index.php;

fastcgi_param  SCRIPT_FILENAME  /var/www$fastcgi_script_name;

include fastcgi_params;

fastcgi_param  QUERY_STRING     $query_string;

fastcgi_param  REQUEST_METHOD   $request_method;

fastcgi_param  CONTENT_TYPE     $content_type;

fastcgi_param  CONTENT_LENGTH   $content_length;

fastcgi_intercept_errors        on;

fastcgi_ignore_client_abort     off;

fastcgi_connect_timeout 60;

fastcgi_send_timeout 180;

fastcgi_read_timeout 180;

fastcgi_buffer_size 128k;

fastcgi_buffers 4 256k;

fastcgi_busy_buffers_size 256k;

fastcgi_temp_file_write_size 256k;

}

## Disable viewing .htaccess & .htpassword

location ~ /\.ht {

deny  all;

}

}

upstream backend {

server 127.0.0.1:9000;

}

Хорошо, здесь мы разобрались. Теперь мы инсталлируем необходимые файлы для PHP.

Step 2 – Установка PHP

Много сайтов делается на PHP для обеспечения работы динамического контента например, такие как вики, форумы, веб-блоги или много чего другого.

Нет необходимости использовать DotDeb, так как PHP5.3 официально поддерживается в Ubuntu Lucid (10.04). Это просто как

sudo apt-get update

Полученный текст должен включать dotdeb.

Сейчас мы установим PHP (часть 1):

sudo apt-get install php5-cli php5-common php5-suhosin

Нам нужно установить cli раньше всего остального, потому что это может привести к проблемам в дальнейшем.

Для установки PHP-FPM, нам понадобится добавить к нему PPA, поскольку он официально не поддерживается.

add-apt-repository ppa:brianmercer/php

sudo apt-get update && sudo apt-get install php5-fpm php5-cgi

Если вы планируете использовать базы данных или вам нужны специфические модули (mcrypt, ldap, snmp и т.д.), то вы так же можете их установить.

Хорошо, теперь у нас есть nginx и PHP, установленные и готовые к запуску.

.

Продолжение:  Установка Nginx с PHP 5.3 и PHP-FPM, тестирование, отладка, заключение.