Рекомендации по поддержке ресурсов

ЗРАДА! Информация была грубо перекатана со свидомой википедии. Требуется дополнить её фактами, разбавить картинками, переписать или хотя бы почистить от мусора.

В данной статье будут собираться рекомендации, по улучшению работы ресурса. В основном, конечно же, речь идёт о техническом администрировании. Если вы читали статью, касающуюся настройки сервера, и более того, выполнив инструкции из неё сумели развернуть таки свой сайт, то должны понимать - это даже не половина дела, максимум одна десятая. Значительная часть ресурсов умирает спустя короткое время после старта, только потому что создатель либо упирается в рутину поддержки, либо просто не может обеспечить требуемый уровень качества ресурса. Данная статья призвана исправить этот пробел, и рассказать некоторые базовые вещи, которые позволят ресурсу пережить как засранные пелёнки, так и юношеские прыщи :)

Скорость работы и аптайм

По большому счёту важнейшими параметрами любого сайта является стабильность его работы и скорость загрузки страниц. В случае I2P мы должны учитывать вносимые этой технологией поправки - в первую очередь высокие, по сравнению с обычными интернетами, задержки, а во вторую - низкую пропускную способность тоннелей. Кроме того, количество тоннелей обычно ограничено в настройках самого серверного тоннеля, что также сказывается на скоростях.

Полоса пропускания

Во-первых, пользователь имеет шанс вообще не достучаться до ресурса - особенно если у него низкоскоростной канал. Сколько раз уже я видел крики на официальном форуме, что Rus.I2P не грузится. При этом я спокойно заходил на сайт через удалённый роутер. Фишка в том, что у меня по большей части I2P-роутер имеет в распоряжении канал, не ниже 20 МБит/с, в то время, как пользователи - неизвестно какой. Роутер, обслуживающий Rus.i2p, имеет в распоряжении постоянный гарантированный канал в 80 МБит/с как на загрузку, так и на раздачу (т.е. не менее, но и не более, по крайней мере настроить на 100 МБит канал мне не удалось, роутер не проглатывает настройки канала более чем 10000 кб/с на странице настройки трафика http://127.0.0.1:7657/config). Из этого следует первый совет - выделяйте для роутера, который обслуживает ваш ресурс, максимально возможно широкую полосу пропускания. При этом не выделяйте на транзит более 50% - эти настройки можно задать на странице конфигурирования.

Серверные тоннели

Во-вторых, существует ограничение со стороны тоннелей. По-умолчанию вы можете задать в менеджере тоннелей 3 основных тоннеля для каждого ресурса, и 3 резервных. Для не сильно нагруженных сайтов (1-2 загрузки в минуту) этого в целом хватает. Но если с вас например тянут подписки (hosts.txt) или у вас на сервере работает аннонсер для торрент-трекера, то этого уже мало. Честно говоря, автор не копался слишком глубоко в дебрях механизма разделения этих тоннелей (если вдруг сюда набредёт владелец hiddenchan - forman, он вполне может прояснить ситуацию. частично), но есть подозрение, что один тоннель может быть занят только одним соединением с клиентом. Иначе говоря три тоннеля - три клиента одновременно (правило 34 во все дыры). (Кстати говоря проясню ситуёвину спустя некоторое время - сказанное несколько неверно. Поднятый тоннель надо рассматривать как один сетевой интерфейс. Т.е. три тоннеля - три сетевых платы. Как-то так). Если есть резервные тоннели - то ещё добавляется возможность пропускать дополнительные соединения. Фишка в том, что через веб-интерфейс слишком много тоннелей не поднять. Как вещает подсказка на странице [1] большими красными буквами: "ОПАСНО ДЛЯ ПРОИЗВОДИТЕЛЬНОСТИ — Настройки задают слишком большие количества туннелей". Против этого не поспорить - каждый дополнительный тоннель отжирает сколько-то там памяти и сколько-то там ресурсов процессора. Однако, чем их больше, тем быстрее будет отклик (только пожалуйста, без фанатизма).

Изменить вселенскую несправедливость можно путём правки конфигурационного файла, который называется /home/<i2puser>/.i2p/i2ptunnel.config (конечный путь зависит от того, где у вас лежат настройки). Нас интересует кусочек примерно как этот:

tunnel.N.option.inbound.backupQuantity=<число - количество резервных входящих тоннелей>
tunnel.N.option.inbound.length=<число - количество т.н. хопов - посредников, на входящих тоннелях>
tunnel.N.option.inbound.lengthVariance=0
tunnel.N.option.inbound.nickname=Ник вашего туннеля
tunnel.N.option.inbound.quantity=<число - обычное количество входящих тоннелей, которые работают всегда>
tunnel.N.option.outbound.backupQuantity=<число - количество резервных исходящих тоннелей>
tunnel.N.option.outbound.length=<число - количество т.н. хопов - посредников, на исходящих тоннелях>
tunnel.N.option.outbound.lengthVariance=0
tunnel.N.option.outbound.nickname=Ник вашего туннеля
tunnel.N.option.outbound.quantity=<число - обычное количество исходящих тоннелей, которые работают всегда>

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

Серверное ПО

Оптимизация скорости работы ресурса не значит, что надо писать приложения на ассемблерах. Это неэффективная трата времени. Сколько раз я уже плакал окровавленными кирпичами, когда всматривался например в аннонсеры торрент-трекеров. Практически все без исключения они написаны с использованием процедурного подхода, т.е. без использования объектов. Почему-то считается, что так быстрее. Вопрос - насколько? ООП-приложение, если оно прошло оптимизацию каким-либо популярным оптимайзером (типа XCache) в байт-код для интерпретатора, притом, этот байт-код хранится в оперативной памяти, а сам интерпретатор тоже постоянно находится в памяти, так как работает в режиме Fast-CGI - будет работать примерно с такой же скоростью. По крайней мере разница не критична (опять таки - без фанатизма - за используемыми ресурсами всё равно следить надо). Это достигается крайне высокой скоростью исполнения - дело в том, что если немного вникнуть в механизм исполнения php-скрипта интерпретатором, можно выделить несколько основных стадий. Самая длительная из них (не считая алгоритма в скрипте), это чтение файла со скриптом с диска, его парсинг, и перевод в байт-код, пригодный для исполнения интерпретатором PHP. Кроме того, другая стадия - это загрузка самого интерпретатора в память. Настройка PHP как Fast-CGI сервиса обеспечивает нам то, что интерпретатор постоянно находится в памяти. Ему просто передаётся байт-код на исполнение. Сам байт-код в нашем случае - хранится также в оперативной памяти. В него уже произведены все требуемые инклуды (то самое include_once/require_once), сформирован байт-код. Когда происходит обращение к какому-либо скрипту, интерпретатор, уже находящийся в памяти, берёт этот скрипт, который уже прошёл через оптимизацию и сборку байт-кода, также из кэша, находящегося там же, в оперативке. Результат - намного более высокое быстродействие.

Алгоритмы, написанные с использованием ООП, в современных версиях php не сильно медленее аналогов, написанных с использованием функционального программирования. В реальности, под высокой нагрузкой уже давно валится не связка nginx-php. Валится движок БД - неважно, что это - mysql, postgresql, oracle... Потому нужно оптимизировать именно эту часть - существует множество механизмов кэширования... Если вы используете стандартные движки - выбор невелик. Но если пишете что-то своё, с блекджеком и шлюхами, то подумайте над этим. И не забывайте об оптимальной настройке сервера.