Попробуйте ещё включить xdebug.remote_autostart и заменить remote_host на 127.0.0.1
Если нет - советую пробовать другой php, кажется, у openserver можно использовать несколько версий, или же установить отдельно php, xdebug и попробовать начать отладку из консоли.
Сделайте запрос напрямую к nginx (например, с помощью curl) и сохраните ответ в файл. Если размер получился 60021, то сравните побайтово с исходным (ожидаемым) файлом.
Сделайте то же самое напрямую к php (по протоколу fastcgi будет проблематично, запустите встроенный в php сервер).
Пока рано делать выводы, что картинку портит nginx. Хедер Content-Length, полученный от fastcgi, это всего лишь текст - нет гарантий, что тело ответа было такой же длины.
По запросу в гугле "email data into google spreadsheet" находится немало статей на нажную вам тему.
Если форма не привязана к таблице, то возможно её ответы шлются на почту, а дальше сводится к предыдущему вопросу.
Могут быть три кардинально разные причины: netbeans, xdebug и система (файрвол). Нужно сначала идентифицировать, кто именно виноват, а потом копать глубже.
Что вам поможет:
netstat -anb под администратором покажет, слушает ли netbeans порт
telnet localhost 9000 - поможет проверить, принимает ли netbeans соединения, отвечает ли он что-то
nc -l 9000 позволит послушать порт вместо netbeans и увидеть факт соединения от xdebug.
Также проверьте реально действующие настройки php с помощью phpinfo, и ещё попробуйте запускать дебаг при запуске скрипта из командной строки.
Попробуйте сделать запрос на проигрывание видео curl'ом и посмотрите скорость. Это укажет, кто виноват - сервер или браузер.
В инспекторе сети браузера Copy as curl. Чтобы измерить скорость, выполните команду так: curl ..... | pv > /dev/null
alexey66: Это значит, что процессы php-fpm во время работы зажирают 64% RAM. Это может быть по двум причинам: либо их становится больше (потому что в какой-то момент было много параллельных запросов), либо увеличивается использование памяти отдельными процессами (потому что с обработкой запросов расход памяти постепенно растёт - кеш, утечки памяти, всё такое).
Бороться с этим не нужно, это совершенно нормальное явление. Наоборот, если после рестарта у вас использование RAM не снижается - это очень странно.
Вам нужно в первую очередь снизить pm.max_children. Можно также pm.max_requests.
Я рекомендую вам начать с таких настроек (это должно быть где-то в /etc/php/5.x/fpm/pool.d/xxx.conf)
Учитывая, что у вас только 2 ядра, 30 параллельно работающих процессов php-fpm не дадут вам большей скорости генерации, чем 10 (исключение - это если ваш php делает много запросов по сети).
alexey66:
На htop у вас 30 процессов php-fpm, которые съедают почти всю память. Уменьшайте количество процессов (pm.max_children)
Сайт возможно не доступен, потому что сервер увяз в своппинге.
"Сервер лежит" - не совсем понятно, как же вы тогда скриншоты сделали?
Судя по htop'у у вас 20% памяти не используется вообще.
Мускул занимает 120М. Чего вы к нему прицепились?
95% занято вместе с кешем, или 95% приложения и 5% кеш?
Сделайте скриншот, когда будет занято 95%. Если не можете следить - atop вам в помощь.
Какой объём базы? Какой движок таблиц? Сколько стоит innodb_buffer_pool_size?
У вас случайно не софт-рейд? Мускул показывает очень плохие результаты на софт-рейде.
Попробуйте отключить кеш запросов полностью (не для текущей сессии, а для всего сервера) - он может провоцировать ненужные блокировки.
Если у вас Copying to tmp table для частых запросов - это говорит о том, что требуется оптимизация запросов или индексов.
Максим Ходырев:
в контроллерах и командах, которые точно не будут использоваться повторно. Это типичный подход Symfony.
Некоторые люди высказываются, что в Symfony даже контроллеры должны быть сервисами и не использовать контейнер. Но я считаю, что это лишнее: строго, красиво, но отнимает время и не несёт особой пользы.
Николай Ковалевский: "текст со сломанной кодировкой длиной в 21 символ" - это на самом деле упакованный в gzip ответ. если его распаковать с помощью gzinflate(substr($data, 10)); - получите тот же самый один ноль.
У вас проблема совершенно не в правах доступа. У вас запрос приходит на папку (/), индекс-файл подходящий (видимо) не нашёлся, а вывод листинга папки (autoindex, directory index) запрещён, о чём и ругается в логи. Вам нужно разбираться, почему не подхватывается index-файл.
Если нет - советую пробовать другой php, кажется, у openserver можно использовать несколько версий, или же установить отдельно php, xdebug и попробовать начать отладку из консоли.