image

Баркемп (англ. BarCamp) — міжнародна мережа конференцій, яка створюється її учасниками. Конференції відкриті для всіх, проходять у форматі доповідей, тренінгів, презентацій, обговорень. Весь матеріал надається самими учасниками. © — Wiki

Подібні заходи в Magento відбуваються на регулярній основі. І в подальшому також будуть висвітлюватися тут.
Вашій увазі представляються відео доповідей з березневого івенту.

Більше під хабракатом

Читати далі →

До Java-конференції JPoint 2017 залишилося п'ять тижнів, 75% доповідей вже затверджені, решта 25% будуть обрані з наявних заявок до середини березня. У цьому пості я розповім вам про те, що у нас вийшло.



Якщо теми всіх доповідей розділити за тематиками, то вийде наступне:
  • Продуктивність Java, як на рівні JVM, так і в роботі з фреймворками;
  • Препарування JVM і публічна демонстрація кривавих кишочков;
  • Побудова розподілених систем, які працюють;
  • Проблеми паралелізму і багатопоточності у великих проектах;
  • Контейнеризація і оркестрация Java-додатків і сервісів.


Плюсом до основним блокам будуть доповіді на більш специфічні теми: Kotlin, trueOOP на Java від Єгора, патерни і, звичайно, трохи паззлеров!

Під катом я розповім про тих доповідях, які вже затверджені на JPoint 2017. Щоб все це не виглядало кашею, я спробував розбити доповіді по темах.

Читати далі →

Продуктивність старту JavaScript



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

Читати далі →

У пошуках перформансу: моніторинг продуктивності JVM під Linux за допомогою BPF

Фахівець з низькорівневої оптимізації додатків, Саша Гольдштейн, в рамках своєї доповіді на JPoint трохи відхилиться від звичної тематики .NET і розповість про інструментарій, що допомагає боротися за продуктивність Java додатків під Linux. Що це за інструмент, кому він потрібен і навіщо, ми вирішили дізнатися заздалегідь і взяли у Саші інтерв'ю.

JUG.Ru Group: Розкажіть, будь ласка, пару слів про себе і своїй роботі?

Саша Гольдштейн: Мене звати Саша Гольдштейн, останні 10 років я працюю в ізраїльській консалтингової компанії Sela в якості CTO.
Моя робота сфокусована на питаннях оптимізації продуктивності, діагностики на продакшн, моніторингу та всіляких основних завданнях.
Моя типова робоча тиждень наповнений самими різними завданнями: я викладаю, виправляю помилки або проблеми продуктивності для клієнтів, а також працюю над внутрішніми проектами. Також я входжу в програмний комітет пари конференцій: нашій власній SDP (Тель-Авів, Ізраїль), а також DotNext (Москва і Санкт-Петербург, Росія), що на подив займає досить багато часу.

«Продуктивність більшості додатків визначається не залізом або середовищем виконання» – Sasha Goldshtein про моніторинг продуктивності Java під Linux

Читати далі →

33 способу прискорити ваш фронтенд в 2017 році

enter image description here
Ви вже використовуєте прогресивну завантаження? А як щодо технологій Tree Shaking і розбиття коду в React і Angular? Ви налаштували стиснення Brotli або Zopfli, OCSP stapling і HPACK-стиснення? А як у вас справи з оптимізацією ресурсів та клієнтської частини, з вкладеністю CSS? Не кажучи вже про IPv6, HTTP/2 і сервіс-воркерах.
Читати далі →

Створення кастомних Go-профілів з допомогою pprof. Запам'ятовуємо стеки


Кадр із серіалу «Коломбо»

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

Читати далі →

Порівняння Lock-free алгоритмів — CAS і FAA на прикладі JDK 7 і 8

Багато ядер не буває
Атомарні операції (atomics), наприклад, Compare-and-Swap (CAS) або Fetch-and-Add (FAA) широко поширені в паралельному програмуванні.

Мульти — або багатоядерні архітектури встановлені однаково як в продуктах настільних і серверних комп'ютерів, так і у великих центрах обробки даних і суперкомп'ютерах. Приклади конструкцій включають Intel Xeon Phi з 61 ядрами на чіпі, який встановлений в Tianhe-2, або AMD Bulldozer з 32 ядрами на сайті, розгорнутих в Cray XE6. Крім того, кількість ядер на кристалі неухильно зростає і процесорів з сотнями ядер, за прогнозами, будуть виготовлені в осяжному майбутньому. Спільною рисою всіх цих архітектур є зростаюча складність підсистем пам'яті, що характеризується кількома рівнями кеш-пам'яті з різними політиками включення, різними протоколами когерентності кеш-пам'яті, а також різними мережевими топологіями на чіпі, що з'єднують ядра і кеш-пам'ять.
Практично всі такі архітектури забезпечують атомарні операції, які мають численні застосування в паралельному коді. Багато з них (наприклад, Test-and-Set) можуть бути використані для реалізації блокувань та інших механізмів синхронізації. Інші, наприклад, Fetch-and-Add Compare-and-Swap дозволяють будувати різні lock-free і wait-free алгоритми і структури даних, які мають більш міцні гарантії прогресу, ніж блокування на основі коду. Незважаючи на їх важливість і повсюдне вживання, виконання атомарних операцій повністю не проаналізовано досі. Наприклад, на загальну думку, Compare-and-Swap йде повільніше, ніж Fetch-and-Add. Тим не менш, це всього лише показує, що семантика Compare-and-Swap вводить поняття «wasted work», в результаті – більш низька продуктивність деякого коду.
Читати далі →

Оптимізуємо redux сховище для більш продуктивних змін

Цей пост є продовженням поста про оптимізацію продуктивності списку React додатку.

Увага. В цьому пості приклади підготовлені спеціально для Redux додатків. Але сам підхід можливо застосувати і з іншими бібліотеками. Так само нижченаведений рада працює у react-redux версії 5. Я не зміг досягти бажаного результату у версії 4. Глибоко розбиратися в причинах я не став.

І так, стандартний спосіб зберігати деяку множину елементів в додатку — це зберігати їх в масиві:

const state = {
targets: [{id: 'target1', radius: 10}, {id: 'target2', radius: 2}]
};

Читати далі →

12 млрд реквестов в місяць за 120$ на java

Коли Ви запускаєте свій продукт — Ви зовсім не знаєте, що станеться після запуску. Ви можете так і залишитися абсолютно нікому не потрібним проектом, можете отримати невеликий струмочок клієнтів або відразу ціле цунамі користувачів, якщо про Вас напишуть провідні ЗМІ. Не знали і ми.

Цей пост про архітектуру нашої системи, її еволюційного розвитку протягом вже майже 3-х років і компромісах між швидкістю розробки, продуктивністю, вартістю і простотою.

Спрощено завдання виглядала так — потрібно з'єднати мікроконтролер з мобільним додатком через інтернет. Приклад — натискаємо кнопку в додатку запалюється світлодіод на мікроконтролері. Тушкуємо світлодіод на мікроконтролері і кнопка в додатку відповідно змінює статус.

Так як ми стартували проект на кикстартере, перед запуском сервера в продакшені у нас вже була досить велика база перших користувачів — 5000 осіб. Напевно багато з Вас чули про відомий хабра ефект, який поклав в минулому багато веб ресурси. Ми, звичайно ж, не хотіли повторювати цю долю. Тому це відбилося на підборі технічного стека і архітектурі програми.

Відразу після запуску вся наша архітектура виглядала так:



Це була 1 виртуалка від Digital Ocean за 80$ в міс (4 CPU, 8 GB RAM, 80 GB SSD). Взяли з запасом. Так як «а раптом лоад піде?». Тоді ми дійсно думали, що ось, запустити і тисячі користувачів ринут на нас. Як виявилося — залучити і заманити користувачів та ще завдання і навантаження на сервер — останнє, про що варто думати. З технологій на той момент була лише Java 8 і Netty з нашим власним бінарним протоколом ssl/сокети tcp (так так, без БД, spring, hibernate, tomcat, websphere та інших принад кривавого ентерпрайза).

Всі користувальницькі дані зберігалися просто в пам'яті і періодично скидалися файли:

try (BufferedWriter writer = Files.newBufferedWriter(fileTo, UTF_8)) {
writer.write(user.toJson());
}


Читати далі →

Як я зробив віддзеркалення віртуальних машин для Free ESXi

У своїй домашній лабораторії я використовую безкоштовну віртуалізацію від VMware – це дешево і надійно. Спочатку був один сервер, потім у нього почав додавати локальні датасторы, потім зібрав другий сервер… Стандартною проблемою при цьому був переїзд віртуальної машини. Роблячи ці операції вручну, я натрапив на один спосіб, який дозволяв переключити працюючу віртуальну машину на копії флэтов зовсім в іншому місці. Спосіб дуже простий: досить створити снапшот віртуальної машини, скопіювати флэты в нове місце, а потім в дельті перебити посилання на батьківський диск. Гіпервізор не тримає файли метаданих диска відкритими, тому при видаленні снапшота відбувається зливання з новим диском, а старий можна спокійно видаляти. Цей спосіб прекрасно працює без всякого VDDK, який недоступний на безкоштовних гипервизорах і яким користується, наприклад, Veeam в схожій ситуації.
Я без праці автоматизував цю процедуру на python, застосувавши ще кілька трюків, які, при наявності запитів, зможу розкрити в наступних статтях. Трохи пізніше знайшовся добрий чоловік з моїх колишніх колег по цеху, який погодився написати гуй, останній, правда, реалізований на Unity, але для отриманого безкоштовного солюшена, названого нами Extrasphere, це було зовсім не погано. Чим не іграшка для адміна?
Читати далі →