Возможно ли оптимизировать отдачу web-сервером статики используя PHP?

Question

[kocherman]

С недавнего времени сайт на хостинге Петерхост даже под небольшой нагрузкой стал работать медленно (не оставляю ссылку на сайт и на хостинг, чтобы не посчитали за рекламу).
Сегодня нашел узкое место в работе сайта.
Так уж получилось, что места на хостинге не хватает в достаточном количестве. Некоторые картинки приходится хранить на другом хостинге. Но при этом, из соображений SEO для лучшей индексации картинки должны быть на одном домене с сайтом.
Еще два года назад для решения задачи был написан скриптик-прокси картинок.

<?php
$imgs = file('./img-links.txt');
$addr = trim($imgs[$_REQUEST['id']]);
header('Content-type: image/jpeg');
readfile($addr);

Скрипт несколько упрощен для наглядности.
Привел название хостинг-компании не случайно. В используемом нами тарифе отмечена поддержка скриптов perl и c/c++.
Хочу узнать у сообщества, будет ли смысл переделывать прокси на perl или с++? Упадет ли нагрузка на процессор и память?
Как реализовать проще и быстрее?

Вариант со сменой хостинга тоже не рассматривается. На дешевых VDS сайт работает медленнее, чем на shared-хостинге, т.к. на shared-хостинге доступны большие ресурсы. Переход на выделенный сервер тоже не рассматривается из-за высокой стоимости аренды.

UPDATE Кэшировать картинки не имеет большого смысла так как почти все картинки прогружаются приблизительно одинаковое количество раз. Хостинг картинок мы используем google-picasa, dropbox и некоторые другие бесплатные сервисы. Аккаунтов много — нет возможностей платить за стогигабайтные хостинги. Чтобы сайты не теряли seo, приходится скрывать реальное размещение картинок для ПС. Кроме того, проект рассчитаны на пользователей, приходящих с ПС.

Основную нагрузку дает не работа самого скрипта, а создание инстанса PHP.

Также хочется отметить непосредственную минимизацию затрат времени и средств на проект.
Если представить, что у нас ни один проект, а, например, 10. Платить за 10 выделенных серверов, следить за их работоспособностью. В таком случае, мне как минимум придется переквалифицироваться из программиста в системного администратора. Даже сейчас не хватает времени на реализацию тех или иных вещей. Если еще заниматься настройками и поддержкой инфраструктуры, то можно вообще закопаться…

Comments

[qxfusion]

Вы пробовали использовать облако? (Amazon AWS, Joyent SmartCloud) Возможно Вам проще перейти и забыть о такой проблеме.

Answer 1

[Денис Пушкарев]

К сожалению, менеджеры хостинга нас ото всюду выгоняют из-за нагрузки. Предлагают услуги dedicated.
Пробывали VDS 4Гб памяти, 1 ядро 3.2Ггц, FreeBSD. — сайт не может проработать и 20 минут. Смотрим на сервере top — висит более 10 тысяч процессов httpd. На хостинге работает стабльнее, а главное — работает. Но со всех хостингов нас выгоняют вместо предложений вариантов решения проблемы.

Дело в том, что на одной странице в среднем подгружается 50 — 300 картинок. Один запрос на страницу = 50 — 300 запросов к apache+php.

Дык поставьте nginx на VDS вместо апача, не будет столько процессов плодить — раз, статику его средствами без PHP отдавать — два. Вашего тарифа за глаза хватит. Apache+php — пара процессов на каждое соединение, посчитайте что на ваших картинках получается — никаких физических серверов не хватит. Nginx'a будет несколько процессов висеть и последовательно запросы обрабатывать — и, спасибо гуглу, 2.5 Мб памяти жрать на 10к неактивных соединений. Ну а если одним nginx, что маловероятно, не обойдетесь — php-fpm за ним, дабы и пыха лишние процессы не плодила.

Answer 2

[Anastasia_K]

проще и быстрее поднять nginx и настроить проксирование картинок на один апстрим, а всего остального на другой.

Comments

[kocherman]

Тогда другой вопрос, как поднять на Петерхосте nginx?

[kocherman]

Извиняюсь за провокационный вопрос. Конечно же, на петерхосте стоит nginx…

[Anastasia_K]

Прошу прощения, я как то не подумала что на shared хостинге проблематично поменять настройки nginx для конкретного сайта :)
Попросите техподдержку сделать проксирование, возможно они пойдут Вам на встречу.

[kocherman]

К сожалению, менеджеры хостинга нас ото всюду выгоняют из-за нагрузки. Предлагают услуги dedicated.
Пробывали VDS 4Гб памяти, 1 ядро 3.2Ггц, FreeBSD. — сайт не может проработать и 20 минут. Смотрим на сервере top — висит более 10 тысяч процессов httpd. На хостинге работает стабльнее, а главное — работает. Но со всех хостингов нас выгоняют вместо предложений вариантов решения проблемы.

[Anastasia_K]

вы уверены, что проблема в хостинге?

[kocherman]

99% нагрузки именно на то место, которое я указываю в вопросе.

[kocherman]

Дело в том, что на одной странице в среднем подгружается 50 — 300 картинок. Один запрос на страницу = 50 — 300 запросов к apache+php.

[vsespb]

Вообще первый раз слышу чтобы «Хостинг» был быстрее VDS… под «хостингом» Вы имеете ввиду shared хостинг?

Если да и провайдер не размещает свои баннеры на ваших страницах, VDS должен быть быстрее, либо он неправильно настроен (используйте nginx а не httpd).

[AndrewStephanoff]

К сожалению, менеджеры хостинга нас ото всюду выгоняют из-за нагрузки. Предлагают услуги dedicated.
Пробывали VDS 4Гб памяти, 1 ядро 3.2Ггц, FreeBSD. — сайт не может проработать и 20 минут. Смотрим на сервере top — висит более 10 тысяч процессов httpd. На хостинге работает стабльнее, а главное — работает. Но со всех хостингов нас выгоняют вместо предложений вариантов решения проблемы.

У вас несконфигурирован apache2. При большом количестве соединений, у вас открывается 10к процессов, оперативная память заканчивается и сервер уходит в своп. Попробуйте ограничить максимальное количество клиентов для apache2, если хостер позволяет.

Answer 3

[vsespb]

Можно ещё наиболее часто загружаемые картинки отдавать с основного хостинга (например все картинки разместить на вторичном хостинге, а частозагружаемые кэшировать на основном хостинге)

Comments

[kocherman]

Вы думаете, нагрузка на процессор и память упадет? Ведь логику кэширования и вытягивания из кэша тоже придется писать на PHP, а соответственно, каждый новый процесс php будет подгружать все подключенные к php модули. Узкое место не размещение картинок, а способ трансляции…

[vsespb]

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

2. У Apache есть директивы типа — если файл существует отдать файл, если нет — вызвать скрипт (хотя с ними гораздо сложнее настроить логику удаления редкоиспользуемых картинок)

3. Если реально весь процессор и память занята php, перекачивающим картинки, то C++ в режиме fastcgi или аналогичном будет лучше — меньше CPU, меньше памяти.

[kocherman]

readfile() — самый производительный способ транслирования файлов. при использовании readfile() вроде как сам файл не хранится в памяти сервера и по мере получения кусочков файла, они сразу транслируются браузеру.

Вот по поводу C++ и думаю… как над единственным вариантом… Но, к сожалению, для меня это сложно было бы реализовать.

[Anastasia_K]

А если в Вашей схеме клиент будет мееееедленно получать картинки? буквально пару байт в секунду? как быстро у вас забьется память или будет достигнут лимит процессов?

[vsespb]

Будет тоже самое, как если бы apache отдавал с локального диска без PHP. Процессов apache будет столько же. Будет ли этот процесс, обслуживающий медленных клиентов, содержать в себе PHP интерпретатор, зависит от того в каком режиме PHP подключён к Apache и от Apache MPM.

[kocherman]

А как в таком случае без PHP подключить логику изымания адреса картинки из файлов?

Answer 4

[ngreduce]

Может я чего-нибудь не знаю, но разве раздача статики с поддомена не сеошно?

Comments

[kocherman]

По моему опыту это менее сеошно, чем картинки были бы на основном домене. Кроме того, главное для этого некоммерческого проекта — картинки. И 90% трафика идет с поисковиков картинок.

Answer 5

[Олег Карнаухов]

" Предлагают услуги dedicated.
Пробывали VDS 4Гб памяти, 1 ядро 3.2Ггц, FreeBSD. — сайт не может проработать и 20 минут."

«99% нагрузки именно на то место, которое я указываю в вопросе.»

«Дело в том, что на одной странице в среднем подгружается 50 — 300 картинок. Один запрос на страницу = 50 — 300 запросов к apache+php.»

1. Берите VDS.
2. Переходите на Nginx с проксированием как вам говорили.
3. PROFIT! (99% нагрузки уже нет)

Answer 6

[Евгений Кузнецов]

Воспользуйтесь услугами CDN. cloudflare.com например.
И на статику отдавайте заголовки Expire на месяцок, чтобы каждый раз браузер не тянул.
А вообще Вам бы провести оптимизацию кода сайта… Т.к. vds такой конфигурации должна держать оооочень высокую нагрузку.

Comments

[kocherman]

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

Answer 7

[Евгений Кузнецов]

Ну вообще, если по уму, то отдавать статику с помощью php это вкорне не правильно, но вот у Вас есть причина на это.
Я бы все же перенес на vds, отстроил все хорошенечко, оптимизировал код, настроил nginx на проксирование к второму вашему хостингу, и про кэширование отдаваемых страниц (не динамических, благо в nginx можно все что угодно настроить) не забыл.

Comments

[kocherman]

как в таком случае без PHP подключить логику изымания адреса картинки из файлов?

[Евгений Кузнецов]

Я не знаю логику Вашего приложения, но посмотрите в сторону www.nginx.org/ru/docs/http/ngx_http_map_module.html

Answer 8

[v0s]

Если работать с тем что есть по принципу минимальных изменений, я бы во-первых закешировал вот это

$imgs = file('./img-links.txt');
$addr = trim($imgs[$_REQUEST['id']]);

(перевел бы список линков в пыховый массив, который закешится opcode-кешером)

а во-вторых, отдавал бы клиенту 301 moved permanently с реальной ссылкой — нехай сам качает.
Это при условии что такой подход не снизит «сеошности» и не стоит задачи скрыть от всех реальное расположение картинок.

Comments

[qxfusion]

301 как раз снижает в Google + возможность попасть в бан у Google если целевой сайт попал тоже.

[v0s]

302 found?

Заголовок Refresh: 0; image url? (изврат, но меньший чем проксировать картинки php-скриптом)

[Максим Дьяченко]

А при чем здесь бан если оба домена ваши?

[Алексей Скахин]

Соглашусь, из всей конструкции самое ресурсоемкое — это каждый раз запихывать этот текстовый файл в память.
Дайте названия картинкам, такие, чтобы их можно было выдернуть зная одно id, или же разбейте файл на несколько мелких частей по какому-то принципу (аналог партиционирования в бд: 0-1000, 1000-2000 и т.д.), а потом будете дергать уже не весь файл, а его меньшую часть.

[kocherman]

Файлов с адресами много. Создаются автоматически ежедневно по 1 файлу.

Answer 9

[la0]

Спросите поддержку про X-accel-redirect + кеширование таких запросов.
Если nginx Accel-ный ответ от бекенда, то не будет обращаться к скриптам а сам отдаст нужную картиночку.
Если вам удастся что-то такое провернуть, это будет лучшее решение.

Answer 10

[max_rip]

файлы на под домен
в под домене в robots.txt

User-agent: *
Host: основной домен.

Comments

[max_rip]

Ну и чтобы начало работать в .htaccess, на картинки 301.
Не уверен, но вы наверно можете через вебмастер потвердить, что под домен это зеркало основного сайта Тогда не каких сео проблем не будет. Хотя Host robots.txt, как раз и должен решить эту проблему.

Ну и если уж сильно хочется чтобы все было на одном домене, то nginx как советовали выше, но не забывайте, что у браузеров есть лимит на количество одновременных запросов к одному домену. А так как у вас от 50 до 300 изобажений на одной странице, вынос их на под домен еще и ускорит их загрузку. А если этих под доменов будет несколько, пусть даже алиасами на одно физическое место, добавит скорости еще.

Answer 11

[qxfusion]

1) сделать отдельный домен под статику
2) поставить на этот домен балансир — например static.site.com -> 0.static.site.com, 1.static.site.com и т.д.
3) обновить настройку — т.к. связка nginx+php_fpm 97% случаев быстрее чем httpd+mod_php (если нету явных завязок на httpd)
4) VDS — смотря у какого хостера, у РУ как правило идет оверселл — что (1) получаете меньше % CPU (2) сеть и без Вас утилизирована до предела, а у хостов часто ставят лишь 100Mbps
P.S. от себя добавлю — переходите в облако, например у Joyent небольшой инстанц стоит недорого + возможность масштабирования на лету (правда тут тогда лучше использовать Joyent SmartOS — удобнее будет) + 10Gbps общий шаред порт (гарантированная скорость равна доле ресурсов от RAM — т.е. если Вы купили 1GB инстанц — то получите гарантировано — 10Gbps/80*1 = 125Mbps теоретической скорости сети (в реале будет до 100Mbps)) и 20TB/mo./instance премиум трафика.

Comments

[kocherman]

У Joyent SmartOS есть российские ip?

[qxfusion]

нет, у них свои ДЦ в EU и USA как и подсети.

Answer 12

[AHTOH]

Я прочитал, все что советовали до меня. Все верно говорят. Но в данном случае я бы исключил php из цепочки вот каким способом (например):

1. Вы создаете символьные ссылки на все нужные Вам файлы в каталоге (командой ln -s), называя ссылки их ID (как описано в вашем же файле img-links.txt). Нужно только в фоне (руками или по крону) поддерживать актуальность соответствия ссылок нужным файлам (чтобы ссылки соответствовали img-links.txt). Тогда Вам не нужно будет для каждого запроса подгружать php, а можно будет просто отдавать файлы средствами httpd (apache или nginx — не важно).

2. Если ID не имеют расширений, то придется прописывать тип файлов в таблице соответствий (что тоже не сложно).

3. Поддерживаю совет по настройке expire для статики хотя бы на несколько дней (лучше — недель).

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