Как настроить заголовок ответа HTTP, когда php используется с g-wan

Я добавляю функцию заголовка в образец 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 будет становиться все более и более ощутимым с течением времени.