Cat`s shepherd » Программизмы

Разгоняем ThreadLocal

Квиринг Алексей — Thu, 17 Jun 2010 17:36:22 +0000

Всем серьезным и не очень программистам из мира Java известен данные класс. Он привязывать объект к конкретному потоку. Достаточно часто используется в многопоточных приложениях, наш сервер также не стал исключением. А раз у нас самый многопоточный из многопоточных серверов – то используется данный класс достаточно часто – на одну входящую команду с клиента раз 20 точно. Сегодня я провел тестирование скорости работы данного класса, оказалось всего лишь 7 000 операций get() за одну миллисекунду. Пришлось ускорять и вот каким методом – у каждого Thread есть метод long getId() который возвращает уникальный идентификатор потока, но также не следует забывать, что если поток умирает – то данный идентификатор может реиспользоваться.

А далее вот что получается:
Было: ThreadLocal threadLocal; String value = threadLocal.get();
Стало: String[] threadLocal = new String[10000]; String value = threadLocal[(int)Thread.currentThread().getId];
Ускорение в три раза, но тут есть костыль – массив должен быть большой, чтобы гарантированно хватило. Для решения этой проблемы у меня есть реализация разреженных массивов, но об этом потом.

P.S. Попутно выяснил что реализация очереди ArrayDeque работает в три раза медленней чем пара из массива и счетчика, для её эмуляции.

NoSQL Redis – первые шаги

Квиринг Алексей — Wed, 16 Jun 2010 17:12:57 +0000

Решение отказаться от PostgreSQL и перейти на Redis было принято еще полтора месяца назад. Но только сегодня практически полностью завершена интеграция базы в платформу. Изначально для доступа к базе данных я использовал JRedis. Чуток позже выяснилось, что он поддерживается не все команды, в том числе он не поддерживал работу с hash. А это для нас критично. Пришлось править код и добавлять поддержку данных команд, поддержку то я сделал, но разбираясь в чужом коде понял, что это совершенно не Realtime решение. А сборке мусора автор даже не подумал, куча объектов, структур и классов. Сам проект – 200 классов самого разнообразного назначения. И поэтому пришлось самому писать API для доступа. В итоге – 5 классов и 10 JUNIT тестов, поддержка всех существующий команд. Работа с сокетами на уровне ByteBuffer и NIO. Пул коннектов, шардинг и многое другое. И все это работает в OSGi. Исходный код дать не могу, но кому интересно – пишите, по крайней мере на вопросы отвечу. По скорости процентов на 30% быстрее чем JRedis, по памяти раза в три и главное не создает объектов в процессе работы.

Redis меня в последнее время радует, недавно сделали поддержку виртуальной памяти, в итоге можно хранить достаточно большое количество данных, нам вполне хватит. А поддержка сортированный SET вообще сказка, именно на нем мы будем делать TOP рейтинг игроков (пример можно посмотреть на http://tankionline.com).

Scrum vs Ваша компания

Квиринг Алексей — Wed, 25 Nov 2009 05:15:32 +0000

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

Проблемы классического подхода:

узкоспециализированные специалисты (это происходит постепенно, когда PM оптимизирует раздачу задач, так чтоб росла локальная продуктивность: люди делают схожие задачи тем, которые они делали раньше);
это в свою очередь приводит к мышлению в рабочей группе типа “я свое сделал…”, это не команда, со всеми вытекающими;
у PM-a растет число задач по микроменедженту своей группы, так как он является единственным человеком, который видит “всю картину”;
подключение новых людей становится задачей PM-a, текущие работники не заинтересованы в обучении новеньких – что им с того?
когда в итоге новых людей подключают, у PM-а работы только прибавляется;
в итоге PM (а это особенные люди) занимается задачами ниже своего уровня компетенции

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

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

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

А вот полная статья:
http://www.developers.org.ua/archives/krivitsky/2008/07/17/scrum-for-developers/

Альтернативная навигация по исходникам в Eclipse

Квиринг Алексей — Sun, 26 Apr 2009 07:10:33 +0000

Каталоги и файлы являются в настоящий момент самым распространным способом навигации по коду. Но на мой взгляд не очень удобным. Например, у меня открыто 10 проектов и я хочу быстро перейти к классам, которые используют рейтинг игрока. Навигация по каталогам такого удобства мне не предоставляет, прийдется вспоминать в каких именно классах я использоваль рейтинг, потом открывать пару каталогов и сам класс. И повторить эту операцию N раз.
В ходе дебатов родилась такая идея – к стандартной навигации добавить навигацию по тегам. Программист в комментах для класса описывает теги – @tags rating user battle. А плагин для Eclipse отображает данные теги в виде облака и позволяет быстро открывать нужные классы и файлы.
Вот такая идея. Реализовать бы

XSLT, SVN и Пермские WEB Студии

Квиринг Алексей — Mon, 20 Apr 2009 16:10:41 +0000

В далеком 2003 году делал я сайт Западно-Уральского Сбербанка. И врядли я бы его вспомнил сегодня если бы не два обстоятельства:
1) в качестве языка шаблонов использовался XSLT
2) сегодня я набрел на презентацию – http://veged.ru/works/WhyXSLT_CS.pdf

В не менее далеком 2002 году у нас было много спорос с одним из товарищей – стоит ли применять эту технологию или нет. Основной аргумент против с его стороны – сложность и неудобность. И в этом он прав – как ни крути XSLT это практически ФУНКЦИОНАЛЬНЫЙ язык программирования. Кто же его будет то изучать. Вот так и сидит у нас в Пермь куча PHP программистов, которые пишут хорошии сайты небольшой величины и крупные сайты с отвратной архитектурой и большим количеством ошибок. Не хотят учится и не будут.

А такие слова как SVN, JIRA, SCRUM для них как индийский язык. Вот поэтому ни одна из веб фирм в перми ничего не достигла. Пока нет ни одного положительного примера в разработки сложных веб сайтов.