Обзор социальных cms

Давайте напишем. Кто что юзал кратко описываем плюсы и минусы.
Если есть у кого желание написать расширенный обзор - пожалуйста.
Вы все войдете в аллею славы socengine.ru

Даешь описание минимум на 1000 символов на каждую cms с графиками, картинками, и результатами тестов!

social engine 3
+ распространенная, большое комъюнити
+ модов много
+ основные возможности социальных сетей присутствуют
+* код довольно простой и модули могут писать даже ламеры.
- говнокод
- закончена разработка
- тяжелый
- дорогой
-** горизонтальная масштабируемость, по-моему, исключена

* хз плюс это или минус
** уверен лишь на 95 процентов

---------- Сообщение добавлено в 01:59 ---------- Предыдущее сообщение было в 01:58 ----------

я конечно за. Но сам делать этого не буду гыгы
Лень одолевает

100%. Некуда и нечему там расти. Разве что наращивать сервера бд, но рано или поздно на основном сервере место закончится, или нагрузка на диски будет большая и всё - система благополучно ляжет.

Тогда и я пару слов, позлорадствую.

Social Engine 4.
+ Простая. Настолько простая что управлять ней можно даже одной кнопкой (иногда - это reset).
+ Есть всё чтобы создать маленькое сообщество. Например тесный семейный круг. Или можно разоряться на серверах и содержать всё это до тех пор, пока у вас не закончатся деньги или терпение.
Собственно и всё. Теперь минусы.
- Разработчики учатся на своих ошибках и совершенствуются...именно поэтому говнокод и нагрузка в этой версии велики как нигде. И являются образцом для подражания начинающих говнокодеров. Даже сотня посетителей может уложить намертво хороший дорогой vps.
- Глюки. Много глюков с разных местах.
- У разработчиков похоже началась темная эпоха, потому что последний список обновлений состоял практически из одних надписей "версия файла обновлена".
- Баги.
- За весь этот бред ещё и денег хотят.

_____
Ну и что, что не литературным языком и не в виде статьи. Зато от души.

social engine 3
+ универсальность
+ доступность
+ способность выдержать ламеров, у которых руки из жопы растут
+ производительность
+ масштабируемость
- неделя биения головой об стол для достижения последних 2х пунктов :stena:
- куча неведомой ****ой х*рни, которая там "просто так"
- свой класс для работы с БД
- Mootools!!!!

- слишком распространённая

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

Таким людям нечего делать в строении социальной сети.

заменяем дефолтный класс "SE Database" на ADODB.
урезаем лишние запросы, добавляем $key = value
собираем кластер из 2 mysql-серверов.
собираем 2 backend и 2 frontend (round-robin)

объединяем... и получаем приличную производительность.
была возможность это всё собрать (работаю в ИСП) - 130000 юзеров онлайн стабильно

MySQL Servers: Intel Xeon X5650, 8GB RAM, Intel SSD (Solaris 10)
WEB: Intel Xeon X5530, 4GB RAM (FreeBSD)

iWalker, Это не масштабируемость, а разврат, который выполнен к тому же костыльным способом. Получается добавляем в общее звено глюков ещё и кривую работу с транзакциями между звеньями кластера, поскольку стандартные средства mysql явно сделаны для галочки, и работают кое-как. Я могу собрать облако из 100 серверов в memcached и что, это разве назовется масштабируемостью? Молчу о крайне зыбкой надежности и производительности такой системы.

Видимо неактивных, либо скорость отдачи измеряется десятками секунд. К тому же - как вы решили проблему с дедлоками? Один сервер на 130k онлайн посетителей? На se3? Гм... Видимо здесь явно не обошлось без потусторонних сил, потому что система написанная куда лучше этой нечисти, и имеющая производительность больше минимум раз в 15 (и почти в 30 раз меньше запросов!) выдала на более мощном сервере куда меньший результат. Что-то здесь не так, причем очень сильно не так. Не находите?

iWalker, ну справедливости ради таким образом можно поступить с любой кмской Вообще любой.

На рабочих проектах такую схему лучше не делать. Будет очень плохо и обидно когда при оверлоаде транзакции будут вести себя очень странно, а мускул будет регулярно падать. Единственная реализация которая работает, а не создает проблемы - наращивание мощностей сервера БД до предельно допустимой мощности, затем плодить такие сервера через балансировку за которую отвечает отдельная часть и заведует днс в своем кластере. Остальное имхо создание проблем на пустом месте. Кто желает убедиться - поставьте такую схему на нагруженный проект с реальной нагрузкой. В 95% очень скоро вы вспомните эти слова, а так же очень много других.