Рекомендации по поддержке ресурсов
В данной статье будут собираться рекомендации, по улучшению работы интернет-ресурса. В основном, конечно же, речь идёт о техническом администрировании. Если вы читали статью, касающуюся настройки сервера, и более того, выполнив инструкции из неё сумели развернуть таки свой сайт, то должны понимать — это даже не половина дела, максимум одна десятая. Значительная часть ресурсов умирает спустя короткое время после старта, только потому что создатель либо упирается в рутину поддержки, либо просто не может обеспечить требуемый уровень качества ресурса. Данная статья призвана исправить этот пробел.
Содержание |
[править] Скорость работы и аптайм
По большому счёту важнейшими параметрами любого сайта является стабильность его работы и скорость загрузки страниц. В случае I2P мы должны учитывать вносимые этой технологией поправки — в первую очередь высокие, по сравнению с обычными интернетами, задержки, а во вторую — низкую пропускную способность тоннелей. Кроме того, количество тоннелей обычно ограничено в настройках самого серверного тоннеля, что также сказывается на скоростях.
[править] Полоса пропускания
Во-первых, пользователь имеет шанс вообще не достучаться до ресурса — особенно если у него низкоскоростной канал. Сколько раз уже я видел крики на официальном форуме, что Rus.I2P не грузится. При этом я спокойно заходил на сайт через удалённый роутер. Фишка в том, что у меня по большей части I2P-роутер имеет в распоряжении канал, не ниже 20 МБит/с, в то время, как пользователи — неизвестно какой. Роутер, обслуживающий Rus.i2p, имеет в распоряжении постоянный гарантированный канал в 8 МБит/с как на загрузку, так и на раздачу (то есть не менее). Из этого следует первый совет — выделяйте для роутера, который обслуживает ваш ресурс, максимально возможно широкую полосу пропускания. При этом не выделяйте на транзит более 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… Потому нужно оптимизировать именно эту часть — существует множество механизмов кэширования… Если вы используете стандартные движки — выбор не велик. Но если пишете что-то своё, то подумайте над этим. И не забывайте об оптимальной настройке сервера.
| Рекомендации по поддержке ресурсов относится к теме «I2P» |