В черговий раз хочу запропонувати свій переклад статті, на цей раз автор Тодд Хофф, і його стаття присвячена архітектурі WhatsApp на момент його покупки Facebook.
Ремарка: на початку статті міститься міркування автора оригіналу про те, навіщо Facebook купив WhatsApp за нечувані 19 мільярдів. Якщо це вам не цікаво - просто прогортайте, опис архітектури буде нижче.
Рік Рід в його майбутній березневій доповіді, названій "Мільярд з великою'М': Наступний рівень масштабування в WhatsApp "розкриває карколомну статистику WhatsApp:
Що має сотні вузлів, тисячі ядер, сотні терабайт RAM і сподівається обслужити мільярди смартфонів, які незабаром стануть реальністю по всьому світу? Заснована на Erlang і FreeBSD архітектура WhatsApp. Ми зіткнулися з багатьма труднощами при задоволенні постійно зростаючого попиту на наш сервіс обміну повідомленнями, але ми продовжуємо розширювати нашу систему з точки зору розміру (> 8000 ядер) і з точки зору швидкості (> 70М повідомлень Erlang в секунду).
Але оскільки у нас ще немає цієї доповіді, давайте подивимося на доповідь, яку Рік Рід зробив два роки тому: «Масштабування до мільйонів одночасних з'єднань».
Маючи досвід розробки високопродуктивної шини повідомлень на C++ в Yahoo, Рік Рід не новачок у світі масштабованих архітектур. Засновники WhatsApp це також колишні співробітники Yahoo з чималеньким досвідом у масштабуванні систем. Так що WhatsApp працює за рахунок їх навичок масштабування. А оскільки їх Велика Зухвала мета в тому, щоб бути на кожному смартфоні в світі, яких протягом декількох років буде близько 5 мільярдів, їм буде потрібно весь цей досвід.
Перш ніж ми перейдемо до фактів, давайте відвернемося на цю вражаючу загадку: як WhatsApp взагалі міг бути оцінений Facebook в $19 мільярдів?
Якщо ви запитаєте мене як програміста, чи коштує WhatsApp таких грошей, то я відповім, що, зрозуміло, ні! Це просто відправка даних по мережі! Ну справді. Правда, я з тих, хто вважає, що блог-платформи не потрібні, тому що немає нічого складного в тому, щоб віддалено підключитися до сервера, відкрити index.html за допомогою vi і написати ваш пост в HTML. Мені потрібен був час, щоб зрозуміти, що розробка - це не написання тупого коду, це спосіб зробити так, щоб всі ті користувачі полюбили ваш продукт, що найскладніше. Любов не купиш.
Так що ж робить WhatsApp таким цінним? Технологія? Не звертайте уваги на тих, хто говорить, що за тиждень зможе написати WhatsApp на PHP. Це просто неправда. Як ми побачимо, це досить круті технології. Але, зрозуміло, у Facebook достатньо ресурсів, щоб розробити WhatsApp, якби вони захотіли.
Давайте подивимося на особливості. Ми всі знаємо, що WhatsApp це продукт без хитрощів (немає реклами, ігор, хитрощів) з відданими користувачами по всьому світу. Він пропонує безкоштовні повідомлення в суворому світі, де рахунки за SMS можуть бути жахливими. Як приїжджого американця, мене дуже здивувало те, як багато справжніх людей використовують WhatsApp щоб дійсно залишатися на зв'язку зі своєю сім'єю і друзями. Так що коли ви берете WhatsApp, то найімовірніше, що люди, яких ви знаєте, вже там, так як у всіх є телефон, який усуває проблему порожньої соціальної мережі. Він агресивно-крос-платформенний, так що всі, кого ви знаєте, може використовувати його і він просто буде працювати. Фраза він «» просто працює «» часто використовується. Він має всі можливості (можна поділитися місцем розташування, звуком, відео, картинки, push-to-talk, голосові повідомлення і фото, оповіщення про доставку, групові чати, відправка повідомлень через WiFi, і все це може бути зроблено незалежно від того, в мережі адресат чи ні). Він також підтримує відображення національних систем писемності. А використання номера мобільного телефону як ідентифікатора і контактів як соціального графа диявольськи просто. Немає підтвердження електронною поштою, імені користувача і пароля, номер кредитної картки не потрібен. Він просто працює.
Це все круто, але воно не коштує $19 мільярдів. Інші продукти можуть позмагатися з ним в плані можливостей.
Можлива причина в тому, що Google хотів купити WhatsApp, запропонувавши 99 центів за користувача. Це загроза для Facebook, вони просто у розпачі. Ці гроші запропоновані за вашу телефонну книгу і за метадані (навіть враховуючи те, що WhatsApp їх не зберігає).
Це за 450 мільйонів активних користувачів зі зростанням на мільйон щодня і потенціалом у мільярд користувачів. Facebook'y потрібен WhatsApp для отримання наступного мільярда користувачів. Але якщо це і так, то це тільки частина. І ціна в приблизно $40 за користувача не виглядає неадекватною, особливо при оплаті акціями. Facebook купив Instagram за ціною $30 за користувача. Користувач Twitter коштує $110.
Бенедикт Еванс заявляє, що ринок мобільного зв'язку становить більше трильйона доларів, а WhatsApp підриває частину цієї індустрії, що відноситься до SMS, яка приносить дохід в $100 мільярдів, відправляючи 18 мільярдів повідомлень в день, в той час як глобально відправляється тільки 20 мільярдів SMS. З фундаментальним переходом від персональних комп'ютерів до майже універсальних смартфонів, розмір можливостей дорівнює значно більшому цільовому ринку, ніж той, який звичний Facebook.
Але Facebook обіцяв, що не буде ні реклами, ні об'єднання сервісів, так в чому вигода?
Має місце цікавий розвиток бізнесу через використання мобільних технологій. WhatsApp використовується для створення групових обговорень командами проектів, а інвестори обговорюють хід угод через WhatsApp.
Instagram використовується в Кувейті для торгівлі вівцями.
WeChat, конкурент WhatsApp, у січні запустив сервіс найму таксі, за перший місяць було найнято 21 мільйон машин.
З майбутнім електронної комерції, що надсилається мобільними додатками для надсилання повідомлень, чи варто зіграти на цьому полі?
Не тільки бізнес користується WhatsApp для завдання, які колись вирішувалися настільними або веб-додатками. Поліція Іспанії використовує WhatsApp для затримання злочинців, італійці організують баскетбольні команди з його допомогою.
Комерційні та інші додатки переходять на мобільні телефони з очевидних причин. У кожного є телефон, а ці месенджери сповнені можливостей, безкоштовні і дешеві у використанні. Вам більше не потрібен настільний комп'ютер, щоб зробити справи. Безліч функцій може бути перекрито мобільним додатком.
Таким чином, миттєві повідомлення це загроза для Google і Facebook. Настільні комп'ютери мертві. Веб помирає. Миттєві повідомлення + мобільні технології - це екосистема, здатна їх замінити. Миттєві повідомлення стали центром взаємодії в мобільних технологіях, а не пошук, змінюючи те, пошук і природу того, які програми завоюють майбутнє. Ми не просто передуємо PceRank, ми передуємо веб.
Facebook повинен потрапити на цей ринок, або стане марним.
З переходом у мобайл, ми бачимо депорталізацію Facebook. Його настільний інтерфейс - це портал, що надає доступ до всіх можливостей бекенду. Він великий, заплутаний і скрипучий. Та кому взагалі подобається інтерфейс Facebook?
Коли Facebook прийшов на мобільні пристрої, вони спробували портальний підхід і він не спрацював. Так що вони перейшли до стратегії маленьких, більш сфокусованих додатків для одного завдання. Mobile first! На маленькому екрані можна зробити не так багато. На мобільнику простіше знайти окремий додаток, ніж меню, закопане глибоко в надра заплутаного портального додатку.
Але Facebook йде на крок попереду. Вони не тільки розробляють окремі програми для конкретних завдань, вони надають кілька конкуруючих додатків, що надають схожу функціональність, і ці програми не обов'язково мають загальний бекенд. Ми бачимо це на прикладі WhatsApp і Messenger, а Instagram конкурує з фотографіями на Facebook. Paper це альтернативний інтерфейс Facebook, який надає обмежену функціональність, але те, що він робить, він робить добре.
Тут може бути застосовано закон Конвея. Ідея в тому, що «» організації, які проектують системи... зазвичай породжують архітектуру, що копіює комунікаційну структуру цих організацій «». З монолітною інфраструктурою бекенду ми отримаємо портальний дизайн, схожий на Борга. Перехід до мобільних технологій звільняє організації від такого мислення. Якщо можуть бути розроблені програми, що використовують тільки частину інфраструктури Facebook, тоді можуть бути розроблені програми, що зовсім не використовують інфраструктуру Facebook. А якщо вони не використовують інфраструктуру Facebook, то вони можуть бути розроблені не в Facebook. Що ж тоді Facebook?
CEO Facebook Марк Цукерберг має свою точку зору, озвучену на конференції Mobile World Congress, що полягає в тому, що поглинання WhatsApp тісно пов'язане з Internet.org:
Ідея в тому, щоб розробити набір базових безкоштовних інтернет сервісів - «» 911 інтернету «». Це може бути соціальна мережа, як Facebook, месенджер, може бути пошук, і інші речі, на зразок погоди. Набір цих безкоштовних сервісів буде працювати як свого роду наркотик - користувачі, які можуть собі дозволити послуги передачі даних і телефони просто не бачать сенсу в тому, щоб платити за ці сервіси. Це дасть їм деякий контекст, який покаже їм, чому сервіси важливі і це підштовхне їх до оплати інших подібних сервісів - є така надія.
Це довга гра, але вона містить достатньо цінностей, щоб мало сенс в неї грати.
Чи ми дійшли згоди? Не думаю. Це вражаюча кількість доларів, короткострокова вигода від яких неочевидна, так що пояснення як довгострокова гра має деякий сенс. Ми як і раніше на зорі мобільних технологій. Ніхто не знає, як буде виглядати майбутнє, так що краще не намагатися змусити майбутнє виглядати як минуле. Схоже, що Facebook чинить саме так.
Але вистачить цього. Як би ви обслуговували 450 мільйонів активних користувачів силами всього 32 інженерів? Давайте подивимося...
Джерела
Попередження: ми знаємо не так багато про архітектуру WhatsApp в цілому. Просто фрагменти і обривки, зібрані з різних джерел. Доповідь Ріка Ріда присвячена оптимізації, що дозволила обробляти 2 мільйони з'єднань на одному сервері використовуючи Erlang, а не огляду всієї архітектури.
- Scaling to Millions of Simultaneous Connections, 2012 року (слайди) від Ріка Ріда
- Інтерв'ю Erlang Factory з Ріком Рідом
- Інтерв'ю з Юджином Фуксманом (Eugene Fooksman) з WhatsApp про Erlang
- DLD14 — What's Up WhatsApp? (Jan Koum, David Rowan)
- yowsup був OpenSource-варіантом API WhatsApp. Репозиторій тепер недоступний через скаргу відповідно до DMCA, але вони документували деякі нутрощі WhatsApp. Різноманітність скрізь.
- Деякі джерела у Зв "язаних роботах
Статистика
Ця статистика, в основному, для поточної системи, а не для системи, доповідь про яку у нас є. Доповідь про поточну систему буде включати більше інформації про хаки для зберігання даних, обміну повідомленнями, мета-кластеризації, і більше про патчах для BEAM/OTP.
- 450 мільйонів активних користувачів, досягли цієї цифри швидше, ніж будь-яка інша компанія в світі.
- 32 інженери, один розробник припадає на 14 мільйонів активних користувачів.
- 50 мільярдів повідомлень щодня на семи платформах (вхідні і вихідні).
- Більше мільйона нових користувачів реєструються щодня.
- $0 витрачено на рекламу.
- $60 мільйонів інвестицій від Sequoia Capital; $3.4 мільярда Sequoia заробить.
- Facebook витратив 35% готівки на угоду.
- Сотні вузлів.
- Понад 8000 процесорних ядер.
- Сотні терабайт RAM.
- Понад 70 мільйонів повідомлень Erlang в секунду.
- У 2011 WhatsApp досяг мільйона активних TCP з'єднань на одному сервері за наявності вільної пам'яті і ресурсів CPU. У 2012 досягли 2х мільйонів з'єднань. У 2013 вони твітнули: "31 грудня ми встановили новий рекорд: 7 мільярдів вхідних повідомлень, 11 мільярдів вихідних повідомлень = 18 мільярдів повідомлень оброблено за один день! З Новим, 2013м! "
Платформа
Бекенд
- Erlang
- FreeBSD
- Yaws, lighttpd
- PHP
- Свої патчі для BEAM (BEAM цей як JVM для Java, але для Erlang)
- Власний XMPP
- Хостинг, можливо, від Softlayer
Фронтенд
- Сім клієнтських платформ: iPhone, Android, Blackberry, Nokia Symbian S60, Nokia S40, Windows Phone, ?
- SQLite
Апаратне забезпечення
- Стандартний сервер користувачів:
- Два 6-ядерні процесори архітектури Westmere (24 логічні процесори);
- 100GB RAM, SSD;
- Два мережеві інтерфейси (публічний інтерфейс для зв'язку з користувачами, внутрішній для бекенду)
Продукт
- Фокус на обміні повідомленнями. З'єднання людей по всьому світу, незалежно від того, де вони знаходяться, без необхідності платити багато грошей. Засновник Ян Кум пам'ятає, як складно було в 1992 зв'язатися з сім'єю по всьому світу.
- Приватність. Сформовано спогадами Яна Кума від дорослішання в Україні, де не було нічого приватного. Повідомлення не зберігаються на серверах; історія чатів не зберігається; мета - знати про користувач якомога менше; ваше ім'я і стать невідомі, історія чату зберігається тільки на вашому телефоні.
Загальне
- Сервер WhatsApp практично повністю написаний на Erlang.
- Серверні системи, що здійснюють маршрутизацію повідомлень написані на Erlang.
- Великим досягненням є те, що така велика кількість користувачів обслуговується невеликою кількістю серверів. Команда сходиться на думці, що, багато в чому, це завдяки Erlang.
- Варто відзначити, що Facebook Chat був написаний в 2009 на Erlang, але згодом від цієї мови відмовилися, так як було складно знайти кваліфікованих програмістів.
- Сервер WhatsApp виріс з ejabberd
- Ejabberd - це знаменитий сервер Jabber, з відкритим вихідним кодом, написаний на Erlang.
- Спочатку він був обраний так як він відкритий, має відмінні відгуки розробників, з ним легко почати роботу і є гарантія того, що Erlang підходить для великих комунікаційних систем в довгостроковій перспективі.
- Наступні кілька років були витрачені на переписування і модифікування невеликого числа частин ejabberd, включаючи перехід з XMPP на свій протокол, реструктуризацію кодової бази, перепроектування декількох ключових компонентів і внесення безлічі важливих змін у віртуальну машину Erlang для оптимізації продуктивності.
- Щоб обробити 50 мільярдів повідомлень на день, потрібно сфокусуватися на побудові надійної системи, яка працює. Про монетизацію слід думати пізніше, вона сильно попереду по дорозі.
- Основний індикатор «» здоров'я «» системи це довжина черги повідомлень. Довжина черги повідомлень всіх процесів на одному вузлі постійно відстежується і оповіщення розсилається, коли вона стає довшою допустимого значення. Якщо один або кілька процесів відстає від інших, і для нього було надіслано попередження, то це ознака чергового вузького місця.
- При відправці мультимедіа повідомлення, зображення, аудіо або відео відправляються на HTTPS сервер, а потім адресату надсилається посилання на вміст, разом із закодованою в Base64 мініатюрою.
- Деяка кількість коду викладається щодня. Зазвичай, це відбувається кілька разів на день, але викладка не відбувається під час звичайних пікових навантажень. Erlang дозволяє агресивно підходити до викладання виправлень або нових можливостей на продакшен. Гаряча заміна коду означає, що оновлення викладаються без перезавантажень або перенаправлення трафіку. Помилки зазвичай можуть бути виправлені дуже швидко, також за допомогою гарячої заміни. Такі системи мають тенденцію бути слабкозв'язаними, що полегшує інкрементальну викладку змін.
- Який протокол використовується в програмі WhatsApp? SSL сокет поділяється між пулом серверів. Всі повідомлення організуються в чергу на сервері до тих пір, поки клієнт не підключиться для їх отримання. Повідомлення про успішне отримання повідомлення надсилається півночі WhatsApp, який перенаправляє його вихідному відправнику (який побачить його у вигляді «» галочки «» біля повідомлення). Повідомлення видаляються з пам'яті сервера, тільки-но клієнт його прийняв.
- Як процес реєстрації реалізований всередині WhatsApp? WhatsApp використовував IMEI телефону для створення імені та пароля користувача. Нещодавно це змінили. Тепер WhatsApp використовує звичайний запит від програми, щоб відправити унікальний 5-і символьний PIN. WhatsApp потім відправляє SMS з цим кодом на вказаний номер телефону (це означає, що клієнт WhatsApp більше не повинен бути запущений на цьому ж телефоні). На основі PIN-коду додаток запитує унікальний ключ у WhatsApp. Цей ключ використовується як пароль для наступних викликів (цей "постійний" "ключ зберігається на пристрої). Це також означає, що реєстрація нового пристрою робить ключ на старому пристрої недійсним.
- На Android використовується сервіс push-нотифікацій Google.
- Користувачів Android більше. Робота з Andoid приносить більше задоволення. Розробники можуть зробити прототип і миттєво розіслати сотням мільйонів користувачів, якщо є якась проблема, вона може бути швидко виправлена. З iOS все не так просто.
Завдання щодо 2 + мільйонів з "єднань на сервер
- Вони зіткнулися з великим припливом користувачів, що є позитивною проблемою, але також означає необхідність витрачати гроші на покупку додаткового апаратного забезпечення і складність управління всіма цими машинами.
- Необхідно планувати сплески трафіку. Прикладами можуть служити футбольні матчі та землятресіння в Іспанії та Мексиці. Це відбувається при практично пікових навантаженнях, так що повинно бути достатньо вільної ємності щоб впоратися з піками і сплесками. Недавній футбольний матч призвів до стрибка на 35% кількості вихідних повідомлень, рівно під час денного піку.
Засоби та технології, що використовуються для підвищення масштабованості
- Розробили засіб відстеження стану системи (wsar):
- Записує характеристики всієї системи, включаючи характеристики ОС, заліза, BEAM. Вона була розроблена такою, що до неї легко підключати метрики від інших систем, таких як заміри віртуальної пам'яті. Система відстежує споживання CPU, загальну завантаженість, user time, system time, час обробки переривань (interrupt time), перемикання контексту, винятки, прийняті/надіслані пакети, загальну кількість повідомлень у чергах процесів, події з зайнятими портами, трафік, передані/прийняті байти, статистика планувальника, статистика збиральника і так далі.
- Спочатку збір інформації запускався раз на хвилину. З ростом завантаженості системи потрібно скоротити період опитування до однієї секунди, так як події, що відбулися протягом однієї хвилини були невидимі. Це дійсно добре деталізована статистика, що дозволяє побачити, як все працює.
- Апаратні лічильники продуктивності CPU (pmcstat):
- Дивляться завантаженість процесора в часі. Це дозволяє дізнатися, скільки часу витрачається на виконання віртуальної машини. У їх випадку це 16%, що означає, що тільки 16% часу йде на виконання коду для віртуальної машини, так що навіть якщо б вони змогли прибрати весь час, протягом якого виконується Erlang код, то це заощадило б тільки 16% від усього часу роботи системи. Це передбачає, що слід сфокусуватися на інших областях, щоб збільшити ефективність системи.
- dtrace, kernel lock-counting, fprof
- Dtrace використовувався в першу чергу для зневадження, а не для контролю продуктивності.
- Вони пропатчили BEAM під FreeBSD, щоб отримати CPU time stamp.
- Написали скрипти, щоб отримати агрегований огляд з усіх процесів, щоб зрозуміти, на що витрачається час.
- Найбільшим досягненням була компіляція емулятора з увімкненим лічильником блокувань.
- Деякі проблеми
- Раніше було помічено, що багато часу йде на процедури складання сміття, це було виправлено.
- Помітили деякі проблеми з мережевим стеком, але вирішили їх налаштуванням.
- Більшість проблем були викликані станом гонок за блокування, що серйозно відбивається на виведенні від лічильника блокувань.
- Вимірювання:
- Синтетичні навантаження, тобто генерація трафіку вашими скриптами, мають мало сенсу для налаштування працюючих з користувачами систем величезного розміру.
- Працювало непогано для простих інтерфейсів, таких як таблиця користувачів, генеруючи вставки і читання так швидко, як тільки можливо.
- Якщо сервер може обробити мільйон з'єднань, потрібно 30 вузлів, щоб відкрити потрібну кількість IP-портів, щоб згенерувати достатньо з'єднань для сервера. Для сервера, що тримає два мільйони з "єднань, потрібно 60 вузлів. Складно створити такий масштаб.
- Складно згенерувати трафік, як при реальному використанні. Можна припустити нормальне навантаження, але в реальності виявляться мережеві події, всесвітні події, а з причини мульти-платформенності, виявляться відмінності в поведінці клієнтів і відмінності по країнах.
- Об'єднане навантаження:
- Візьміть звичайний трафік від продакшену і направте його на окрему систему.
- Це дуже зручно для систем, де сайд-ефекти можуть бути обмежені. Ви не хочете переспрямувати трафік і робити те, що може вплинути на постійний стан користувачів або привести до декількох копій повідомлення, надісланих користувачам.
- Erlang підтримує гарячу заміну коду, так що можна перебуваючи під повним навантаженням щось придумати, скомпілювати, завантажити зміну, поки програма працює, і миттєвою побачити, краще стало або гірше.
- Вони додали перемикачі, щоб динамічно змінювати навантаження від продакшену і бачити, як це позначиться на продуктивності. Вони будуть читати висновок від sar, дивлячись на завантаження CPU, споживання пам'яті, відстежувати переповнення черг, а потім перемкнуть перемикачі, щоб побачити, як система відреагує.
- Реальні навантаження
- Абсолютний тест. Виконання завдань як вводу, так і виводу.
- Внесіть сервер у DNS кілька разів, тож він отримуватиме вдвічі або втричі більше трафіку, ніж зазвичай. Це створює проблеми з TTL, оскільки клієнти ігнорують TTL від DNS, що створює затримку, і не можна швидко відреагувати на отримання більшого обсягу трафіку, який потрібно обробити.
- Переспрямуйте трафік від одного сервера до іншого, щоб отримати необхідну кількість клієнтських з'єднань. Є , що викликає kernel panic, так що це не дуже добре працює.
- Результати:
- Почали з 200 тис. одночасних з'єднань на сервер.
- Перше вузьке місце виявилося на 425 тисячах. Система увійшла в стан безлічі блокувань. Робота зупинилася. Звернулися до планувальника, щоб виміряти, скільки корисної роботи виконується, скільки процесів очікує, скільки в блокуваннях. Під навантаженням зросли очікуючі, так що використовувалося 35-45% CPU, 95% з яких споживали планувальники.
- Перший етап виправлень дозволив досягти мільйона з'єднань.
- Споживання пам'яті склало 76%, процесор був завантажений на 73%. BEAM споживав 45% ресурсів, що близько до значення споживання ресурсів з простору користувача, це добре, оскільки BEAM працює від імені користувача.
- Зазвичай, споживання CPU це не найвдаліша метрика, оскільки планувальник теж споживає CPU.
- Через місяць, після виправлення пляшкових горлечок, досягли двох мільйонів сполук.
- BEAM споживає 80% пам'яті, близько до показника, коли FreeBSD починає вивантажувати сторінки з пам'яті. Споживання CPU приблизно таке ж, але з дворазовим приростом кількості з'єднань. Планувальник стикається з блокуваннями, але працює досить непогано.
- Виглядало як хороший момент, щоб зупинитися, тому почали профілювати код на Erlang.
- Спочатку було два процеси на кожне з'єднання. Скоротили до одного.
- Невеликі зміни роботи з таймерами.
- Досягли піку на 2.8 мільйона з'єднань на сервер
- 571 тисяча пакетів в секунду, більше 200 тис повідомлень в секунду.
- Зробили кілька оптимізацій роботи з пам'яттю. і її споживання скоротилося до 70%.
- Пробували 3 мільйони з'єднань, але не вийшло.
- Коли система під навантаженням, черги повідомлень зростають. Або одна черга, або кілька відразу.
- Вони додали в BEAM механізм з відстеження черг повідомлень для кожного процесу окремо. Відстежують, як багато повідомлень прийнято і відправлено, наскільки швидко.
- Заміри виробляються кожні 10 секунд, можна побачити, що якщо у процесу в черзі 600 тисяч повідомлень, із затримкою 15 секунд і витяганням з черги 40 тисяч повідомлень, то очікуваний час очищення черги складе 41 секунду.
- Висновки:
- Erlang + BEAM + їхні патчі - чудове масштабування на SMP. Майже лінійне масштабування. Вражаюче. Можна запустити систему, що споживає 85% CPU і вона буде продовжувати працювати під реальними навантаженнями. Вона може працювати так хоч весь день.
- Привіт програмної моделі Erlang.
- Чим більше сервер працює, тим більше довгоживучих з'єднань він збере, ці з'єднання більшу частину часу знаходяться в стані очікування, так що сервер може обробити ще більше з'єднань, оскільки ці з'єднання не так завантажені, як інші.
- Блокування - головна проблема
- Внесли до свого коду виправлення, щоб зменшити проблеми від блокувань BEAM.
- Пропатчили BEAM.
- Розподіл завдань таким чином, що завдання не переміщуються між процесорами зайвий раз.
- Кожного разу, коли повідомлення отримано від порту, оновлюється блокування, єдине для всіх планувальників, тобто всі процесори звертаються до одного блокування.
- Оптимізували використання таймерів. Прибрали таймери на вбудованих функціях (BIF, build-in-function).
- Додали таку функцію запису до файлу, яка приймає вже відкритий порт, для того, щоб знизити конкуренцію за порти введення-виведення.
- Аллокатор mseg - єдина точка конкуренції для всіх аллокаторів. Зробили його окремим для кожного планувальника.
- При отриманні з'єднання виконується багато транзакцій з портами. Внесли зміни, щоб зменшити кількість дорогих операцій взаємодії з портами.
- Коли черга повідомлень стає великою, збирання сміття може дестабілізувати систему. Тож збирання сміття призупиняється доти, доки черга не скоротитися.
- Уникання деяких дорогих речей.
- Бекпортували TSE таймер з FreeBSD 9 на 8. Цей таймер читати дешевше. Можна швидше отримати час, і це не так дорого, як звернення до апаратного чіпа.
- Збільшили кількість сокетів та файлів.
- Pmcstat показала, що багато часу йшло на пошук PCB в мережевому стеку. Збільшили розмір хеш-таблиці, щоб зробити пошук швидше.
- Патчі BEAM
- Вже згадані діагностичні патчі. Пропатчили планувальник, щоб отримати інформацію про споживання ресурсів, статистику черг повідомлень, кількість "сплячих" "процесів, кількість відправлених повідомлень, лічильники повідомлень, і так далі. Може бути отримано і з Erlang, з допомогою procinfo, але при мільйоні з'єднань це дуже повільно.
- Збір статистики дуже ефективний, тому його можна запускати і в продакшені.
- Статистика збирається через три інтервали, що збільшуються: 1, 10 і 100 секунд. Дозволяє відстежувати проблеми з плином часу.
- Зробили підрахунок блокувань для більшого числа асинхронних потоків.
- Додали механізми для зневаджування лічильників блокувань.
- Налаштування
- Встановили межу пробудження планувальника нижче, тому що планувальник може піти в стан "" сну "і не прокинутися.
- Віддайте перевагу mseg, а не malloc.
- Збільшили розмір буферів FreeBSD, і дали їм можливість збільшуватися ще сильніше. Це змушує FreeBSD використовувати супер-сторінки. Скорочує замусорювання TLB і ув
- Erlang + BEAM + їхні патчі - чудове масштабування на SMP. Майже лінійне масштабування. Вражаюче. Можна запустити систему, що споживає 85% CPU і вона буде продовжувати працювати під реальними навантаженнями. Вона може працювати так хоч весь день.
