Я добавляю функцию заголовка в образец hello.php, как показано ниже:
<?php header("xxxxx: yyyyy"); fwrite(STDOUT, "see headers.<br><br>Hello, PHP!<br>current working directory: ".getcwd()); exit(200); // return an HTTP code (200:'OK') ?> но в firebug нет такого заголовка.
Кто может объяснить, как добавить дополнительные заголовки в php cli с gwan?
Благодаря Гилу и Ричарду,
Теперь это то, что я сделал в соответствии с вашими советами. PHP работает в gwan с настраиваемыми заголовками.
<?php $output='See headers....Hello, PHP!<br>from gwan'; $len=strlen($output); fwrite(STDOUT, "HTTP/1.0\r\nContent-Type: text/html; charset=UTF-8\r\nConnection: close\r\nContent-Length: $len\r\nxxxxx: yyyyy\r\n\r\n$output"); exit(1); ?>
Я использую ab -c 1000 -n 100000 http:127.0.0.1/?hello.php
Использование памяти увеличивается на 0,7% от 2,9 ГБ = 0,0203 Гбит
Использование ЦП увеличивается с 20% до 75% = 50% (выполняется на той же машине с gwan)
Я сделал это на своей старой машине intel P9300 2.26GHz x 2, ubuntu 12.04
он закончил за 9,543 секунды без сбоев
около 10 479 req / sec
Том прав. Чтобы обойти HTTP-заголовки, введенные G-WAN (поскольку вы returned 200 ), вы должны вернуть значение в диапазоне 1-99 (недопустимый код состояния HTTP).
Затем вы будете использовать HTTP-заголовки (если они есть).
return 0; означает закрытое соединение и return 200-600; зарезервирован для кодов возврата HTTP, которые сообщают G-WAN о создании соответствующих HTTP-заголовков.
Руководство по PDF – это ресурс, который стоит прочитать.
Просто слово о "fastCGI" : оно НИКОГДА не будет быстрее, чем запуск скриптов параллельно из нескольких потоков … без привлечения сети (между сервером и PHP).
Чем больше промежуточных слоев или интерфейсов вы добавите, тем медленнее будет так, что "fastCGI" запускает скрипты через интерфейс, используя сеть, обязательно медленнее, чем запуск кода напрямую (и я даже не обращаюсь к факту, что PHP «fastCGI» – сервер очень медленный, что протокол fastCGI сам по себе бессмысленно сложный и, следовательно, медленный, и в этом случае реализация fasctCGI более чем неоптимальная).
Теперь у нас многоядерные процессоры, параллелизм не обязательно включает масштабируемость HORIZONTAL (масштабируемость, полученную при запуске кода на многих подключенных машинах).
Это дешевле (быстрее и экономичнее) масштабироваться ВЕРТИКАЛЬНО (на многих ядрах процессора, которые находятся на локальной машине).
Поскольку количество ядер процессора растет экспоненциально, пути назад нет: масштабирование VERTICALLY будет становиться все более и более ощутимым с течением времени.