Программирование

Напоролся сегодня на такой Exception. Его генерирует Grape. Причину не знаю, но знаю решение:

:::: WARNINGS
        problem while listing resources in file:C:/Users/R/.m2/repository/org/codehaus/groovy/
modules/http-builder/http-builder/ with localm2:

          java.lang.NullPointerException null

        problem while listing resources in file:C:/Users/R/.m2/repository/org/codehaus/groovy/
modules/http-builder/http-builder/ with localm2:

          java.lang.NullPointerException null

        problem while listing resources in file:C:/Users/R/.m2/repository/org/codehaus/groovy/
groovy/ with localm2:

          java.lang.NullPointerException null

        problem while listing resources in file:C:/Users/R/.m2/repository/org/codehaus/groovy/
groovy/ with localm2:

          java.lang.NullPointerException null

                [NOT FOUND  ] commons-collections#commons-collections;3.2.1!commons-collections.jar (2ms)

        ==== localm2: tried

          file:C:\Users\R/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
:: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS

Правильное решение скрыто во тьме веков, а быстрое решение - скачать файл, например, отсюда и положить его к вам в локальный репозитарий m2, в моём случае путь к файлу ~/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar. Мне этот файл был нужен для поддержки HttpBuilder в Groovy. Такие дела.

Есть очень много людей, убеждённых в том, что Windows не лучшая среда для веб-разработки. Да, возможно, отчасти это на самом деле так. Чем ближе ко всевозможным скриптовым языкам вроде Python, тем это сильнее так. Или можно взять node.js, выпущенный для Windows, но без менеджера дополнений.

Однако, слава высшим силам, мы используем в разработке Java и JVM языки. Их поддержка в Windows, как и в любой другой системе, хороша. Юзать можно хоть через консоль, хоть воспользоваться средствами, встроенными в IDEA.

Но сейчас я про другое, я про NoSQL сервер Redis.

Проект Atmosphere (используется для т.н. Comet соединений) выпустил наконец-то новый релиз. Точнее, даже 2 — вслед за 0.8, через сутки вышла версия 0.8.1. У нас успешно использовалась версия 0.7.2, вскорости рассчитываю использовать уже 0.8.1 версию в нашем проекте.

Релиз выглядит многообещающим: универсальный код для поддержки WebSocket выглядит читаемым (жаль, пока ещё не работает полноценно с GlassFish 3.1.1); в плагине для JQuery сделали поддержку CORS; поддержку запуска приложений в нескольких вкладках одного браузера.

Поддержка socket.io будет только в 0.9 версии, судя по всему. Либо в 0.8.х в виде плагина (пока непонятно, какова будет схема выпуска плагинов для Atmosphere, лично я проголосовал за независимый выпуск плагинов уже начиная с 0.8 версии).

Для Grails есть замечательный плагин console. Один минус у него: при структуре проекта чуть сложнее Hello World, когда в проекте десятки или сотни пакейджей, например — надо обязательно осуществлять импорт доменных классов вручную. А это — лишнее время, причём тратится оно не разово, а раз в рестарт сервера.

К сожалению, добраться до GroovyShell, в котором выполняется введённый пользователем код — кажется, нереально, Хотя силён и могуч Groovy, но вроде бы там даже кложеров не используется, которые было бы можно заменить. Тогда я пошёл другим путём, через фильтры.

Давным-давно ещё натыкался на штуковину под названием Quercus в J2EE-сервере Resin. Сейчас решил попытаться на своём сервере сэкономить немножко памяти посредством её использования. Сервер – недорогой двухъядерный AMD x64 Athlon 5600+, ОС Debian, 4GB RAM. Дополнительно: ядро 2.6.32-5-amd64, java version "1.6.0_26", PHP 5.3.8-1~dotdeb.2 with Suhosin-Patch, nginx: nginx version: nginx/1.0.9. Congratulations! Quercus™ Pro 4.0.7 is compiling PHP pages. Have fun! MySQL держит 150 одновременных подключений, nginx – имеет 2 воркера по 1000 подключений каждый, а вот пул php-fpm – имеет всего лишь 50 воркеров (50 воркеров по 64 Мб съедают почти всю память системы, а ведь некоторым задачам в wordpress уже надо по 128 Мб, именно из-за этого я и посмотрел в сторону Quercus). jetty был запущен с ограничением в 1 Гбайт под heap.

Мистическим образом для тестов ко мне попала standalone PRO версия Quercus (умеет компилировать PHP в сервлеты, за счёт чего работает быстрее). Версия эта была для 2х 8-ядерных процессоров, так что ресурсы сервера были задействованы по максимуму.

Были взяты два пустых Wordpress’а, во избежание возможного кэширования запросы к ним выглядели как ?a=b. Первый работал на php-fpm из dotdeb, второй работал на ProQuercusServlet. Прогревание — было, несколько раз порефрешил страницу из браузера (в браузере без ?a=b).

Работой по HTTP занимались с одной стороны — nginx, с другой стороны — jetty 7.4.2.

Итак, что мы видим:

Производительность Grails

Рано или поздно, любой программист слышит, что производительность инструмента, который он использует или инструмента, который он сделал — невысока. Будь то какой-нибудь синтетический бенчмарк, или сложные распределённые вычисления. Будь то работа с базой данных или с файлами.

Все хотят максимальной производительности! Всегда! Немедленно!

Как известно, часто максимальная производительность достигается путём жертв. Пожертвовать удобством, настраиваемостью, масштабируемостью, поддерживаемостью — то и другое, и третье и четвёртое — можно принести на алтарь производительности.

Но насколько серьёзны потери? Насколько их можно избежать? Как можно выжать из проекта побольше производительности? Давайте посмотрим на примере Grails.

Несмотря на то, что сейчас такие вещи, как последнее обновление записи, модно делать с помощью ORM, — в том случае, если вы можете быть платформенно-зависимы (всю жизнь с MySQL, или готовы переписать триггеры в случае перехода на другую БД вроде PostgreSQL), возможно, есть смысл воспользоваться триггерами.

MySQL позволяет сделать один автообновляемый таймстамп, например таким образом:

Иной раз казалось бы, вполне себе невинный и очень даже простой метод count() может стать серьёзной проблемой для производительности.

Предположим, что у нас есть два доменных класса: Игрок и Предмет. Имеем реляцию: Игрок hasMany Предмет. Классы будут называться: Player, Item. Поле с коллекцией предметов — items. Коллекция предметов нужна нечасто, поэтому для её подгрузки используется lazy-loading.

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

player.items.count()

Но гораздо быстрее будет работать код

Item.countByPlayer(player)

Попробуем разобраться, что же происходит?

Я уже писал, что считаю Groovy одним из самых перспективных языков программирования и даже приводил тому примеры.

Но этот разговор не имеет ни начала ни конца, и интересные примеры всегда могут придумываться «по ходу дела». Так, например, подвернулся такой код на Groovy:

string = 'hippopotamus'
assert string - 'hippo' - 'mus' + 'to' == 'potato'

Считаю, что это просто гениально :) Когда-то давным-давно, когда я ещё учился в школе и ничего толком программировать не умел, я ушёл с Basic к Pascal из-за более качественной работы со строками. Ах, если бы в то время существовали такие прикольные штуки, как Groovy или хотя бы Java!

Моё первое знакомство с Groovy было не вполне удачным. Так, обнаружилась достаточно невысокая производительность, тормоза при использовании статической типизации, и отсутствие масштабных плюсов по сравнению с Java. В тот момент единственное, что я был готов отдать на откуп Groovy, была отладочная консоль сервера. Например, у нас в сервере используется JavaScript от Mozilla (Rhino), ещё с тех пор, когда его не было в JRE.

Однако позднее пришлось «допиливать» проект, написанный на Groovy с использованием фреймворка Grails, и тогда в этот язык я влюбился.

Я могу часами (ну ладно, не часами — минутами) придумывать, как сделать рефакторинг Java кода, чтобы он стал более читаемым, более производительным, более грамотно организованным. Но на Groovy можно зайти ещё дальше. В сети есть интересный пример, как программу на Java (конечно же, являющуюся и валидной программой на Groovy), можно переписать.

Кстати, самое первое и очень важное преимущество Groovy заключается в том, что программа на Java — это программа на Groovy. Вовсе необязательно переписывать код! То, что все библиотеки Java, написанные за последние ≈15 лет, можно использовать и в Groovy — и так понятно. Но этот факт тоже не стоит недооценивать. Ну да ладно, вернёмся к рефакторингу: