Посты с тегом ‘производительность’

На нашем видео-пректе при отдаче видео с серверов возникает вопрос производительност дисковой подсистемы. Очевидно, что гигабитные сетевые интерфейсы обладают большей производительностью, чем, скажем, RAID0 из 2х дисков. И если бы видео-ролики обладали одинаковой популярностью, то диски являлись бы узким местом при отдаче контента.
Однако же, нам повезло и всегда есть небольшой набор роликов, которые делают 80% трафика, и длинный хвост с редкой посещаемостью. Этот небольшой набор оседает в кеше файловой системы и отдается практически без дисковой активности.
Например, если у нас на сервере лежит 100 гигабайт роликов, а памяти на сервере 24 гигабайта, то мы можен нарисовать такой график. По горизонтали у нас будут «файлы», отсортированные по популярности, по вертикали — трафик, порождаемый этими файлами. Суммарный трафик — площадь поверхности под графиком.

filesystemcache

С другой стороны, всегда стоит вопрос, сколько памяти на сервер лучше поставить и как померять hit/miss ratio. В этом посте мы рассмотрим, как это можно сделать.
(далее…)

Mike Haertel, автор GNU grep, написал в рассылку FreeBSD отличное письмо по поводу производительности grep-а.

Суть в том, что grep использует модифицированный алгоритм Boyer-Moore для поиска подстроки и ему не приходится проверять каждый байт.

Там же предлагалась идея использовать mmap для увеличения производительности, чтобы ядру не читать read-ом каждый байт, а передать контроль за этим в юзерспейс — самому grep-у.

Если вдуматься, смысл этой оптимизации не очень большой. Все равно с диска считывается минимум 4 килобайта (размер физического сектора HDD), и вряд-ли Boyer-Moore сделает прыжок больше, чем на 4K.

Вторая причина в том, что каждая считанная страница памяти будет генерировать page fault. Это может быть даже дороже, чем системный вызов read().

Собственно, именно так и посчитали разработчики grep-а.

Еще одна отличная оптимизация — grep не разбивает входящий файл на строки заранее. Он сначала находит вхождение, а потом ищет начало и конец строки. Если grep-у указать ключ -n (включить счетчик строк), то ему будет необходимо из распознавать заранее, что сильно уменьшит его производительность.

$ time grep groovy tmpfs/words > /dev/null

real 0m0.927s
user 0m0.600s
sys 0m0.311s
$ time grep -n groovy tmpfs/words > /dev/null

real 0m1.924s
user 0m1.606s
sys 0m0.307s
$

Недавно меня попросили сравнить провести тесты шаблонизатора для используемого нами фреймворка Grails. Зачем такие тесты нужны и что они, собственно, скажут о производительности приложения — не знаю. Однако это весело и народ такие тесты очень любит.

Собственно, у Grails никакого шаблонизатора нет, а есть язык Groovy, который можно использовать внутри серверных страничек (GSP — Groovy Server Pages). Итак, хотим измерить производительность языка Groovy. В качестве базовой точки отсчета используется язык PHP.

(далее…)

Продолжение первой части.

Мы мигрировали нашу БД на новые накопители и настало время посмотреть на картинки с производительностью.

(далее…)

На одном из наших проектов нам перестало хватать производительности дисковой подсистемы на сервере БД. Одним из решений было начать использовать дисковый массив с большим количеством шпинделей, но звучали аргументы против. Во-первых, дисковый массив + HBA (external SATA у сервера нет) стоит как 2 новых сервера. Во-вторых, дисковый массив занимает как минимум 2U. В-третьих, дисковый массив предоставит терабайты, которые, строго говоря, не нужны (размер БД + временные таблицы укладываются в 40 гигабайт максимум).

Поэтому мы подумали, почему бы не попробовать SSD. И взяли 4 Intel X25-E по 32Gb каждый. Объеденили их в 2 массива RAID0 (из-за специфики проекта мы готовы мириться с потерей данных при выходе из строя одного из устройств) и посмотрели что получилось.

Получилось следующее:

(далее…)