Перейти к контенту

IPB vs vBulletin


Рекомендуемые сообщения

Ссылка на комментарий
Поделиться на других сайтах

  • Ответы 204
  • Создана
  • Последний ответ

Лучшие авторы в этой теме

Лучшие авторы в этой теме

Загружено фотографий

Отвечаю всем и сразу.

Большая часть народу откровенно не поняла о чем я говорил, и что кому было адресовано, поэтому разъясняю:

1. Вот вы тут все про нагрузку говорите, и хотите меня убедить, что дерганье аватарок и шаблонов из базы создаст лишнюю нагрузку, как будто я сам этого не знаю =\ Я разве где-то говорил что нагрузку будет такая же, или не дай бог меньше? Я говорил малость о другом.

Если вы считаете что правильно грузить как можно больше базу данных, то это ваше сугубо личное имхо. Так ведь?

Я не так считаю. Я считаю что в идеале правильно хранить все, кроме исполняемых скриптов в БД. Нагрузка - это исключительно проблема вашего mysql сервера и проца, о чем тут еще можно говорить? Конечно разработчики виноваты, что сделали воблу всепожерающим монстром на ваше машине, не учтя, что таких ресурсов у большинства людей сейчас нет. Сейчас нет - а завтра тоже не будет? А через 5 лет? Когда-то админы считали килобайт свободного места у себя на сайте, сейчас считают нагрузку на сервер. Кто сказал, что в ближайшем будущем на нее не забьют? А ведь забьют наверняка, и вы, ребята, забьете.

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

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

 

Неужели программисты уже разучились отличать теорию от практики, и не понимают этого? С точки зрения оптимизации было бы замечательно полностью кэшировать хтмл страниц форума- разве не так? а че ж это никто не делает? Да потому что это прямой дебилизм, и банальная экономия на спичках. Хранить ли в кэше всю страницу, или лишь ее части - разница в нагрузке минимальна. Всему свое время. На нагрузку БД мы тоже плевать начнем.

 

А что касается аватарок, аттачей и прочего, читай ниже.

Дебилизмом является именно хранение статической бинарной инфы в БД. Почему?

Как ты думаешь, кому из нас проще сделать бекап всего форума? Мне - нажав на одну кнопку в админке, или тебе, сохранив то-се, пятое-десятое, и про автарки не забыть? Ответ очевиден как и твой вывод.

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

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

Расскажите плз поподробней про эту логику.

Я про нее уже рассказал. Файлы - для исполняемых скриптов, для данных - база ДАННЫХ - единое место, где им самое место.

 

Понятно, что данные постов никто в файлах из этих двух борд не хранит.

Извини, а в чем разница между загружаемым текстом, и загружаемыми файлами, кроме того что они называются "файлы"? Правильно, ни в чем. Кто-то тут говорил про "статику", и спрашивал часто ли я шаблоны редактирую с аватарками. А вы часто редактируете сообщения хотя бы 3х дневной давности? ну и .... ?

 

Может кто-то из здешних программистов решит поспорить, что самой логичной с точки зрения оптимизации + производительности является схема: индексы - в БД, данные - в файлах? Ну поспорьте. Однако странно, что ИПБ ее не использует =\

 

Повторяю еще раз, товарищи: учимся отделять теорию от практики, и идею от воплощения. Вы смотрите на вещи с точки зрения ежедневной практики, основанной на врожденном стремлении к экономии. Не то чтобы это не правильно - это очень даже правильно. Я сам переносил аттачи в файловую систему, и матюгался на джелсофт за то, что шаблоны нельзя перенести туда же, т.к. при нескольких сотен посетителях в день и говенном хостинге вбола начинает загинаться. Но я не говорю что идея хранить данные в базе данных - это глупо. Надеюсь, теперь я свою позицию достаточно подробно объяснил?

 

и пока форум не выростет из пеленок, ему разницы то особой нет... а потом начинается....

Бедняжка, у вас проблемы с нагрузкой на хваленом вами же ипб? Может вы просто не умеете его готовить (оптимизировать) ?

Кто был на форуме пхпклаба, тот на башорге не смеется... (с)

Ссылка на комментарий
Поделиться на других сайтах

Ну и праивильно, давайте 5 лет подождём и будем потом пользоваться VB, а пока сидим на IPB и не пи####м :D

 

А да кстати мне говорили что и аттачи VB хранит в БД. Не только фотки и аватары.

Итого имеем: VB хранит в БД:

- скины

- аватары

- фотки

- аттачи

 

Ну просто супер.

(Сколько интересно бэкап у него весит?)

 

Malcolm_Reed

уважаемый мы ценим вашу точку зрения и философию по поводу хранения всего и вся в БД, но мы с ней не согласны. Видимо с теорией и практикой, как вы говорите :-/ у нас действительно проблема.

На этом я так понимаю можно про этот единственный (?) "косяк" в VB закончить говорить.

Ссылка на комментарий
Поделиться на других сайтах

Malcolm_Reed

VB осталось еще и скрипты в базу запихать и вообще очнь логично будет

а уж как бекап удобно будет делать сказка прям да и только

-- тут ирония кончилась --

 

Вы видимо с частичным кешированием не знакомы чтоли? никто и не говорил о том чтобы всю страницы в HTML-Ке сохранять же

 

ну еще у VB до кучи и моды (хаки) в базе (если меня не глючит, вечерком удостоверюсь)

Ссылка на комментарий
Поделиться на других сайтах

2 GiV: Я не предлагал считать, я предлагал сравнить. Это проще чем проверять оба форума на одинаковых серверах

 

2 Malcolm_Reed: Может с точки зрения сервера этот вариант и имеет право на жизнь, но не с точки зрения клиента. Расположение аватаров на диске является преимуществом именно из-за кеширования их браузером пользователя. Если уж хранить в БД html, то можно туда и всю графику скина запихнуть и тоже выдавать скриптом? :D Плюс к тому этот вариант имеет минус из-за дополнительной нагрузки которую вызывает php для выдачи всего этого дела. А если считать что сервер без всяких лимитов - то вообще бесполезно сравнивать. Для этого можно многие вещи сделать по-другому и вместо оптимизации заниматься теор вопросами из этой серии.

Ссылка на комментарий
Поделиться на других сайтах

VB осталось еще и скрипты в базу запихать и вообще очнь логично будет

будь добр - читай весь пост, перед тем, как писать.

а уж как бекап удобно будет делать сказка прям да и только

в любом случае, сейчас восстанавливать бэкап вб в 1000 раз удобнее, чем бэкап ипб, редактируя половину файлов.

Ссылка на комментарий
Поделиться на других сайтах

в любом случае, сейчас восстанавливать бэкап вб в 1000 раз удобнее, чем бэкап ипб, редактируя половину файлов.

 

Не вижу проблемы. У меня всегда дома есть точная копия того, что стоит на сервере. Элементарно заливаются файлы, импортируется дамп БД и вуаля - всё работает.

Ссылка на комментарий
Поделиться на других сайтах

Не вижу проблемы. У меня всегда дома есть точная копия того, что стоит на сервере. Элементарно заливаются файлы, импортируется дамп БД и вуаля - всё работает.

хорошо. обновлять вб удобнее чем ипб

Ссылка на комментарий
Поделиться на других сайтах

Заливка и сохранение БД, тем более одним куском - самый геморный этап.

И чем она меньше, тем лучше. С фтп работать и быстрей и удобней, пофайлово. Выборочные файлы сохранять удобно.

Ссылка на комментарий
Поделиться на других сайтах

и что, модификации, которые делаются под VB лежат в стороне от основных файлов форума, и они совместимы с любыми версиями этого форума от первой до последней, и никогда нет необходимости поправить под себя эти основные файлы?
Ссылка на комментарий
Поделиться на других сайтах

и что, модификации, которые делаются под VB лежат в стороне от основных файлов форума, и они совместимы с любыми версиями этого форума от первой до последней, и никогда нет необходимости поправить под себя эти основные файлы?

представь себе, в 99% случаев - да. только совместимы не со всеми версиями, а с линейками(например 3.6.x, 3.5.x, 3.0.x). для всех модификаций кода в вобле есть так называемые 'хуки'. то есть грубо говоря в файлах в определенных местах прописаны контрольные точки, а через встроенную систему модулей можно прилепить выполнение пхп кода к определенной такой точке. Да, хуки присутствуют не на каждой строчке, поэтому остается 1% хаков, которые требуют модификации файлов.

Ссылка на комментарий
Поделиться на других сайтах

Жутькакая.

Сразу представлюсь: я из стана вбуллетенщиков и сервер у меня некоторое время назад был ужасно тормозной, поэтому пришлось изучить все известные методы оптимизации и разработать некоторые неизвестные.

 

Вы, конечно, обратили внимание на ценовую политику обеих фирм, деньги платят _один_ _раз_за экземпляр форума и поддержку. В таких условиях важным клиентом становятся середнячки-непрограммисты, те люди, которые по документации способны нажать пару кнопок и поставить форум. Они не знаю что такое safe mode, где лучше хранить данные. Они просто хотят обсуждать свое хобби. Их форум возможно никогда не станет большим. Вот на них jelsoft и ориентируется.

 

На корпоративном рынке хороший продукт продают в зависимости от производственного эффекта(числа юзеров,процессоров,одновременных сессий). Вы готовы к такому лицензированию? Я - пока нет.

 

Теперь конкретика :

Действительно по-умолчанию все хранится в базе, но легко переносится в файловую систему.

Не переносятся только аттачи, там при скачивании необходимо вызывать скрипт для проверки прав доступа.

 

Все нужные шаблоны выцепляются одним запросом все !

На код, призваный кешировать темплаты я тоже обращал внимание.

Мне кажется, с тех пор как появился специальный аддон, разработчики забили на эту идею.

Проблема в том, что кеширование текста шаблонов ничего особо не даст.

Вот если преобразовывать шаблон в скомпилированный php-код наподобие smarty - может помочь.

IPB именно php-код в шаблонах? if-ы и тд? ну что ж, молодцы)

 

В статье описывается тормознутость плагинов и необходимость делать запросы.

Это неправда. По-умолчанию тоже выцепляются все существующие плагины и хранятся в массиве.

Кроме того, есть стандартная возможность записывать наиболее частоиспользуемые данные

в php-файл. называется внешний datastore . В число этих данных входит код плагинов. Некоторые массивные аддоны просто в этом тексте вставляют require('имя_файла.php') и, таким образом, вступает в дело php-акселератор. Также есть модификации, которые просто выкатывают код плагинов в файлы.

 

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

Ссылка на комментарий
Поделиться на других сайтах

Не переносятся только аттачи, там при скачивании необходимо вызывать скрипт для проверки прав доступа.

В IPB проверяется и аттач не даёт скачаться не тому лицу что надо. В IPB ссылки на аттачи всё же не абсолютные.

 

IPB именно php-код в шаблонах? if-ы и тд? ну что ж, молодцы)

Да.

Ссылка на комментарий
Поделиться на других сайтах

В IPB проверяется и аттач не даёт скачаться не тому лицу что надо. В IPB ссылки на аттачи всё же не абсолютные.

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

если использовать nginx и модификацию для nginx, это не так страшно.

 

IPB именно php-код в шаблонах? if-ы и тд? ну что ж, молодцы)

Да.

так, а маленькие шаблончики тоже хранятся в файлах?

все-таки это неоднозначный плюс. неизвестно,что быстрее выполнится eval маленького шаблончика какой-нибудь кнопки или include внешнего файла. php ведь имеет очень простой синтаксис и компилируется относительно быстро.

Ссылка на комментарий
Поделиться на других сайтах

так, а маленькие шаблончики тоже хранятся в файлах?

все-таки это неоднозначный плюс. неизвестно,что быстрее выполнится eval маленького шаблончика какой-нибудь кнопки или include внешнего файла. php ведь имеет очень простой синтаксис и компилируется относительно быстро.

Ну не скажите — всего один инклуд против eval'а каждого шаблона в vBulletin.

Система шаблонов в IP.Board такова, что мы в большинстве случае делаем всего лишь один инклуд — подключаем группу шаблонов. Группа шаблонов из себя представляет всего один PHP-файл.

Так что более верно будет сравнить N-ое количество eval'ов против 1—2 инклудов :D

Инициализируем группу и потом становятся доступны все ее методы, которые представляют из себя шаблоны...

Ссылка на комментарий
Поделиться на других сайтах

> Давайте еще скрипты в бд запихнем.

gorn правильно ответил - читайте пост целиком. Я там все объяснил.

 

 

>(Сколько интересно бэкап у него весит?)

Больше чем у ИПБ, это понятно. Вот тут кто-то сказал, что маленькую БД удобнее экспортировать/импортировать. Почему? т.е. в чем удобство? Поставил я базу скачиваться, и пошел покурить. Вернулся - вся база скачалась. А вы будете сидеть за машиной, и в экстазе от скорость импорта БД скачивать по фтп аватарки и аттачи - в чем разница то? Правильно, разница в том, что у меня меньше гемора =)

Кто-то скажет, что за время экспорта/импорта mysql может лагануть, или же будет не в состоянии загрузить такой объем данных за раз - да, бывает, но эти случаи уже из разряда фантастики. Их очень мало, и это исключительно проблема хостинга (даже не сервера, а хостинга. "Покажите мне такой сервер" называется), так что брать это в расчет не стоит.

 

>но мы с ней не согласны.

Ваше право.

 

>никто и не говорил о том чтобы всю страницы в HTML-Ке сохранять же

Почему? я говорил =) Это была ирония, но со смыслом.

 

и что, модификации, которые делаются под VB лежат в стороне от основных файлов форума, и они совместимы с любыми версиями этого форума от первой до последней, и никогда нет необходимости поправить под себя эти основные файлы?

Лежат - да отдельно. Не происходит ни одного редактирования файла. Иногда редактируются шаблоны, но это и так понятно (хотя часто можно обойтись и без редактирования шаблонов, при этом вставить в нужный шаблон свой ХТМЛ, но технически это осуществимо и в ИПБ).

Совместимость: есть такое понятие, как линейка версий. В вб это например 3.0 3.5 и 3.6 (2,* уже никто не пользуется, так что его опускаем). 99 процентов хаков и стилей всегда подходит под свою линейку целиком и полностью. Обновление ничуть не затрагивает их функционал. Конечно можно придумать мистическую ситуацию, когда разработчики в новой версии переименуют как раз ту переменную, которая использовалась в этом хаке, но это уже на грани фантастики, ибо обновления между линейками у ВБ незначительные (затрагивают небольшие никому не нужные участки кода).

Примерно 50% всех хаков являются кросс-версионными. Например половина хаков от 3,5 подходит к линейке 3,6.

За последние кажется 2 года обновлений я моды не трогал вообще. Они как стояли, так и стоят. Я лишь перезаливал файлы воблы для новых версий, не теряя при этом ничего. Полное обновление модов раз в 1,5 / два года - это фигня. К тому же не забываем, что в под обновлением у нас обычно подразумевается нажатие 2х кнопок - "установить плагин -> перезаписать поверх существующего" =\

Ссылка на комментарий
Поделиться на других сайтах

Больше чем у ИПБ, это понятно. Вот тут кто-то сказал, что маленькую БД удобнее экспортировать/импортировать. Почему? т.е. в чем удобство?

Во мне ещё живёт память о диал-апе, о том как приходится тянуть многометровую базу, с трепетом - не порвётся ли связь. Да и сейчас мало что изменилось. Хоть не диал-ап, но траффик платный. И сам процесс бек-апа\восстановления базы самый ресурсоёмкий. Часто бывает что хостер просто посылает бек-апящегося юзера по тайм-ауту, или другой причине связанной с железом.

Ссылка на комментарий
Поделиться на других сайтах

Первый раз встречаю движок, который всё, кроме собственных сорцов хранит в БД...

 

У меня "головная боль" с 10-ю проектами на IP.B ("Головная боль" - корпоративные клиенты: создание проекта, администрирование и хостинг).

Есть определённая схема бэкапа:

  1. Зеркальная копия файлов
  2. Инкрементный бекап файлов.
  3. Бэкап БД (дробный бэкап)

Например регламент работы такой:

  • Зеркальная копия производится каждый день.
  • Инкрементный бэкап производится раз в час.
  • Бэкап БД каждый час.

Рассмотрим проект, у которого постоянный онлайн 250 человек, пик 2000. Дамп БД весит 300 Мб (рассматриваю дамп базы IP.B ) + на форуме около 1 Гб загружено пользователями (аттачи+аватары).

 

Пример схемы резервного копирования я привёл. Я рассмотрел только один проект, а если у меня этих проектов 10 и в среднем все они создают такую нагрузку. Это ж сколько я буду тратить ресурсов сервера на бэкап и какой мне нужен сервер, чтобы хостить такие проекты под булкой? (Замечу, что сейчас всё нормально с ресурсами и есть запас прочности).

 

P.S. vB упал в моих глазах и очень сильно, никому его советовать не буду...

Ссылка на комментарий
Поделиться на других сайтах

Дамп БД весит 300 Мб

форум (IPB), который я админю оффициально не считается таким уж крупным, БД весит ~450 метров, аттачи ~3гига, авки и фотки - понты, метров 300... + галерея, + блоги - все вместе, как ни крути - около 4.5 гиг - позвольте возмутиться - какой смысл все это пихать в базу и читать с нее все время? это же какой гемор сделать нормальный бекап с ее???!!! даже с учетом всемизвестногодампера!!!

Ссылка на комментарий
Поделиться на других сайтах

предполагалась борьба простых админов, а пошла пикировка техников))) а это уже намного интересней :D да и открываются движки с совсем другой стороны ))) и тут, фразы наподобие прозвучавшей со стороны Malcolm_Reed'а

Бедняжка, у вас проблемы с нагрузкой на хваленом вами же ипб? Может вы просто не умеете его готовить (оптимизировать) ?
попросту неуместны ;)
Ссылка на комментарий
Поделиться на других сайтах

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

В итоге основное дерево кода цементируется из-за модов. Разработчик боится потерять то большое количество совместимых модификаций, тем самым "обделив" новую версию.

 

В IPB с этим проще - люди привыкли.

 

К тому же не забываем, что в под обновлением у нас обычно подразумевается нажатие 2х кнопок - "установить плагин -> перезаписать поверх существующего" =\

А так же не забываем, что на каждый чих системы, есть событие, которое должно быть обработано диспетчером хуков, даже если на этом событии мода не было, нет и не будет.

Ссылка на комментарий
Поделиться на других сайтах

GiV, не будем спорить, хуки идея хорошая. отличная, я бы даже сказал, если бы они не были возведены во главу трона, так как это сделано в VB :D))))
Ссылка на комментарий
Поделиться на других сайтах


×
×
  • Создать...

Важная информация

Находясь на нашем сайте, вы соглашаетесь на использование файлов cookie, а также с нашим положением о конфиденциальности Политика конфиденциальности и пользовательским соглашением Условия использования.