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

less установлен у всех, все привыкли с ним работать, знают о базовых вещах, как поиск вперед-назад, фильтрация по &, переход в конец(G) файла, переход в начало(g) и так далее.

А так же, все уже смирились с тем, что в любой момент, при добавлении фильтра less может подвиснуть на неопределенный срок, выводить по строчке в 5 секунд и так далее. В конечном счете, особенно при считывании логов с stdin — приходится быть аккуратным. Фильтр может сработать, а может и не сработать.

Собственно, в тот момент, что и мне выпала участь в течении нескольких дней пройтись через этак пару сотен лог-файлов — стало очевидно — мир нужно менять к лучшему…

Под катом демо (gif 2.2mb) и немного истории.

goader — консольный бенчмарк с простой конфигурацией и поддержкой различных бэкендов для тестирования. Название происходит от go и loader, а также имеет свое значение на английском, "подгонять копьем, палкой"

На данный момент можно тестировать (аргумент -requests-engine):

• http (GET запросы либо GET+PUT)
• disk
• s3 (С авторизацией по ACCESS/SECRET keys, endpoint необходим, но это дает возможность проверять private s3, signature ver4 на данный момент не поддерживается, но планирую)
• null и sleep для тестирования самого бенчмарка

Уклон сделан на запись и считывание файлов, не страничек

Пример использования

goader -rps=300 -wps=150 -min-body-size=1 -max-body-size=128k --max-requests=1000 -requests-engine=disk -url=tmp/NN/RRRRR

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

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

Новые инстансы дешевле старых и вводят понятие CPU Credit-ов.

CPU Credit — это внутренняя накапливающаяся монета, которая равна 1 минуте при 100% нагрузке.
Кредит накапливается со скоростью зависимой от типа сервера. Так же, от типа сервера зависит до куда просядет его максимальная CPU нагрузка при отсутствии кредитов — baseline. Минимальный максимум. Минимальный, так как при отсутствии кредитов максимальная нагрузка проседает не мгновенно, а постепенно в течении 15 минут, чтобы была возможность компенсировать нехватку ресурсов в случае необходимости.
Хранится кредит до 24 часов.

Тип инстанса	Кредитов в час	Baseline	Цена за час	Цена за месяц
t2.micro	6	10%	$0.013	$9.50
t2.small	12	20%	$0.026	$19
t2.medium	24	40%	$0.052	$38

В своем предыдущем посте я писал о том зачем и почему нужно было сделать pybabel-hbs, экстрактор строк gettext из шаблонов handlebars.

Чуть позже появилась необходимость извлекать так же из json.
Так появился pybabel-json.
pip install pybabel-json либо на github

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

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

— Babel. Набор утилит для локализации приложений.
— Grunt. Менеджер задач(task-ов),
— coffeescript. В представлении не нуждается, весь клиенстский код написан на coffee, и из него тоже нужно извлекать строки.
— handlebars — темплейты
— json — хранилища строк
— Jed. gettext клиент для js
— po2json. Утилита для перевода .po файлов в .json формат поддерживаемый Jed-ом

Думаю многим известен такой пакет как Babel, либо PyBabel.
Отличный пакет для локализации, который базируются на gettext, как и все остальное ( по крайней мере мне известное) в современном мире.

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

Должен заранее оговориться, что у меня не было никакого ограничения в выборе технологий.
У нас в конечном счете для билда статики используется полный набор — ruby(compass), node(coffee,grunt,requirejs), python(бэкенд и основа всего и вся), шелл скрипты, в общем ограничения нет никакого.