Дальнейшее развитие движка трекера VBTT.

[Skald]

В связи с тем что наконец начали появляться другие программисты, которые решили поучаствовать в проекте, стала проблема координации разработки и постановки правильных ТЗ.
Как результат добавил несколько разделов исключительно для разработчиков.

В следующие несколько постов постараюсь изложить свои мысли насчет дальнейшего развития проекта.

[Skald]

Сначала надо определиться что хотелось бы получить от трекера?
Как мне кажется, это:

1. Производительность.
2. Функциональность.
3. Универсальность.
4. Расширяемость.

Производительность:
Самое ресурсоемкое место любого трекера на базе PHP - это аннонсер(скрейп), и иногда некоторые части фронтэнда. С фронтэндом у vBulletin нет никаких проблем - наверное один из самых оттюненных для производительности движков форумов на PHP, но вот с аннонсером при достижении некоторого количества пиров - 100% будут проблемы. В зависимости от конфигурации сервера - число может довольно сильно колебаться, но есть данные что на выделенном сервере 100К пиров 400 пользователей онлайн нагрузка юникс сервера около единицы. А к примеру VDS с 20К пиров при тех же 400 онлайн - юникс нагрузка уже около 4.
Основная проблема проблема PHP аннонсеров - это PHP :) А именно - первая проблема - PHP все-таки не самый быстрый скриптовый язык, а обрабатывать надо от десятка до нескольких сотен запросов в сек (аннонс + скрейп). Вторая не возможность нормально хранить данные между запросами, как следствие постоянное дерганье базы MySQL.
Решением проблемы производительности может стать любой другой аннонсер, например бинарник xbtt, написанный на с++. Но у этого анносера есть несколько недостатков, это:
функциональность - базовый функционал очень мал, и программа ничего не знает о vb,
совместимость и универсальность - т.к. это бинарник - пойдет не на всех хостингах, программу нужно компилировать и она требует довольно много библиотек и иногда есть проблемы в момент сборки - как результат невозможность сборки.

Добавлено через 13 секунд
Функциональность:
Я могу реализовать практически любой функционал трекера на PHP, LUA вот с другими языками посложнее будет. Как следствие правильно модифицировать исходник бинарника и добавить нужный функционал я не могу. В версии 1.0 я отталкивался от последней версии бинарника оригинального VBTT, но т.к. я не мог изменить код - это сильно тормозило разработку и постоянно приходилось придумывать костыли на PHP для замены того функционала, что по идее должен был делать бинарник. Со временем это сильно усложнило код и мне пришлось полностью отказаться от поддержки бинарника. Есть еще проблемы с бинарником, но это уже для отдельного раздела и для тех кто захочет его модернизировать (надеюсь что такие будут :))

Добавлено через 13 минут
Универсальность:
Достичь универсальности можно только используя несколько модификаций движка (минимум версий аннонсеров). Потому что, как я написал выше, использовав PHP аннонсер - все будет работать на любом хостинге, но тогда возникнут проблемы с производительностью, при большом количестве пиров, а использовав бинарник или другой аннонсер демоном, получаем производительность, но совсем не универсальность :)
Поддерживать параллельно несколько различных версий - это просто нереально, но вот определиться с некоторыми местами кода где и какие отличия будут в различных версиях - без проблем (о технической реализации - позже). Только таким способом можно достичь относительной универсальности продукта. Все равно будет или одно или другое, но у пользователя будет выбор (или быстро, но проблемы с совместимостью, или заработает везде, но максимальная нагрузка ограничена)

Добавлено через 9 минут
Расширяемость:
Проблем с расширяемостью у vB практически нет. Существует мощная система хуков для интеграции стороннего кода.
Подобные хуки я добавлю в VBTT. Это нужно чтобы не захламлять код редко используемыми фичами и экзотическими функциями.
Поэтому каждый желающий при желании сможет дописать свой функционал и не надо ничего будет править в коде чтобы заработал какой-либо дополнительный мод. И не должно быть потом проблем при обновлении, т.к. хуки скорее всего будут только добавляться, а удаляться только в крайнем случае - при переписывании большой части кода

[BRP]

На основании вышеизложенного хотелось бы задать вопрос, чем отличается двиг торрентпира от данного, ведь по заявлениям тот двиг держит ~400К пиров, может стоит посмотреть наработки из него...
(то что тот двиг трекера открытый, а данный частный это понятно, но это разве настолько может влиять на производительность?)

PS. Если не в тему - прошу удалить или перенести в другое место...

[Skald]

Технические аспекты интеграции аннонсеров с фронтэндом пока здесь (тема еще в редактировании)

[LInfo]

Сообщение от BRP

На основании вышеизложенного хотелось бы задать вопрос, чем отличается двиг торрентпира от данного, ведь по заявлениям тот двиг держит ~400К пиров, может стоит посмотреть наработки из него...
(то что тот двиг трекера открытый, а данный частный это понятно, но это разве настолько может влиять на производительность?)

PS. Если не в тему - прошу удалить или перенести в другое место...

дело в том, что тот двиг использует xbt-версию

и тут как раз ставится вопрос: главное производительность или универсальность (плюс еще функциональность и расширяемость, последние за счет "движка" форума)

[Skald]

BRP, Я не знаю сколько может держать мой текущий двиг на данный момент, последние данные для выделенного сервака 100К пиров при очень небольшой нагрузке на сервер. Надеюсь понимаете что VDS - это не полноценный выделенный сервер, и я например не слышал чтобы на VDS-ах были форумные трекеры с количеством пиров более 10К.
Я видел исходники торрентпира. Там говорят о кешировании как о каком-то достижении, что очень печально, т.к. я считаю что кеширование должно быть по умолчанию.

[BRP]

еще обратил внимание что на двиге торрентпира по умолчанию скрейп не пашет, может они изначально за счет этого облегчали нагрузку?

[Skald]

Сообщение от BRP

PS. Если не в тему - прошу удалить или перенести в другое место...

Писать можно и нужно, т.к. сейчас главное определить основные направления развития. Тему потом можно почистить.

Добавлено через 2 минуты

Сообщение от BRP

может они изначально за счет этого облегчали нагрузку?

Наверное. Т.к. без скрейпа нагрузка точно меньше будет. Если по соотношению запросов - скрейп:аннонс - идут где-то 2:1.
Хотя аннонс запросов в БД делает значительно больше

Добавлено через 1 минуту

Сообщение от LInfo

и тут как раз ставится вопрос: главное производительность или универсальность

А хочется и то и другое, не одновременно, а чтобы выбор был :)))

[Skald]

Создал опрос - добавлять или нет ситему бонусов в VBTT и если да, то какую

[Skald]

В связи с тем что довольно скоро новая версия и что аннонсер будет переписан почти с нуля, решил опять вернутся к системе бонусов.
После долгих размышлений пришел к выводу что система бонусов (вернее хранение бонусов в базе) будет реализована так:
У пользователя есть засчитанная стата по аплоуду/даунлоуду из которого считается ратио и есть реальная стата по трафу (без учета золотых, серебрянных, випгруппы и т.д.).
Т.е. например:
▲18.87 ГБ / 6.42 ГБ▼
Ратио: 2.94
А реальная стата: будет например
▲10.00 ГБ / 23.42 ГБ▼
Тогда из этих данных (конечно по требованию - редко кому это нужно постоянно), можно из таблицы пиров поднять детальную инфу и получить, что-то типа такого:
▲18.87 ГБ (10.00 ГБ + 1.00 ГБ бонус на своих +2.87 ГБ бонус на чужих + 5 ГБ другие бонусы) / 6.42 ГБ (23.42 ГБ всего - 17.00 ГБ золотых раздач)