bazhenov.me

The Two Thread IDs of macOS: Measuring P/E Core Usage on Apple Silicon

Fri, 24 Apr 2026 00:00:00 +0000

Introduction Link to heading

I needed a straightforward way to check programmatically how much time a process spends on P-cores vs E-cores. There’s no high-level API for it, at least not that I know of – and yet this information matters whenever you care about consistent performance on Apple Silicon.

I ran into this while working on Tango.rs, a benchmarking framework. When comparing two algorithms, if one happens to run mostly on P-cores while the other gets pushed to E-cores, you’re not comparing algorithms anymore – you’re comparing hardware. I needed to check the proportion of time each process spends on P and E cores.

Activity Monitor Anatomy

Sun, 20 Jul 2025 00:00:00 +0000

Introduction Link to heading

Imagine you opened Activity Monitor to check how much memory your application consumes.

But wait, which number should you actually look at? Suppose there’s “Memory” showing 800 MB, and “Real Memory” showing 1 GB. What’s the difference?

Note

Activity Monitor doesn’t display those two readings by default. To show them, you need to right-click on a table header and select them.

This exact scenario happened to me more times than I’d like to admit. As someone who keeps Activity Monitor perpetually open, I found myself constantly puzzled by these two memory metrics. Coming from a Linux background where RSS (Resident Set Size) tells a straightforward story, macOS’s dual memory reporting felt like reading tea leaves.

Performance Roulette: The Luck of Code Alignment

Wed, 14 Feb 2024 00:00:00 +0000

Introduction Link to heading

Good weather is specific weather. Conclusion: there is no such thing as good weather.

Pilot’s proverb

TLDR: The very same machine code, placed at different addresses, can exhibit drastically different performance.

As software developers, we often assume that the performance of a specific piece of code is determined solely by the code itself and the hardware it runs on. This assumption gives us a sense of control when optimizing code for better performance. While this assumption holds true in most cases, this article aims to explore phenomena that challenge this notion of control. Additionally, I will provide a sandbox to demonstrate this phenomenon using the Rust programming language.

Paired benchmarking. How to measure performance

Wed, 31 May 2023 00:00:00 +0000

Introduction Link to heading

In this article, I discuss the challenges associated with testing algorithm performance, focusing primarily on microbenchmarks rather than overall application performance, although some principles apply to both. I provide a brief overview of efforts to address these challenges and highlight some limitations we’re encountering.

Subsequently, I introduce an alternative method of performance testing called paired benchmarking, which effectively tackles some of these challenges. While paired testing is a well-known statistical technique, as far as I am aware, it has not yet been implemented in any benchmarking tools.

Compress-a-Palooza: Unpacking 5 Billion Varints in only 4 Billion CPU Cycles

Sun, 21 May 2023 00:00:00 +0000

Introduction Link to heading

Varint is a widely recognized technique used for compressing integer streams. Essentially, it suggests that it can be more efficient to encode a number using a variable-length representation instead of a fixed-size binary representation. By removing leading zeros from the binary number, the overall representation size can be reduced. This technique works particularly well for encoding smaller numbers.

In this article, I provide a brief introduction and rationale for varint encoding. Additionally, I describe the Stream VByte format, which enables fully vectorized decoding through SSSE3 instructions. I also share my findings from implementing this algorithm in Rust, which includes both encoding and decoding primitives and the ability to read data from both RAM and disk.

Fast(er) binary search in Rust

Wed, 03 May 2023 00:00:00 +0000

Introducton Link to heading

Binary search is a very fast algorithm. Due to its exponential nature, it can process gigabytes of sorted data quickly. However, two problems make it somewhat challenging for modern CPUs:

predictability of instruction flow;
predictability of memory access.

At each step, binary search splits the dataset into two parts and jumps to one of those parts based on a midpoint value. It’s difficult for the CPU to predict which parts of the presumably large array will be accessed in the next iteration. As a result, binary search produces many cache misses, which stalls the CPU pipeline, resulting in poor instruction-per-clock performance.

How fast can you count to 16 in Rust?

Mon, 10 Apr 2023 00:00:00 +0000

Introduction Link to heading

Suppose we need to write a function that computes the next set of numbers in a range and stores them in a slice, as shown below:

let pl = RangePl::new(1..12);
let mut buffer = [0u64; 4];
pl.next_batch(0, &mut buffer); // returns 4, buffer[..] = [1, 2, 3, 4]
pl.next_batch(0, &mut buffer); // returns 4, buffer[..] = [5, 6, 7, 8]
pl.next_batch(10, &mut buffer); // returns 2, buffer[0..2] = [10, 11]
pl.next_batch(10, &mut buffer); // returns 0, buffer not updated

Key factors:

Why Clean Code was (and still is) important?

Tue, 28 Mar 2023 00:00:00 +0000

In recent years, criticism of the classic object-oriented analysis and design ideas has grown increasingly louder. One example of such criticism is Clean Code, Horrible Performance by Case Muratori.

Here’s a quote that explains the author’s idea:

It simply cannot be the case that we’re willing to give up a decade or more of hardware performance just to make programmers’ lives a little bit easier. Our job is to write programs that run well on the hardware that we are given. If these rules cause software to perform this poorly, they simply aren’t acceptable.

Java, futex, 2 gc

Thu, 19 Oct 2017 00:00:00 +0000

Недавно на работе произошла следующая ситуация, потребовавшая не совсем тривиальной диагностики. Есть Java-приложение, выполняющее пакетную обработку информации. Обработка выполняется последовательно в несколько стадий. Каждая стадия выполняется в нескольких потоках. Несмотря на высокую требовательность к процессорному времени, приложение не может полностью утилизировать ресурсы сервера. В чем же дело?

Довольно быстро появилась гипотеза, что дело в GC, который добавляет паузы в работу приложения и не позволяет польностью утилизировать CPU. Гипотеза согласовывалась с тем что сообщали нам jstat и JFR. Но чтобы понять как лучше оптимизировать приложение, было необходимо оценить степень влияния GC на потоки одной конкретной стадии, а не на все приложение в целом. Именно эта стадия была узким местом. Ни jstat ни JFR этого не умеют.

Объединение линейных счётчиков

Tue, 28 Jun 2016 00:00:00 +0000

Линейный счётчик — это очень простой алгоритм оценки мощности множества. Тем не менее, у него есть одна не очевидная и очень полезная особенность. Побитовая сумма (логическое ИЛИ) двух линейных счётчиков позволяет оценить мощность объединения двух множеств.

Например, у вас есть два множества $A$ и $B$, а также их линейные счётчики $A’$, $B’$. Тогда:

$$L_{A’ | B’} \approx |A \cup B|$$

где $L_x$ – функция оценки линейного счётчика.

Это свойство крайне полезно для оценки, например, количества уникальных посетителей того или иного ресурса за произвольный промежуток времени.

Как замедлить систему в три раза чтобы пользователь не заметил

Tue, 11 Aug 2015 00:00:00 +0000

Иногда по долгу службы приходится проводить деструктивные эксперименты. Делаем мы это лишь для того чтобы сделать нашу систему более стабильной и надёжной.

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

LXC для разработчика

Wed, 11 Feb 2015 00:00:00 +0000

Работая над более менее сложным проектом, приходится поддерживать окружение необходимое для корректного функционирования системы. Нередко это выливается в ситуацию, когда на машине установлено такое количество пакетов и зависимостей, что возникает масса проблем:

окружение становится тяжёло воспроизвести на другой машине (например, новому разработчику);
окружение становится хрупким. Обновляя зависимости для какой-нибудь вспомогательной утилиты, ломается основной проект;
окружение тяжело поддаётся изменениям. Хочется поэксперементировать с какой-нибудь библиотекой, но из за опасности накосячить с зависимостями, от этой затеи приходится отказаться.

На Java-платформе эти проблемы менее заметны за счёт развитых инструментов управления зависимостей, а также замкнутости платформы. В экосистеме Java не очень жалут C/C++ библиотеки. Все популярные драйвера и библиотеки написаны непосредственно на Java, поэтому не возникает проблем с управлением системными зависимостями. А для управления библиотеками в Java есть масса зрелых инструментов.

Top 10 фич Java 8 о которых не говорят

Sun, 20 Jul 2014 00:00:00 +0000

О новых фичах Java 8 было сказано уже довольно много. В основном обсуждают замыкания, Stream’ы, новое API для работы со временем, default-методы в интерфейсах, класс Optional и отсутствие Permanent Generation.

Но помимо жирных фич, в Java 8 сильно изменилась стандартная библиотека по перифирии. В частности, в уже существующие классы было добавлено много методов существенно упрощающих ежедневные задачи. Об этом мы сегодня и поговорим.

Итак, Top 10 самых не обсуждаемых фич Java 8. Поехали.

String.join() Link to heading

Неужто свершилось?! 2014 год на дворе, а в стандартной библиотеке Java появился метод объединяющий набор строк в одну с заданным разделителем.

Классификация методом максимальной энтропии

Tue, 23 Apr 2013 00:00:00 +0000

Наивный байесовский классификатор, о котором я уже писал, один из самых простых классификационных алгоритмов. В этой заметке я опишу более сложный алгоритм — метод максимальной энтропии, который, в ряде случаев, может оказаться существенно более точным. К своему удивлению, я не нашел в рунете более менее полного описания этого алгоритма классификации. Поэтому, считаю полезным поделиться этими знаниями.

Как и в предыдущем случае, описание разбито на две части: теорию и практику. В теоретической части описываются вопросы связанные с математической моделью классификатора. В практической части, содержится описание, как максимально быстро получить работающий классификатор для практических нужд на Java. Исходный код работающего примера доступен на github.

Размер линейного счетчика

Sun, 14 Apr 2013 00:00:00 +0000

Для использования линейного счетчика необходимо заранее знать приблизительное количество уникальных элементов в потоке. На основании этого количества, а также необходимого вам уровня точности, вычисляется длина битовой маски счетчика.

Допустим, вы хотите создать линейный счетчик для оценки количества элементов в потоке, с максимальным количеством уникальных элементов равным 10 миллионам. Какой длины должна быть битовая маска? Ответ на этот вопрос позволяет найти следующее неравенство:

$$m > \max\left(5, \frac{1}{(\epsilon t)^2}\right) \left(e^t - t - 1\right)$$

Архитектура поисковых систем

Tue, 08 Jan 2013 00:00:00 +0000

Так уж получилось, что последние несколько лет я занимаюсь вопросами, связанными с поиском. Один из проектов, завершенных в прошлом году, был связан с модифицированием архитектуры нашей поисковой системы. В итоге мы получили результаты, которыми, как я считаю, имеет смысл поделиться. So, here we go.

Функциональность поисковой системы Link to heading

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

Линейный счетчик

Wed, 12 Dec 2012 00:00:00 +0000

Допустим, вам необходимо рассчитать количество уникальных строк в файле. Причем, файл большой – миллионы или десятки миллионов строк. Типичный shell’овский однострочник который позволяет решить эту задачу выглядит следующим образом:

sort | uniq | wc -l

И все бы хорошо, но есть одна проблема. Имя ей sort.

Сортировка $O(n \log n)$ по времени и $O(n)$ по памяти, поэтому время её работы очень быстро перерастает все разумные пределы. Как вариант, можно хранить не сами строки, а их контрольные суммы. Это снизит как требования по памяти, так и асимптотическую оценку по времени до $O(n)$. Но хранение контрольных сумм подразумевает наличие коллизий, поэтому вы можете получить не точную оценку, а приблизительную. В случаях когда приблизительной оценки достаточно мы можем разменять точность алгоритма на его скорость и требования к памяти.

Feature selection в алгоритмах классификации

Mon, 10 Dec 2012 00:00:00 +0000

Существует один очень простой и эффективный способ улучшения алгоритмов классификации, который называется feature selection (выбор классификационных признаков). Этот метод позволяет при построении модели выбрать только самые показательные признаки (например, слова) и отсеять остальные.

Что такое показательные признаки? Если мы говорим о задаче классификации текстовых документов, то это слова которые несут информацию о классе к которому относится документ. Например, в контексте автомобильной тематики слово “Nissan”, скорее всего будет показательным признаком, а вот слово “новый” вряд ли. Использование для классификации не всех слов, а только показательных дает несколько преимуществ.

Толерантный автокомплит

Sat, 04 Aug 2012 00:00:00 +0000

Автокомплит вещь удобная. Он позволяет экономить время на наборе текста, когда множество значений поля закрыто. Хороший автокомплит отличается следующими качествами:

он должен быть быстрый. Если мы хотим экономить силы пользователя, то мы должны ему предложить вариант как можно быстрее;
он не должен предлагать к вводу варианты которые заведомо неверны;
он должен быть толерантен к пользовательскому вводу. В том числе прощать опечатки.

Вот о последнем качестве autocomplete алгоритмов я и хочу сегодня поговорить.

Оценка классификатора (точность, полнота, F-мера)

Sat, 21 Jul 2012 00:00:00 +0000

Продолжая тему реализации автоматической классификации необходимо обсудить следующий очень важный вопрос. Как оценивать качество алгоритма? Допустим, вы хотите внести изменения в алгоритм. Откуда вы знаете что эти изменения сделают алгоритм лучше? Конечно же надо проверять алгоритм на реальных данных.

Тестовая выборка Link to heading

Основой проверки является тестовая выборка в которой проставлено соответствие между документами и их классами. В зависимости от ваших конкретных условий получение подобной выборки может быть затруднено, так как зачастую ее составляют люди. Но иногда ее можно получить без большого объема ручной работы, если проявить изобретательность. Каких-то конеретных рецептов, к сожалению, не существует.

Наивный байесовский классификатор

Mon, 11 Jun 2012 00:00:00 +0000

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

Заметка разбита на две части: теоретическая, в которой описаны аспекты классификации, и практическая часть построения классификатора. Если вы хотите быстро создать прототип классификатора, то обратитесь к практической части заметки, там на приводится пример классификатора. Также на github доступны исходники примера. Если же вам интересны теоретические принципы работы классификации, то обратитесь к теоретической части заметки.

О задачах классификации

Tue, 05 Jun 2012 00:00:00 +0000

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

Классификатор – это алгоритм соотносящий некие входные данные с одним или несколькими классами. В отличие от алгоритмов кластеризации эти классы должны быть определены заранее.

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

Особенности функциональщины в Java

Sat, 12 May 2012 00:00:00 +0000

Некоторое время назад мне довелось участвовать в одном из подпроектов целью которого было извлечение упоминаний об автомобилях из произвольного текста с использованием экспертной информации. Это задачу в простонародье называют парсингом :). Так или иначе, этот класс задач имеет свою специфику связанную с относительно большим количеством различных операций над коллекциями. Связано это с необходимостью проверки различных гипотез относительно содержимого анализируемого текста. Оперирование над коллекциями это сильная сторона функциональных языков к которым Java конечно же не относится.

Гармоническое среднее

Sat, 05 May 2012 00:00:00 +0000

Сегодня я хочу обсудить следующую проблему. Как мониторить CPU usage на многопроцессорной машине? Конечно же мониторить метрики выдываемые mpstat. Эта программа выдает процент времени который процессор проводит в различных состояниях (user, system, iowait, idle и т.д.).

$ mpstat 1
Linux 2.6.32-200.13.1.el5uek (search-personal2.vfarm.loc)		05/05/2012 	_x86_64_	(16 CPU)

11:35:52 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
11:35:53 AM all 8.34 0.00 0.59 0.06 0.00 0.12 0.00 0.00 90.89
11:35:54 AM all 7.27 0.00 0.86 0.00 0.00 0.36 0.00 0.00 91.51
11:35:55 AM all 7.80 0.00 0.45 0.06 0.00 0.17 0.00 0.00 91.53
11:35:56 AM all 5.33 2.17 0.84 0.00 0.00 0.14 0.00 0.00 91.52
11:35:57 AM all 5.92 0.00 0.40 0.06 0.00 0.06 0.00 0.00 93.57
11:35:58 AM all 4.71 0.07 0.42 0.00 0.00 0.14 0.00 0.00 94.67

В ретроспективе это выглядит следующим образом:

Один на миллион

Mon, 16 Apr 2012 00:00:00 +0000

Вам наверное приходилось слышать что-то вроде: “Этого не может быть. Вероятность этого менее одной миллионной”. В бытовом понимании одна миллионная это некая несвершимая вероятность. Другими словами, этого просто не может произойти. Но насколько это вeрятное событие, если вы повторите эксперимент миллион раз? Конечно, вероятность наблюдать событие растет если вы повторяете эксперимент много раз подряд. Но все равно мы зачастую подсознательно пытаемся игнорировать такие события считая их невероятными.

Тем не менее, в современных Интернет-системах которые обрабатывают миллионы запросов в сутки не заметить в течение дня событие с вероятностью в одну миллионную довольно сложно. И вот почему. Вероятность что интересующее нас событие (с исходной вероятностью 1/n) не проявит себя ни в одном из n независимых экспериментов равно:

О высокой нагрузке

Sun, 26 Feb 2012 00:00:00 +0000

В последнее время все чаще говорят о высоконагруженных приложениях. Нельзя не заметить что это теперь очень популярная, можно даже сказать модная, область знаний. Сам же термин “высоконагруженная система” при этом не имеет в нашей отрасли четкого определения. В этой заметке я хочу привести свои рассуждения по этому вопросу. Я не ставлю перед собой цель дать исчерпывающее определение этого термина. Моя цель, предоставить читателю ключевую информацию о системах такого рода, которая определяет стиль мышления при работе с ними.

Deploy и прочие неприятности

Fri, 10 Jun 2011 00:00:00 +0000

В продолжение предыдущего поста хочу немного рассказать о том как у нас происходит deploy. В прошлый раз мы закончили на том что артефакт доставлен на production и готов к развертыванию. Начинается самое интересное, процесс деплоя.

Но для начала надо немного описать платформу на которую мы деплоим наши приложения. В качестве servlet-container’а мы используем Jetty. Есть два основных типа приложений, которые мы пишем и сопровождаем: web-приложения, которые имеют некий web-интерфейс (это может быть как UI, так и REST интерфейс), а также background сервисы, которые как правило работают асинхронно (мы активно используем ActiveMQ). И здесь нужно подметить первую особенность, мы используем Jetty для обоих типов приложений. Это может показатся странным, так как для background-сервисов мы получаем явный overhead связанный с запуском и работой servlet-container’а. Но этот overhead просто мизерный по сравнению с тем какие плюсы мы получаем. А именно:

Fair lock

Sun, 17 Apr 2011 00:00:00 +0000

Не так давно у нас на собеседовании был кандидат, который произвел довольно хорошее впечатление, поэтому было решено предложить ему более сложную задачу, которую обычно мы не спрашиваем. Вот ее немного видоизмененный вариант.

Переделайте следующий код оставив его многопоточным таким образом, чтобы лампочки зажигались и гасли строго по очереди и в любой момент времени должна быть включена только одна лампочка:

package me.bazhenov.bulb;

public class Main {

	public static void main(String[] args) {
		new Thread(new Bulb("first")).start();
		new Thread(new Bulb("seconds")).start();
	}
}

public class Bulb implements Runnable {

	private final String name;

	public Bulb(String name) {
		this.name = name;
	}

	public void run() {
		Thread self = currentThread();
		while(!self.isInterrupted()) {
			System.out.println(name + " bulb is on");
			try {
				sleep(300);
			} catch (InterruptedException e) {
				self.interrupt();
			}
			System.out.println(name + " bulb is off");
		}
	}
}

Кандидат предложил использовать ReentrantLock в FairSync режиме. В первом приближении эта идея может показаться рабочей. Передать общий лок в оба оъекта типа Bulb и синхронизироватся там на нем. Тем не менее, этот подход не работает. Если мы заглянем в документацию к классу, то увидим следующее описание:

Маленький Билд и его друзья

Sat, 09 Apr 2011 00:00:00 +0000

Помните фильм “Пятый элемент”? Там была сцена, когда Зорг опрокидывает стакан на пол и роботы тут же начинают уборку помещения. Всего лишь одно маленькое действие привело в жизнь десяток машин, которые сразу же начали подметать и мыть полы, а в конце еще и налили воды хозяину.

Что-то похожее происходит в коллективе с налаженным build процессом, когда разработчик коммитит изменения в систему контроля версий.

О пользе налаженного процесса билда известно много. Но “путь на production” не прост. После того как код написан и перед тем как он будет запущен на production’е было бы неплохо сделать следующие вещи:

Как я собирал NAS

Sun, 14 Nov 2010 00:00:00 +0000

Коллеги давно просили меня описать процесс сборки и настройки своего NAS-сервера. Этим постом я искупаю свою вину. К тому же тема действительно актуальная и, мне кажется, многим будет интересно с какими проблемами я столкнулся, какое железо и софт использовал.

NAS у меня исполняет несколько обязанностей:

файловое хранилище “жирного” контента (фильмы, etc);
сервер для Apple TimeMachine (бекапы);
качает и раздает торренты;
“самопальный” мониторинг сетевой активности с использованием rrdtool;
локальный git-репозиторий.

Мой опыт использования NAS начался с QNAP TS-109 PRO II.

HighLoad++ 2010 - впечатления

Sun, 31 Oct 2010 00:00:00 +0000

В этом году я побывал на HighLoad++. Event довольно интересный, поэтому я попытаюсь вкратце описать свои впечатления, а так же основные тенденции наблюдаемые на конференции.

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

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

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

Keep it simple, stupid

Mon, 30 Aug 2010 00:00:00 +0000

Простота. Краеугольный камень нашей профессии. Наверняка вам приходилось слышать от своих коллег: “это можно сделать гораздо проще”. Или вы говорили это вашим коллегам: “смотри, можно сделать так. Это ведь гораздо проще”, а в ответ получали взгляд полный непонимания, как бы говорящий вам: “и это ты считаешь проще?”.

В программной инженерии определенно произошла инфляция слова “простота”.

Простота – это расстояние Link to heading

Не существует общепринятого определения простоты. Тем не менее, если мы заглянем в словарь то увидим, что очень часто рядом со словом простота фигурируют такие понятия как: “предсказуемость”, “прямолинейность”, “ясность”, “очевидность”.

Lock vs. Lease

Tue, 10 Aug 2010 00:00:00 +0000

Представьте себе типичную задачу, есть поток событий и этот поток событий надо разделить между несколькими пользователями системы. Типичный пример: модерация. Скажем, есть три модератора, которые просматривают добавляемый пользователями контент (допустим рекламные кампании). Мы хотим “распилить” поток событий между модераторами, чтобы они не делали одну и ту же работу дважды.

В самом простом случае, мы можем использовать mq в любом его проявлении. Пользователи просто берут сообщение из головы и обрабатывают его. Эта схема хорошо работает, но к сожалению не всегда применима. Например, если пользователи имеют возможность указывать критерии событий которые хотят обрабатывать. Последнее требование очень часто в том или ином виде всплывает в подобных задачах, потому что люди (точно так же, как и процессоры) плохо переносят context switch. Например, если я настроился на модерацию авто тематики, то я фигурально выражаясь загрузил в кеш ключевые слова относящиеся к этой тематике и буду очень расстроен если мне подсунут объект с тематикой относящийся к сотовым телефонам.

About motivation

Sat, 05 Jun 2010 00:00:00 +0000

Does anybody know why we do what we do? Why do we wake up everyday and go to our workplaces? It seems that the most obvious reason is money. We need money to function in the society. We need some funds to make some plans, if you wish.

It turns out that not only money motivate people to do their job. OSS is the proof. Well, yes, we can make money from open source projects. And a lot of companies do this already, but it’s not the point. The point is that there is another force motivating people. Most good programmers like some of my colleagues and buddies work not because of money, but because they feel passion to write programs. Money is a required but not sufficient part of motivation.

ldt или нагрузочное тестирование по-простому

Fri, 16 Apr 2010 00:00:00 +0000

И снова про инструменты разработки. Часто бывает необходимо сравнить производительность/пропускную способность того или иного участка кода, а писать тестирующий код ой как не хочется. А ведь надо всего-то, запустить нужный метод N раз и померять время выполнения.

Вот сегодня у меня возник вопрос. Сколько процессору надо времени, чтобы проитерироваться по массиву с заданной длинной?

Недолго думая, пишем простой POJO класс описывающий тестовый случай.

package com.blogspot.dotsid.ldt;

public class ArrayIterationTest {

	private int size;
	private int[] data;

	public void setSize(int size) {
		this.size = size;
	}

	public void prepare() {
		data = new int[size];
	}

	public void doTest() {
		for ( int i : data );
	}
}

компилируем исходник и находясь в classpath’е выполняем:

Программисты и железо

Sat, 20 Mar 2010 00:00:00 +0000

Не так давно у нас на работе (Виктор, Игорь, Олег привет вам) состоялась дискуссия на тему: должны ли программисты знать как работает железо на котором выполняются их программы? И я еще раз убедился в том, что большинство программистов придерживаются мнения: “железо само по себе, а я сам по себе”. Точка зрения вполне ожидаемая и ничего принципиально неправильного в ней нет, но я хотел бы “копнуть глубже”.

Вообще, мне кажется вопрос “стоит ли программистам изучать железо” в чем-то похож на вопрос “стоит ли программистам изучать математику”, — ответ неоднозначен. Существует множество вопросов, ответы на которые могут повлиять на окончательное решение: в какой предметной области вы работаете, насколько эти конкретные знания ценны для вас и т.д. Это вопрос инвестиций и прибыли. В данном случае под инвестициями подразумевается в первую очередь ваше свободное время, а под прибылью — профессиональные навыки и знания, которые позволят вам более эффективно делать вашу работу. Тогда вопрос сводится к следующему: чем изучение железа может помочь нам программистам делать свою работу лучше?

Superlinear scalability

Mon, 15 Feb 2010 00:00:00 +0000

Как вы думаете во сколько раз может быть быстрее ваша программа, если вам дадут в два раза более “крутое” железо: в два раза более быстрый процессор, в два раза больше памяти и т.д. Интуитивный ответ — в два раза. Раньше я уже писал о том, что не все так безоблачно. Взвесив все аргументы вы можете сказать: “окей, максимум в два раза”. Но что если бы я вам сказал, что при увеличении вычислительной мощности в два раза вы можете получить ускорение больше чем в два раза?

Миграция ключей

Wed, 20 Jan 2010 00:00:00 +0000

Сегодня в разговоре с одним знакомым всплыл следующий вопрос. В случае, если для дистрибуции ключей по нодам кластера используется типичная схема остатка от деления на количество серверов, какая доля ключей осуществляют миграцию, если один из серверов выводится из схемы? Интуитивным ответом является: “почти все” или “большинство”. Тем не менее, если вы любите тренировать мозг, то вот вам небольшая задачка имеющая приложение в web-программировании.

Формально говоря: при заданном количестве серверов $ N $ и хеширующей функции $ ƒ(x) $ обладающей выходным множеством с мощностью $ P $ ($ \log(P) $ бит, для crc32 $ P = 2^{32} $, для md5 $ P = 2^{128} $) какое количество ключей осуществит миграцию в случае, если серверов станет $ N-1 $, а для дистрибуции ключей используется значение $ f(x) % N $.

Слежка за логами

Sun, 17 Jan 2010 00:00:00 +0000

Раньше я уже писал о том, что нам приходится разрабатывать дополнительный инструментарий для себя. Еще одна сфера которую над которой мы плодотворно поработали — это логгирование. Здесь я не буду говорить о пользе логгирования и о том как надо логгировать. В интернете полно информации по этим аспектам. Я хочу рассказать о том, как мы анализируем логи.

Дело в том, что в сутки у нас генерируется порядка 100 мегабайт логов. Часть из этой информации — это информация об ошибках (при средней длине сообщения в 5 килобайт нам достаточно 4 секунд чтобы набрать мегабайт информации), часть это аудиторская информация. Просматривать такой объем информации в виде текстового файла — это просто нереально, поэтому мы создали для себя инструмент позволяющий аггрегировать информацию со всех компонентов системы и производить поиск по ней.

KV-хранилища

Sat, 16 Jan 2010 00:00:00 +0000

В последнее время в web-программировании появился очередной тренд — Key-Value базы данных. Существует просто великое множество KV-решений, — одно лучше другого. Но так ли они важны и какая от них польза? Разрешите мне немного порассуждать о происхождении KV-хранилищ.

Нет дыма без огня Link to heading

Недовольство реляционными базами данных начало появляться давно. Оказалось что на некоторых use case’ах они не такие быстрые как хотелось бы. Они слишком сложные для того чтобы большинство программистов понимало как они работают, а следственно и то, как их использовать. Идея изоляции программиста от физических деталей хранения данных с треском провалилась. Если вы не знаете нюансов вашей РСУБД, то эффективно использовать ее на большом dataset’е или при высокой конкурентной нагрузке у вас не получится.

IoC контейнеры

Mon, 21 Dec 2009 00:00:00 +0000

Если вы пишете на объектно-ориентированном языке, то вы должны быть знакомы с “джентльменским набором” принципов, которые очень полезны при написании кода. К таким принципам относятся: single responsibility principle, open-closed principle, interface segregation principle и другие. Общий эффект их использования заключается в том, что количество сущностей (классов и интерфейсов) в системе стремительно растет. В этом есть как положительные, так и отрицательные стороны.

Один из положительных моментов заключается в том, что у каждой сущности появляется строго выделенная роль, для работы которой требуется меньше кода. Такую роль проще протестировать, ее поведение проще понять, а следственно и изменить.

Диагностика OutOfMemoryError подручными средствами

Sun, 20 Dec 2009 00:00:00 +0000

Один мой коллега является адептом философии “дефолтных настроек”. Эта философия пропагандирует следующий подход: не пытайтесь менять environment под свои нужды, — просто научитесь пользоваться стандартным environment’ом.

Несмотря на то что сам по себе этот подход довольно спорен, в нем есть свои плюсы. Умение решать задачи штатными средствами особенно выручает когда необходимо быстро продиагностировать какую-то проблему, а у вас под рукой нет настроенного environment’а. Например, вы временно работаете за другой машиной, или географически отдалены от вашего милого сердцу, прекрасно настроенного environment’а. Поэтому, я считаю, очень важно уметь диагностировать типовые проблемные ситуации пользуясь только штатными утилитами. Так что давайте посмотрим как мы можем диагностировать memory leak’и в java, когда у вас под рукой нет ничего кроме JDK.

Гарантия доставки сообщений и ее последствия

Sun, 06 Dec 2009 00:00:00 +0000

В прошлой заметке, я затронул тему порядка доставки сообщений MQ-системами. Отсутствие гарантий в отношении этого порядка вызвало некоторое возмущение со стороны читателей, поэтому я решил раскрыть эту тему более полно.

Почему же многие очереди сообщений не гарантирую порядок? И так ли он вообще важен — этот порядок доставки?

Почему многие системы очередей не гарантируют порядок доставки? Link to heading

Здесь потребуется договорится об обозначениях.

Note

Для любых двух событий A и B запись A→B означает, что событие A происходит перед событием B. Людям знакомым с Java Memory Model эта запись должна быть известна как отношение happens-before.

Давайте представим себе очередь сообщений, которая гарантирует вышеупомянутый порядок и двух подписчиков читающих сообщения из этой очереди.

Прикладное применение оптимистической блокировки

Wed, 04 Nov 2009 00:00:00 +0000

В прошлый раз я писал про оптимистическую блокировку. Сегодня я хочу описать одну разновидность прикладного применения оптимистической блокировки.

Это прикладное применение относится к области систем асинхронного обмена сообщений (таких как ActiveMQ, RabbitMQ, OpenMQ, memcacheQ и другие). Очереди сообщений — это очень полезная разновидность промежуточного хранилища данных. В очередь можно положить сообщение и можно из нее взять сообщение. MQ системы позволяют частично решить проблему именуемую “Producer—Consumer problem”. Кто-то ложит, а кто-то читает, — все просто. Вообще, подобную систему можно реализовать и поверх вашей любимой реляционной базы данных. Причина, почему существуют очереди сообщений как отдельный тип middleware, заключается в эффективности их реализации. Когда вы знаете, что все что может делать клиент — это писать в хвост и читать с головы, вы можете написать действительно эффективную реализацию с очень большой пропускной способностью. Предыдущее предложение метафорично. Я надеюсь, вы не будете пытаться написать свою mq-систему.

Оптимистическая блокировка

Fri, 23 Oct 2009 00:00:00 +0000

Shared state, как известно необходимо защищать. Иначе параллельные потоки могут его “поломать”. Это относится и к web-приложениям. Несмотря на отсутствие вменяемой поддержки параллелизма в большинстве web-ориентированных языков (PHP, Python, Ruby), concurrency в web-приложениях хватает. Запросы приходят на web-сервер параллельно, исполняются на разных процессорах параллельно и т.д. По этой причине следующий код некорректен:

$bulletin = $manager->findBulletinById($request->id);
$bulletin->setHits( $bulletin->getHits()+1 );
$manager->saveBulletin($bulletin);

Два параллельных потока могут одновременно загрузить объявление, одновременно инкрементировать счетчик, и записать объявление обратно. Это приведет к тому, что один инкремент потеряется. В общем случае, если N потоков выполняют данный код одновременно, может быть потеряно до N - 1 update’ов.

Interrupted Exception

Fri, 04 Sep 2009 00:00:00 +0000

Недавно еще раз встретился с некорректной обработкой InterruptedException в java. InterruptedException — это checked exception генерируемый многими методами стандартной библиотеки, которые блокируют поток исполнения. К таким относятся: interruptible версии lock’ов, метод Thread.sleep(), некоторые операции над блокирующими очередями, некоторые операции над каналами и другие.

По своей сути, InterruptedException сигнализирует о том, что поток просят завершить его работу. При этом вас не просят немедленно завершить свою работу. Вас просят корректно завершить работу. На это может понадобится некоторое время.

Pipelining

Sat, 01 Aug 2009 00:00:00 +0000

Существует одна очень старая и эффективная техника — конвейерная обработка данных (pipelining). Ее смысл заключается в том, что разные физические исполнители, которые могут работать не блокируя друг друга (хвала DMA), такие как: процессоры, жесткие диски, сетевые карты, — должны работать не блокируя друг друга. Это позволяет повысить их утилизацию, и, если правильно все организовать, не допустить перегрузки отдельно взятых исполнителей. Отличительной особенностью этой техники является то, что она используется в микропроцессорах с незапамятных времен, и сейчас является неотъемлемой частью любого суперскалярного процессора.

Возожности mysqlnd в PHP/5.3

Sat, 01 Aug 2009 00:00:00 +0000

Если вы не знаете, то с PHP/5.3 поставляется новый mysql драйвер — mysqlnd. У него есть несколько особенностей и воможностей, которые отличают его от libmysql.

Первое не очень интерестно. Теперь при fetch’e результата не происходит копирования из памяти libmysql в память, находящуюся под управлением zend engine. Фактически весь result set находится в памяти zend engine. Это значит что выборки превышающие по размеру memory limit теперь таки будут генерировать out of memory. Наверное, это представляет ценность для владельцев shared хостинга, но для тех у кого выделенный сервер это имеет мало пользы.

О проблемах растущего размера

Sat, 01 Aug 2009 00:00:00 +0000

Все таки интернет индустрия развивается. Теперь на каждом углу высоконагруженные проекты, миллионы пользователей, требования к high-availability, масштабиремости. Причем вот ведь странно. К масштабиремости всегда относятся как-то однобоко. Иногда ее путают с производительностью. А иногда не понимают что масштабируют.

Dan Pritchett, один из архитекторов eBay (теперь уже бывший), еще в 2006 году написал отличное эссе You scaled your what? на тему векторов масштабирования (scaling vectors)¹. Действительно, существует масса направлений которые требуют внимания при интенсивном росте проекта, а следственно и сложности решаемых в проекте проблем. А это значит, что употребляя слово “масштабируемость”, мы должны отдавать себе отчет в том, в каком контексте мы употребляем это слово.

Что если цепь рванет?

Sat, 01 Aug 2009 00:00:00 +0000

Сегодня со мной произошел форс-мажор. Я приехал на работу на велосипеде так что, когда рабочий день закончился, я сел на вел и сопровождаемый прохладным ветерком покатил в центр города. Далеко уехать не получилось. Буквально через 40-50 метров я услышал хруст и педаль под ногой резко провалилась. Оказалось, что я поломал крепление заднего переключателя.

Вообще, поломать крепление заднего переключателя еще надо умудрится. Переключатель не испытывает больших нагрузок (разве что в момент переключения), так как находится на прямом ходу цепи. На прямом ходу цепь практически расслаблена, — основную нагрузку она испытывает на обратном ходу проходя через заднюю звезду. При ближайшем рассмотрении оказалось, что всему виной цепь. Разорвавшись она застряла в транке переключателя (цепь проходит через ритейнер переключателя по змейке) как раз в тот момент когда я в очередной раз перенес вес тела на педаль.

Энди и Билл

Sun, 19 Jul 2009 00:00:00 +0000

Вчера моя девушка купила себе Sims 3. Ну вы знаете… Маленькие человечки, которые постоянно требуют спать и есть. Эдакие тамагочи, которым хватает вычислительной мощности чтобы обсчитывать нравятся ли им их соседи, босс и прическа того волосатого парня, который косится на них в течении всей вечеринки. Полторы тысячи за лицензионную копию. И на обороте бокса вы можете прочитать:

Системные требования CPU: (XP) процессор P4 с частотой 2.0 ГГц или аналогичный: (Vista) процессор с частотой 2.4 ГГц или аналогичный. RAM: (XP) 1 Гб оперативной памяти: (Vista) 1.5 Гб оперативной памяти.

Fail Fast

Wed, 15 Jul 2009 00:00:00 +0000

$data = file_get_contents($location);

Что не так с этим кодом? На первый взгяд все хорошо. Вряд ли он может нам чем-нибудь навредить.

Хорошо, предположим, что у вас есть 3 web frontend’а, каждый из которых может обслуживать 60 параллельных запросов (итого 180 конкурентных запросов). На минутку предположим, что вышеприведенный код — это единственный код, который выполняется при обработке запроса. Если location указывает на локальный ресурс (на локальной файловой системе), то вряд ли что-то может пойти не так. Latency чтения с локальной файловой системы достаточно низкий для того, чтобы не беспокоится о возможных проблемах (если файлы достаточно маленькие).

Perfomance vs. scalability

Sun, 28 Jun 2009 00:00:00 +0000

Иногда встречаюсь c непониманием того, что такое производительность, а что такое масштабируемость. Почему-то некоторые люди считают, что это одно и то же.

С производительностью все более менее понятно. Это мера скорости работы системы. Запрос поступает в систему и через некоторое время система генерирует ответ. Это время (которое иногда называют latency) и является мерой производительности системы. Для интернет-приложений время получения ответа клиентом может быть значительно больше, чем время генерации ответа на стороне сервера (потери в канале, необходимость загрузки дополнительных статических ресурсов и т.д). Обычно эти издержки не учитываются при оценке производительности, хотя надо признать, они могут очень сильно влиять на user experience работы с приложением.

Future Evolution of High-Performance Microprocessors

Sat, 27 Jun 2009 00:00:00 +0000

На просторах сети нашел довольно интерестное видео о тенденциях развития микропроцессоров. Norm Jouppi из Hewlett-Packard рассказывает о текущих проблемах и о том, что из себя будут представлять микропроцессоры лет эдак через 5-10.

Было много сказано, про power wall и про то, как растущее энергопотребление не дает наращивать частоты. При этом заметно упали темпы снижения базового напряжения, используемого микросхемами. Мне, как программисту, было интерестно в первую очередь другое, — каковы тенденции в развитии микропроцессоров.

Groovy Remote Shell

Thu, 23 Apr 2009 00:00:00 +0000

Я работаю в довольно интенсивно развивающемся проекте. Мы много эксперементируем с разными инструментами. Иногда приходится инструменты разрабатывать самим.

Последний инструментарий, который мне пришлось реализовать самому — это удаленный groovy shell. Если вы незнакомы с groovy, то скажу, что это динамический язык работающий на JVM.

Задачей было разработать инструментарий, который бы позволил удаленно дергать некий служебный функционал внутри приложения (запускать переиндексацию, менять настройки thread pool’ов, удалять или создавать обьекты в БД и т.д.). Сначала для этих целей мы использовали JMX. Оказалось слишком сложно и неудобно. Решили сделать удаленный shell, который бы позволял выполнять groovy код в адресном пространстве приложения, что называется, на лету. Что может быть проще, чем получить ссылку на фасад, загрузить пару обьектов и послать им пару сообщений, – прямой канал с приложением в обход всех web-интерфейсов.

Конец эры закона Мура

Tue, 13 Jan 2009 00:00:00 +0000

Начиная с 70-х годов прошлого века производители микропроцессоров осуществляли экспоненциальный рост производительности, описанный законом Мура. Но достигнув физических ограничений, связанных с резким скачком тока утечки транзисторов и, как следствие, рассеивания тепла, стало понятно — дальнейшее увеличение производительности процессоров существующими техниками невозможно. Еще в 2003 году Intel обещала предоставить 4 ГГц модель. И вроде бы годом позже Intel’овцы приблизились к реализации задуманного, — появился процессор с тактовой частотой 3.8 ГГц. Но 4 гигагерцовым “мечтам” так и не суждено было сбыться. А все современные модели процессоров работают на тактовой частоте до 3 ГГц. Индустрия, как мы все теперь знаем, пошла другим путем. Выходом стало увеличение количества процессоров (ядер).

16x16

Fri, 09 Jan 2009 00:00:00 +0000

Это скриншот с Windows 2008 R2 с запущенным на нем SQLServer.

Примечательна сама загрузка. Загрузить 256 ядер почти на полную одним приложением не так-то просто. У MySQL, например, проблемы начинаются уже с 8 ядрами¹. У нас в проекте мы это испытали на собственной шкуре.

Как заметил Doug Holland, для того чтобы наблюдать такие полотна графиков, надо иметь по меньшей мере 30" монитор². Task manager плохо масштабируется по колличеству ядер, если вам угодно :).

Enhanced null handling в Java

Fri, 09 Jan 2009 00:00:00 +0000

Как показало голосование по вопросу java 7 language changes¹, null-handling в java - это самый большой “pain in the ass” из всех, через которые Java заставляет проходить программистов. С другой стороны то-же голосование на devoxxx по вопросу самого популярного языка под JVM, показало, что это Groovy.

Видимо, все те, кто привыкли к оператору Элвиса и safe-navigate в groovy, пришли на devoxxx и устроили флеш моб. Вобщем приветствуйте. Proposal² определяет 2 новых оператора в языке: null-safe и null-default. Работает так же как и в groovy. Просто и понятно.

Terracotta vs. Memcache

Fri, 09 Jan 2009 00:00:00 +0000

В последнее время начали сравнивать terracotta и memcache. Мне это сравнение кажется некорректным. Бытует мнение что terracotta — это distributed cache¹. Это все равно что называть автомобиль “четырехколесным мопедом”, только потому, что он может ездить и у него четыре колеса.

Terracotta часто определяют как Network Attached Memory. И это правда, но не вся. Технически никто не мешает вам использовать terracotta как distributed (или, как его еще иногда называют, clustered) cache. Но тут возникает проблема с HA. В кластере Terracotta всегда есть координатор, который управляет потоком данных. По словам Ari Zilka² (одного из основателей Terracota Inc.), именно по этой причине terracotta очень хорошо масштабируется, так как благодаря наличию координатора нет необходимости использовать multicast передачу данных. Однако, наличие координатора означает single point of failure. При использовании memcache SPOF нету, но вам необходимо самому распределять данные по нодам.

ANTLR и DSL

Wed, 18 Jun 2008 00:00:00 +0000

Задача. Есть биллинг, который аккумулирует данные по операциям. Нужно предоставить интерфейс (программный) для получения отчетов. Каждый отчет может быть параметризирован. Например, получить определенный отчет (скажем начисления за месяц) для какого-то конкретного клиента. Список отчетов будет изменятся, будут разрабатываться новые. Учитывая требования, пришел к выводу, что наилучший вариант предоставить клиенту декларативный язык для получения данных. Что-то вроде:

build DepositReport from '2008-01-01' to '2008-02-01'
	with userId = 15, depositGround = 'cash'

Решил написать грамматику для реализации парсера на ANTLR. К собственному удивлению, справился за пол часа, а результирующая грамматика занимала 35 строчек кода. На выходе я имел следующий интерфейс.

Чайник и сложность ПО

Tue, 17 Jun 2008 00:00:00 +0000

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

MySQL Queue

Thu, 12 Jun 2008 00:00:00 +0000

Случайно нашел интерестное программное решение. Q4M — иммитация сервера очереди сообщений посредством MySQL сервера (начиная с версии 5.1). Написано что fast, robust и flexible (интерестно, бывает что-нибудь одно?). Однако, дозволяются условные выборки из очереди, несмотря на то, что в limitations указано, - индексы при этом не используются.

Вообще, довольно трудно представить себе где бы могла мне пригодится такая очередь сообщений. Cуществует куча бесплатных специализированных решений, которые создавались специально для обработки очередей сообщений. Взять хотя бы ActiveMQ или JBossMQ. Поддержка транзакционности, оптимизирована для быстрой вставки (в принципе, как и любая другая MQ система), поддержка практически всех популярных скриптовых языков посредством STOMP, встроенный message router, поддержка репликации, поддержка forward on demand bridge и куча еще чего. Учитывая то, что MQ системы обычно применяются либо при интеграции приложений либо в целях масштабируемости приложений (что говорит о больших обьемах данных), непонятно зачем нужно решение подобное Q4M. Рано или поздно вы упретесь в пропускную способность sql-сервера по чтению, добавите slave серверов, а затем упретесь в ту же пропускную способность, но уже по записи. И тут уже никакая репликация не спасет.

Mon, 01 Jan 0001 00:00:00 +0000

About Link to heading

Hello 👋

My name is Denis. I’ve been a Software Developer for over 20 years, working with a wide range of technologies for commercial applications and personal projects. It’s tough to list them all, but here are a few of my favorites:

Information retrieval applications, particularly Apache Lucene, are my area of expertise. I designed, built, and for many years assisted in operating large scale e-commerce search systems;
Monitoring, troubleshooting, and application introspection in cloud environments;
Rust language, application performance analysis and making software faster on modern hardware;
Java language and JVM in general;
Linux as an application platform.

Last 5 years I’ve been playing the role of a technical leader in a development team helping adopt and use the right technologies for the job.

Mon, 01 Jan 0001 00:00:00 +0000

Projects Link to heading

Here is the list of open source project I’ve developed through the years…

bazhenov.me

The Two Thread IDs of macOS: Measuring P/E Core Usage on Apple Silicon

Introduction Link to heading

Activity Monitor Anatomy

Introduction Link to heading

Performance Roulette: The Luck of Code Alignment

Introduction Link to heading

Paired benchmarking. How to measure performance

Introduction Link to heading

Compress-a-Palooza: Unpacking 5 Billion Varints in only 4 Billion CPU Cycles

Introduction Link to heading

Fast(er) binary search in Rust

Introducton Link to heading

How fast can you count to 16 in Rust?

Introduction Link to heading

Why Clean Code was (and still is) important?

Java, futex, 2 gc

Объединение линейных счётчиков

Как замедлить систему в три раза чтобы пользователь не заметил

LXC для разработчика

Top 10 фич Java 8 о которых не говорят

String.join() Link to heading

Классификация методом максимальной энтропии

Размер линейного счетчика

Архитектура поисковых систем

Функциональность поисковой системы Link to heading

Линейный счетчик

Feature selection в алгоритмах классификации

Толерантный автокомплит

Оценка классификатора (точность, полнота, F-мера)

Тестовая выборка Link to heading

Наивный байесовский классификатор

О задачах классификации

Особенности функциональщины в Java

Гармоническое среднее

Один на миллион

О высокой нагрузке

Deploy и прочие неприятности

Fair lock

Маленький Билд и его друзья

Как я собирал NAS

HighLoad++ 2010 - впечатления

Keep it simple, stupid

Простота – это расстояние Link to heading

Lock vs. Lease

About motivation

ldt или нагрузочное тестирование по-простому

Программисты и железо

Superlinear scalability

Миграция ключей

Слежка за логами

KV-хранилища

Нет дыма без огня Link to heading

IoC контейнеры

Диагностика OutOfMemoryError подручными средствами

Гарантия доставки сообщений и ее последствия

Почему многие системы очередей не гарантируют порядок доставки? Link to heading

Прикладное применение оптимистической блокировки

Оптимистическая блокировка

Interrupted Exception

Pipelining

Возожности mysqlnd в PHP/5.3

О проблемах растущего размера

Что если цепь рванет?

Энди и Билл

Fail Fast

Perfomance vs. scalability

Future Evolution of High-Performance Microprocessors

Groovy Remote Shell

Конец эры закона Мура

16x16

Enhanced null handling в Java

Terracotta vs. Memcache

ANTLR и DSL

Чайник и сложность ПО

MySQL Queue

About Link to heading

Projects Link to heading

Tango Link to heading

safe-cargo Link to heading