Дотепність і відвага: як ми багато разів помилялися, створюючи iFunny

Це — не стаття, це — фейлбук. Те, що ви прочитаєте під катом, — витримка наших безглуздих техно-промахів за всі 5 років роботи над флагманським продуктом — iFunny. Можливо, наша фейловая історія допоможе вам уникнути помилок, а можливо, викличе сміх. Що теж добре. Смішити людей — покликання FunCorp вже 13 років.

Читати далі →

Історія розробки TWIME — нового високошвидкісного інтерфейсу Московської Біржі

В цьому хабі ми розповімо вам про свій унікальний досвід розробки високошвидкісного інтерфейсу TWIME для Московської біржі, пояснимо, чому нам так важлива низька latency (час відгуку) і як її скоротити. Сподіваємося, у висновку вам стане трохи зрозуміліше, чому Московська біржа більш технологічна в деяких областях, ніж, приміром, такі гіганти High Load як Nginx, VK або MailRu.

Читати далі →

HighLoad++2016: як це було



Привіт, Хабр! Поспішаємо повідомити тобі, що трансляції з Хайлоада вже викладені на Youtube-каналі Хабра. Нагадуємо що це плід спеціального проекту Хабра і Хайлоад. 7 листопада, текстова трансляція, кілька сотень постів (доступна тут). 8 листопада, текстова трансляція – тут. Напевно не у всіх була можливість спостерігати за цим онлайн, тому поспішаємо повідомити, що тепер доступна запис конференції, яку ви можете подивитися в будь-який зручний для вас час на YouTube каналі Хабра. Сторінку спеціального проекту переглянули більше 25 000 разів, текстову трансляцію прочитали більше 9 000 чоловік, а відео на ютубі подивилися на даний момент 10 000 чоловік. Ну що ж, сподіваємося, що це допомогло читачам Хабра трохи зануритися в нове або гаряче улюблене, розширити свій кругозір і знайти для себе щось корисне в самій гущі висококонцентрованих доповідей про високих навантаженнях.

Читати далі →

Текстова трансляція HighLoad++ 2016. День перший

Сьогодні в цьому пості весь день буде вестися текстова трансляція конференції HighLoad++ 2016, що проходить в Сколково 7 і 8 листопада. HighLoad++ — це понад 200 експертів найвищого класу з доповідями про високонавантажених сервісах, проблеми роботи з ними і питаннях адміністрування. Більше 15 залів, щільний графік, чесний і корисний досвід спікерів — HighLoad++ вміє збирати круті теми, задавати тон дискусії і все на одному диханні.
Якщо ви хочете дивитися відео з головного залу і включення з мобільної студії Хабрахабра, то вам на сторінку спецпроекту. Якщо почитати онлайн і поообщаться в кооментариях — під кат.



Читати далі →

«Збираємося запустити своє хмара»: Однокласники про Java і не тільки



Як в Однокласниках використання sun.misc.Unsafe поєднується з підвищеними вимогами до надійності? Чому там допрацьовували систему моніторингу Cacti? Робота в ОК перетинається з науковою діяльністю? Якщо соцмережа називається «Однокласники», то складається весь її Java-код з одного класу?

Відповіді на ці та інші питання — у нашому пості. Напередодні Joker, де відразу троє співробітників ОК будуть спікерами, а ще один бере участь у програмному комітеті, ми розпитали всіх чотирьох — і не тільки їх. На наші питання відповіли:

  • Олег Анастасьєв, провідний розробник (учасник програмного комітету Joker 2016)
  • Андрій Паньгин, провідний розробник (спікер Joker 2016)
  • Віталій Худобахшов, провідний аналітик (спікер Joker 2016)
  • Дмитро Бугайченко, інженер-аналітик (спікер Joker 2016)
  • Андрій Губа, заступник технічного директора
  • Христина Штейнберга, керівник відділу персоналу

Читати далі →

Web-Оповіщення навантажених проектах

В сучасному WE-конструюванні дуже часто виникають задачі, коли необхідно оповіщати користувача про яку-небудь подію: прийшло нове повідомлення, змінився курс на біржі або статус замовлення, сконвертировался відео-контент або подскачила температура хворої бабусі.

Є кілька варіантів вирішення такого класу задач. Найбільш оптимальне і поширене рішення – це підписка на події. Як це реалізується в навантажених проектах?

Читати далі →

JSON-сериализатор на швидких шаблонів



В чому проблема текстових форматів обміну даними? Вони повільні. І не просто повільні, а жахливо повільні. Так, вони надлишкові, порівняно з бінарними протоколами і, по ідеї, текстовий сериализатор повинен бути повільніше приблизно на стільки ж, на скільки він надмірний. Але на практиці виходить, що текстові сериализаторы інший раз на порядки поступаються бінарним аналогам.

Я не буду розмірковувати про переваги JSON перед бінарними форматами — у кожного формату є своя область застосування, в якій він хороший. Але найчастіше ми змушені відмовлятися від чогось зручного в користь не дуже комфортного внаслідок катастрофічної неефективності першого. Розробники відмовляються від JSON, навіть якщо він прекрасно підходить для розв'язання задачі, тільки з-за того, що він виявляється вузьким місцем у системі. Звичайно ж, винен не JSON сам по собі, а реалізації відповідних бібліотек.

У цій статті я розповім не тільки про проблеми парсерів текстових форматів взагалі і JSON зокрема, але і про нашу бібліотеку, яку ми використовуємо вже багато років в самих високонавантажених проектах. Вона настільки нас влаштовує і в плані швидкодії, і в плані зручності використання, що часом відмовляємося від бінарного формату там, де б він більше підійшов. Звичайно ж, я маю на увазі якісь прикордонні умови, без претензій на всі випадки життя.


Читати далі →

Сучасна операційна система: що треба знати розробнику

Олександр Крижановський (NatSys Lab.
Олександр Крижанівський

Нас буде цікавити операційна система – її нутрощі, що там відбувається… Хочеться поділитися ідеями, над якими ми зараз працюємо, і звідси невеликий вступ – я розповім про те, з чого складається сучасний Linux, як його можна потюнить?

На мою думку, сучасна ОС – це погана штука.


Справа в тому, що на картинці зображені графіки сайту Netmap (це штуковина, яка дозволяє вам дуже швидко захоплювати і відправляти пакети мережевого адаптера), тобто ця картинка показує, що на одному ядрі з різною тактовою частотою до 3 ГГц Netmap дозволяє 10 Гбіт – 14 млн. пакетів в секунду. відпрацьовувати вже на 500 МГц. Синенька лінія – це pktgen – найшвидше, що, взагалі, є в ядрі linux'а. Це така штуковина – генератор графіків, який бере один пакет і відправляє його в адаптер багато разів, тобто ніяких копіювань, ніякого створення нових пакетів, тобто, взагалі, нічого – тільки передавання одного і того ж пакету в адаптер. І ось воно настільки сильно просідає порівняно з Netmap (те, що робиться в user-space показано рожевої лінією), і воно взагалі десь там внизу знаходиться. Відповідно, люди, які працюють з дуже швидкими мережевими додатками, переїжджають на Netmap, Pdpdk, PF_RING – таких технологій море зараз.
Читати далі →

Tarantool: як заощадити мільйон доларів на базі даних на высоконагруженном проекті

Аникин Денис ( danikin, Mail.Ru
Денис Анікін

Сьогодні я розповім, як заощадити на базах даних величезні гроші, наприклад, мільйон доларів, як це зробили ми. Для початку питання: чому частіше використовують саме бази даних, а не файлики?

Бази даних – це сховище, більш структуроване, ніж файл, і має ряд деяких функцій, яких у файлу немає.



Там можна робити запити, там є транзакції, індексування, таблиці, стійкі, більш-менш надійні сховища. Насправді, бази даних – це більш зручно, ніж файли.

Читати далі →

Що особливого в СУБД для даних в оперативній пам'яті

Костянтин Осипов ( kostja
Костянтин Осипов

Як народилася ідея доповіді? Я не дуже люблю виступати і розповідати про фічі, особливо про майбутні фічі. З'ясовується, що і люди не особливо люблять це слухати. Вони люблять слухати про те, як все влаштовано. Це доповідь про те, як все влаштовано або має бути, з моєї точки зору, влаштовано у сучасній СУБД.

Я спробую зробити так, щоб ми змогли з макрорівня спуститися на мікрорівень, тобто яким чином, спочатку відкидаючи макропроблеми, ми можемо створити собі простір для вибору на середньому рівні і мікрорівні.



На макрорівні – це те, як повинна бути влаштована сучасна СУБД. Чому у нас сьогодні є можливість створювати нові бази даних, чому не можна взяти поточну і задовольнитися її продуктивністю, подтюнить або написати для неї патч? Просто взяти і написати патч, який би прискорив її, якщо вона повільна? З якогось простору рішень ми вибираємо?
Читати далі →