Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет Misha Verbitsky ([info]tiphareth)
@ 2005-07-16 00:43:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Настроение: tired
Музыка:godspeed you black emperor! - F#A#infinity

на предмет окончательного утверждения правил
Собирались сегодня на предмет
окончательного утверждения правил. В общих чертах, утвердили:

http://imperium.lenin.ru/LENIN/33/NPJ-LJ/tos.html
http://imperium.lenin.ru/LENIN/33/NPJ-LJ/ustav.html
http://imperium.lenin.ru/LENIN/33/NPJ-LJ/guidelines.html

С правками от [info]r_l@lj, который участвовал через
микрофон и динамики.

Также утвердили Попечительский Совет:

  • Вадим Гущин
  • Иван Давыдов
  • Константин Крылов
  • Роман Лейбов
  • Максим Мошков
  • Антон Носик
  • Миша Вербицкий

  • В Попечительский Совет кооптируется
    (с правом совещательного голоса) системная
    администрация сервера LJR; в случае раздела
    голосов, совещательный голос становится
    решающим.

Были разговоры о привлечении юриста (козырной кандидатурой
является прекрасный [info]lqp@lj), но дальше разговоров
дело не пошло. Миша Беленький придумал прекрасное название
общественной организации, которая будет это дело обеспечивать:
"Правозащитное объединение "Русский Живой Журнал".

Окончательное открытие сервера назначено на понедельник вечером.
До того момента Денис [info]mironovd@lj, который здесь
главный по системной части, просил адреса lj.rossia.org
не публиковать, ссылаясь на то, что все еще очень сыро.
Придется уважить. Моя функция на текущий момент
(правила и попечители) выполнена.

Петя [info]nit@lj посчитал физические пределы
числа пользователей, которые могут сюда одновременно
подключаться, получилось 600. По масштабам LJ.com, довольно
мало. Другое дело, что в большинстве серверов максимум
установлен на 50-100 примерно, даже на таких
серверах, где пользователей по 50 тысяч в день.
Что и понятно - если их 50 тысяч в день, то в пик
их 3 тысячи в час; если считать, что в этот час
каждый 1-2 минуты чего-то грузит (а все остальное
время читает), то и получается как раз по 100
одновременных коннектов.

На imperium.lenin.ru их больше 50 редко бывает,
хотя траффик колоссальный совершенно.

Отдельная задача - как снискать денег на фундаментальный
проект написания распределенного сервера
с функциональностью LJ. Даже если русское блоггерское
сообщество в ближайшие 2-3 года не потребует много ресурсов,
распределенность упрощает администрирование и борьбу
с цензурой неимоверно.

Привет

(Читать комментарии) - (Добавить комментарий)


[info]nit
2005-07-16 05:21 (ссылка)
> это число можно относительно безболезненно увеличить переходом на другой http-сервер

И другой http-сервер будет перехватывать перловые вызовы DBI->connect
и правильно их канализировать?

Там разговор шел исключительно о mysql+innodb на Linux/IA-32.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]polter
2005-07-16 05:51 (ссылка)
ну я и не писал, что такой транзишен можно устроить даром.
В случае с Apache 2.x переход может быть относительно легким, в случае с nginx и ему подобными конечно может потребоваться относительно серьезная переделка уровня общения с базой данных, зато они (сервера на edge-triggered notification) несколько тысяч одновременных коннектов не чихнув обслуживают.

есть вариант почти задаром - двухуровневая система отдачи контента.
Apache 1.3 в качестве "тяжелого" бэкенда и легкий проксирующий сервер типа Apache 2.0 или nginx перед ним.

при поступлении запроса от пользователя, тяжелый апач быстро отдает контент фронтенду и тут же опускается, а легкий сервер уже работает дальше, не особо загружая сервер. Тут еще пара положительных моментов - 1. Легкие сервера могут отдавать еще и статический контент (картинки/js/css/etc) 2. И Apache 2.x и nginx могут использовать sendfile(2) для отдачи контента, что дополнительно и очень заметно сказывается на загрузке сервера.

Такая система, по опыту, даже если в качестве фронтенда используется апач 1.3 с mod_accel, но без modperl'a уже дает ощутимый выигрыш в производительности.

P.S
Я пока что вообще не знаю как работает LJ и какие оптимизационные схемы в нем уже используются. Меня просто смутило столь небольшое число возможных одновременных коннектов и то, что контент в данном случае отдает старый и тяжелый апач, да еще и со встроенным модперлом (судя по response headers сервера)
Если я чего-то не учел, поправьте меня.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]nit
2005-07-16 12:19 (ссылка)
У нас тут недопонимание. Цифра 600 -- это в районе максимального
количества подключений к базе mysql с движком innodb на
32-битном Linux/x86 (насчет IA-32 я наврал, мозг за разум зашел).

Она не зависит ни от процессора, ни от памяти, ни от http-сервера.
Просто такова жизнь. По крайней мере так написано в документации,
а у меня пока нет повода ей не доверять.

Движок lj, насколько я понимаю, при каждом новом обращении пользователя
открывает подключение к базе, получает информацию, закрывает
подключение к базе.

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

Кэширующий/проксирующий http-сервер, наверное, тоже поможет,
но если в ваших терминах "тяжелый бэкенд" будет работать с базой,
как описано выше, то выигрыш будет, видимо, сильно меньший,
чем если все-таки переписать работу с бд.

Или я тоже вас неправильно понял? :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]polter
2005-07-16 13:08 (ссылка)
хм...

У нас тут недопонимание. Цифра 600 -- это в районе максимального
количества подключений к базе mysql с движком innodb на
32-битном Linux/x86 (насчет IA-32 я наврал, мозг за разум зашел).

Количество коннектов к базе и количество коннектов по http - это разные, никак совершенно не связанные вещи. Еще, конечно, это не связано с архитектурой центрального процессора и с форматом таблиц в базе данных. Кстати IA-32 и x86-32 - это одно и то же. Различаются IA-64 и x86-64, но, впрочем, к делу это не относится. Ну и еще mysql будет поддерживать столько коннектов, сколько ему в max_connections сказать. Mysql на threads работает, соответственно ресурсов каждое подключение почти не требует.

Движок lj, насколько я понимаю, при каждом новом обращении пользователя
открывает подключение к базе, получает информацию, закрывает
подключение к базе.

Я не видел ни байта кода LJ, но я очень сильно сомневаюсь в этом.

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

Я не совсем понимаю почему такая суета вокруг именно количества подключений к базе данных. Оно не равно количеству подключенных по HTTP пользователей, при правильной организации процесса. И не является проблемой. А вот что интереснее - стоит ли сейчас здесь memcached, который стоит на livejournal.com?

Кэширующий/проксирующий http-сервер, наверное, тоже поможет,
но если в ваших терминах "тяжелый бэкенд" будет работать с базой,
как описано выше, то выигрыш будет, видимо, сильно меньший,
чем если все-таки переписать работу с бд.

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

Если же переписывать еще и работу с БД, которая, я уверен, вовсе не является тут bottleneck'ом, то тогда уже нужно и менять модель работы с HTTP-сервером, чтобы избавляться от модперла и Apache 1.x, которые и являются основным ограничителем в большинстве подобных систем, что я видел.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]nit
2005-07-16 13:44 (ссылка)
Неохота чатиться, я не мастак.
Сорри.

(Ответить) (Уровень выше)


[info]drz
2005-07-20 07:39 (ссылка)
"Движок lj, насколько я понимаю, при каждом новом обращении пользователя
открывает подключение к базе, получает информацию, закрывает
подключение к базе."

Ужас какой-то. Давно ведь уже есть такое понятие как пул коннектов.

(Ответить) (Уровень выше)


[info]drz
2005-07-20 07:36 (ссылка)
"И другой http-сервер будет перехватывать перловые вызовы DBI->connect
и правильно их канализировать?"

А пул коннектов?

(Ответить) (Уровень выше)

(Читать комментарии) -