Моя цель – раннее очистить заголовок части моего сайта, в то время как мой PHP-скрипт сшивает остальную страницу вместе и отправляет ее после ее завершения. Важно то, что куски отправляются в браузер. (Я использую Apache / 2.2 и PHP / 5.3.4)
Прямо сейчас я пытаюсь достичь этого, вызвав ini_set («zlib.output_compression», «Вкл.») В моем PHP-скрипте. Но если я использую flush () в любом месте моего скрипта, даже в конце, сжатие больше не будет работать.
Вопросы:
a) Используя этот метод, zlib будет очищать выходной буфер и отправлять сжатый кусок в браузер после достижения размера этого выходного буфера?
б) Если это так, то есть какой-либо способ тонкого контроля, когда zlip отправит мой кусок не путем установки внутреннего размера буфера zlib? Значение по умолчанию – 4 КБ.
c) Есть ли хорошие альтернативы для достижения раннего сжатого флеша, возможно, с более тонким контролем в отношении времени, когда я хочу его очистить? Может быть, я полностью ошибаюсь 🙂
Это было долгое время, так как мне пришлось использовать сжатие zlib на OB (подробнее о том, почему позже). Однако позвольте мне попытаться убедить вас отключить сжатие zlib на OB в PHP. Прежде всего, немного фона, чтобы мы были на одной странице.
КАК ДЕЛАЕТ РАБОТУ
Каждый раз, когда php печатает что-то, без OB, он отправляется прямо в apache и от apache к браузеру. Вместо этого, с OB, выход останавливается в apache и ждет, пока данные не будут сброшены (в браузер) или пока скрипт не закончится, и данные будут автоматически очищены. Это позволяет сэкономить довольно много времени и ресурсов при создании страницы путем буферизации этапа Apache на веб-браузер процесса.
ПОЧЕМУ НЕ ИСПОЛЬЗОВАТЬ КОМПРЕССИЮ OB в PHP
Почему бы вам заставить PHP сжать его? Задача серверов должна выполнять такие задачи (например, сжатие js-файлов). То, что вы «должны» сделать, чтобы радикально освободить apache для обработки php, – это установить NGINX в качестве фронта для публики. Это очень просто настроить как обратный прокси, и вы даже можете установить его на том же сервере, что и php и apache.
Поэтому установите NGINX на порт 80, поставьте apache на 8080 (и разрешите только nginx подключаться, но не беспокойтесь, если вы оставите его общедоступным в течение небольшого времени, поскольку он уже был общедоступным и отлично подходит для отладки, чтобы обойти nginx, поэтому никаких проблем с безопасностью должен подняться – но я рекомендую вам не оставлять его общедоступным для долгого времени). Затем создайте обратный прокси nginx для apache, кешируйте все статические файлы, которые выгружают из apache (потому что nginx служит им вместо этого), что означает, что apache может выполнять больше запросов php, а также получать nginx для выполнения OUTPUT COMPRESSION;) освобождая apache и php, чтобы сделать даже больше запросов. В качестве дополнительного преимущества nginx также может обслуживать статические файлы намного быстрее, чем Apache, а Nginx также использует гораздо меньше бара и может обрабатывать гораздо больше соединений.
Даже новичок nginx мог получить настройку nginx после прочтения нескольких учебников в Интернете и завершить все, что я только что сказал в течение 1 дня. 1 день также хорошо провел.
Помните, что буферизация вывода KEEP включена, но для PHP для Apache, но отключите сжатие zlib на PHP и включите его вместо nginx.