устройство ЖЖ (техническое)
Jul. 30th, 2004 04:23 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaЕсли кто-то хочет узнать, как LiveJournal развивался от одного сервера к сегодняшнему устройству, и как это сегодняшнее устройство выглядит, советую почитать слайды, которые Брэд использовал для своего доклада на OSCON пару дней назад. Некоторые не очень значительные подробности и этапы большого пути там опущены, но всё основное и существенное упомятуто и вкратце разъяснено.
Эта ссылка только для технарей, предупреждаю. Если что-то там непонятно, можно меня спросить, я постараюсь объяснить.
Эта ссылка только для технарей, предупреждаю. Если что-то там непонятно, можно меня спросить, я постараюсь объяснить.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2004-07-30 06:29 am (UTC)no subject
Date: 2004-07-30 06:35 am (UTC)no subject
Date: 2004-07-30 06:47 am (UTC)no subject
Date: 2004-07-30 06:55 am (UTC)no subject
Date: 2004-07-30 06:56 am (UTC)no subject
Date: 2004-07-30 07:02 am (UTC)Но я не главный разработчик, а один из главных. Самый главный и важный - сам Брэд.
no subject
Date: 2004-07-30 07:03 am (UTC)Даа...
Date: 2004-07-30 07:27 am (UTC)no subject
Date: 2004-07-30 07:31 am (UTC)Re: Даа...
Date: 2004-07-30 07:32 am (UTC)no subject
Date: 2004-07-30 07:32 am (UTC)no subject
Date: 2004-07-30 07:36 am (UTC)no subject
Date: 2004-07-30 07:39 am (UTC)"Сбожией помощью" работает?
no subject
Date: 2004-07-30 07:41 am (UTC)no subject
Date: 2004-07-30 09:04 am (UTC)1. A зачем dist FS? Почему не хранить все в дазе банных?
2. На слайде Cache Disadvantages, было упомянуто что ставит cache между app и db - плохо. Почему? Можно иметь два слоя: один ближе к пользователю (static content) другой прямо перед db (dynamic content)..
3. Интересно, а что вы использовали для performance (и load) testing особенно когда стало так много пользователей?
no subject
Date: 2004-07-30 09:41 am (UTC)no subject
Date: 2004-07-30 10:14 am (UTC)no subject
Date: 2004-07-30 10:15 am (UTC)Ибо Jesus saves.
no subject
Date: 2004-07-30 10:36 am (UTC)no subject
Date: 2004-07-30 10:39 am (UTC)2) LJ устроен так, что по сути дела статического контента нет вообще. Каждая страница генерируется динамически; статические только юзерпики. Почти каждая страница должна выглядеть по-разному в зависимости от того, какой юзер logged in и на неё смотрит, т.е. от того, какую cookie его браузер посылает серверу. Поэтому на уровне сразу перед пользователем кэшируются только юзерпики (и это делает Akamai). memcached кэширует не целые страницы, а логические объекты: содержание записи, или атрибуты юзера, или данные пользовательского стиля, итд. итп. Ставить cache между app и db плохо потому, что тогда cache должен знать о db и говорить с ней, знать устройство таблиц и полей, списки DB-серверов итд. итп. Тогда cache во-первых становится столь же медленным in the worst case, как db, с которой он говорит, а во-вторых, становится очень сложным и его постоянно надо менять и развивать, по мере того как мы меняем базу данных. Он становится по сути дела частью app, только разбитой на много машин вместо одного вебсервера. Очень неустойчивая и неудачная конфигурация. У нас сделано по-другому. С точки зрения логической организации данных cache сидит-таки между app и db, но с точки зрения обмена данными они друг о друге не знают. app сначала пробует найди данные в cache, если их там нет - обращается к db. Когда есть новые данные, пишет их и туда, и туда. Это позволяет кэшу быть очень быстрым, простым, "глупым" и супер-оптимизированным (на скорость) компонентом системы. Он всего лишь хранит любые данные по ключу и возвращает их по ключу, ничего не зная об этих данных.
3) мы не нашли удобного готового решения, которое подходило бы к нашим нагрузкам и требованиям. В результате мы тестируем сами, с помощью скриптов, которые для этого пишутся и симулируют нагрузку. Для разных частей системы это делается разными способами. Потом, если это возможно, новый код запускается на небольшой части живых серверов, а не на всех; потом на всём живом сайте. Вообще говоря, сгенерировать искусственным образом правдоподобную нагрузку, соотвествующую той нагрузке, что мы видим на живых серверах, оказывается довольно сложным и не всегда возможным (без слишком больших затрат времени/труда) делом.
no subject
Date: 2004-07-30 11:11 am (UTC)Двухступенчатая система с кластеризацией юзеров - один к одному то, что мы делали в Комверсе.
no subject
Date: 2004-07-30 12:07 pm (UTC)no subject
Date: 2004-07-30 12:10 pm (UTC)2) Согласен - значит я просто неправильно понял слайд. Ставить cache между app и db плохо потому, что тогда cache должен знать о db и говорить с ней - да, потому что это называется не "cache", а "cache proxy". Под "cache" я имел ввиду как раз то что вы сказали дальше любые данные по ключу что и должно стаять между db и app. Hence my question. Короче теперь "мы на одной страннице" ;)
3) Ясно. Поэтому мне было интересно есть ли что-нибудь в OpenSource связанное с этой проблеммой. Я знаю несколько платный программ-монстров (из которий больше всего уважаю LoadRunner) - но они естественно бешенно дорогие.
no subject
Date: 2004-07-30 12:13 pm (UTC)Больше никаких особых текстов нет, увы, только код. Брэд подумывал пару раз о том, чтобы написать об этом книгу, но не факт, что из этого что-то выйдет.
no subject
Date: 2004-07-30 03:35 pm (UTC)...
3. LoadRunner, к сожалению, тут мало применим. Зффективно им можно симулировать лишь end-user load, и соответственно, мерять end-user experience. Что само по себе тоже очень важно, но составляет лишь заключительный этап тестирования. Покомпонентное или послойное тестирование по-прежнему приходится делать "в ручную". Если интересно, постараюсь расказать подробнее — мы на этом съели не одну собаку (я был почти 2 года консультантом по LR в Mercury, а затем ещё 3,5 - участвовал в написании собственно LR и его многочисленных "младших братьев").
Ваааау!
С Вашего позволения, я бы хотел задать несколько вопросов, но чуть по-позже!
Пока же, чтобы избегнуть дурацких вопросов, на которые давно есть ответы, подскажите — что ещё стоит почитать-поглядеть, чтобы составить представление о работе ЖЖ?
no subject
Date: 2004-07-30 08:43 pm (UTC)Сегодня как раз один из тех редких дней, когда ЖЖ не тормозит.
Это хороший день, чтоб задуматься о том, что к примеру, мсдн.ком выносит нагрузки того же порядка, что ЖЖ, работая на гораздо более простой, но более продуманной архитектуре. Возможно, ЖЖ платформа дешевле на порядок (но не на два), что скорее всего компенсируется maintanence efforts.
Вы меня простите, I'm a straight MS guy. I respect Sun solutions as well. Generally I respect all _working_ solutions (I've seen too many failed ones); this is why I respect the LJ architecture too.
Спасибо, Allehandro за правильные вопросы, спасибо, Avva за понятные ответы.
no subject
Date: 2004-07-30 09:37 pm (UTC)Именно с этой точки зрения я его и предлагал (и если использовать только для этой цели, как я и сказал, он слишком дорог). На то он и "Load Runner", не так-ли? Осуществив нужный user load, покомпонентный анализ делаeтся намного удобнее используя уже море profiling программ.
я был почти 2 года консультантом..
С удовольствием послушаю подробности и Ваши рекоммендации об алтернативах.Вот, Вы упомянули "end-user experience"... на сколько я понимаю, как раз эти способности у LoadRunner кажутся достаточно ограничеными. Например, мне может быть интересно не только сколько времени нужно что бы загрузить страницу (HTML,JavaScript,etc) к себе в браузер, но и сколько нужно для ее rendering (server-side) в случае скажем JSPs. Можно ли это исследовать LoadRunnerom с точки зрения того самого "end-user experience"?
no subject
Date: 2004-07-31 03:40 am (UTC)MSDN можно кешировать в статику весь, кроме поиска.
Думаю, так и делается.
Не то с ЖЖ.
no subject
Date: 2004-07-31 05:44 am (UTC):)
no subject
Date: 2004-07-31 06:43 am (UTC)2
no subject
Date: 2004-07-31 11:03 am (UTC)Также только в браузере клиента должны рисоваться украшения страницы (skins), LJ сервер должен лишь сообщать крошечный набор аттрибутов и вечно хранить в кэше мелкие гифы для украшений.
Логон и атрибуты скорее всего будут более эффективыно храниться (и scale) из специализированной быстрой базы данных, вроде LDAP.
Невозможно сказать, не копаясь в деталях, и слайды не дают достаточно информации, стоит ли архитекрутой LJ гордиться - или это всего лишь очередной kludge.
http://www.livejournal.com/users/sceptic_008/2402.html
no subject
Date: 2004-07-31 11:51 am (UTC)Для memcached возможность работы с клиентом через shared memory так и не планируется?
Кстати, по оптимизации гигабитной сетки еще какие-нибудь работы проводились (драйверы, роутинг etc)?
no subject
Date: 2004-07-31 11:52 am (UTC)no subject
Date: 2004-07-31 12:03 pm (UTC)Можно расшифровать вот эту вот гениальную мысль?
no subject
Date: 2004-07-31 12:04 pm (UTC)С этого момента осуждение можно завершить.
Склейте мне это в Netscape 4 и lynx, а потом продолжим.
no subject
Date: 2004-07-31 12:59 pm (UTC)no subject
Date: 2004-07-31 01:06 pm (UTC)no subject
Date: 2004-07-31 02:00 pm (UTC)- LDAP - специализированная база данных, он может быть быстрее БД общего пользования, даже если это MySQL
- LDAP scales easily; на нем можно городить хоть глобальную хранилку если LJ будет существовать в виде нескольких сайтов (mirrors или региональные центры)
- под authentication through LDAP существуют готовые модули в куче программ (apache, postfix, APIs from programming languages и т.д.)
- в LDAP встроены все необходимые для maintenance удобства.
Документация "настоящего", не opensource LDAP лежит на сайте Sun Microsystems. По схемам/архитектуре его применения сейчас есть ряд книг. На Нете можно найти гору информации.
Но все же главное, на мой взгляд - деление входящего потока и кэширование каждого поста. В качестве результата запроса клиенту отправляется skeleton page, которая вызовет, в основном из cache, отдельные посты для заполнения forum thread.
Весь traffic таким образом сжимается до разностных (differential) объемов, в БД проникают лишь запросы об изменениях.
Обслуживать веб-запросы большой интенсивности и растить фермы веб и cache серверов всегда легче, чем выдавать такие же объемы из баз данных.
no subject
Date: 2004-07-31 02:26 pm (UTC)Например, мне может быть интересно не только сколько времени нужно что бы загрузить страницу (HTML,JavaScript,etc) к себе в браузер, но и сколько нужно для ее rendering (server-side) в случае скажем JSPs. Можно ли это исследовать LoadRunnerom с точки зрения того самого "end-user experience"?
Ой, что-то я не пойму, как связан "end-user experience" и обработка страницы на стороне сервера... По-этому, отвечаю как понимаю: transaction breakdown всегда был большой бедой (под транзакцией мы здесь понимаем всё то, что происходило между тем, как юзверь нажал на "submit form" и до того момента, как в ответ пришла и показалась новая страница). Это проблематично, потому что нужно собирать информацию по дороге. Плюс, для многослойных систем (3 layers and more) нетривиальной задачей оказывается сопоставить нажатие конкретной кнопки в UI с тем, что произошло в базе данных.
В принципе, для WEB, J2EE и Oracle в LR есть общие решения (поройтесь в документации: transaction breakdown). Для WEB и Oracle результат можно посмотреть в Analysis.
Для J2EE - совсем красиво, всё видно сразу в Online на уровне вызовов отдельных методов; но это появилось, по-моему, лишь с версии 7.8 и нужна специальная лецензия.
В принципе, если есть доступ к коду на server-side, можете поставить марекры в страницу (скажем, HTML-комментарий: страница сгенерировалась за надцать секунд), а в LR-скрипте эти маркеры вылавливать и обрабатывать (например, посылать data points).
Вот так вот, вкратце:-)))
no subject
Date: 2004-08-01 09:13 am (UTC)no subject
Date: 2004-08-02 12:57 pm (UTC)no subject
Date: 2004-08-02 01:00 pm (UTC)no subject
Date: 2004-08-02 01:15 pm (UTC)no subject
Date: 2004-08-02 01:23 pm (UTC)Писать CGI на С - это тяжелая и неблагодарная работа. Я бы не стал такое делать без крайней на то необходимости. А в случае с ЖЖ, я очень сомневаюсь что Perl - это bottleneck.
no subject
Date: 2004-08-02 01:30 pm (UTC)Ладно, я не буду говорить про C, т.к. сначала нужно говорить о том, что LB как раз один из критических участков. Больше не спорю :)
no subject
Date: 2004-08-02 10:46 pm (UTC)no subject
Date: 2004-08-03 03:11 am (UTC)Анонимные серверные прокси + VPN + Выделенные сервера.
Date: 2017-05-26 12:24 pm (UTC)[url=http://proxyelite.biz]socks5 proxy italy[/url]