Архитектура

Давным-давно ещё натыкался на штуковину под названием 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.

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

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

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

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

player.items.count()

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

Item.countByPlayer(player)

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

Сначала создадим проект в Мейвене: mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=ru.bytexgames.test -DartifactId=server

Редактируем pom.xml. Нам нужно добавить наркотическую зависимость проекта от Hibernate, для чего мы идём на http://mvnrepository.com/ и находим там параметры для зависимости hibernate:

<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>3.6.4.Final</version>
</dependency>

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

Фреймворки рассматриваются с разных позиций, а именно:

• Легкость создания нового проекта, чтения и поиска документации
• Продуманность объектной модели, возможность расширения
• Потребление памяти
• Скорость
• Роутинг
• Удобство настройки и отладки

Тесты производились на неком “Hello world”-проекте, типичном для MVC фрейморков. Проект включает в себя 1 контроллер, 1 модель, 1 представление, 1 роут. Модель загружается из базы средствами ORM. Поскольку во всех фреймворках скорость выполнения тестового проекта высока, для оценки использовались результаты apache benchmark (ab) на loopback-интерфейсе (127.0.0.1).

Для тестов использовался VDS (1 Гб памяти, бёрст до 1.5 Гб). Процессор: по 666 Мгц от каждого из 4х ядер “старого” Xeon X3350.

Настройки всех фреймворков “по умолчанию”. Для KO3 включен caching (это не кэширование запросов, это кэширование путей для автозагрузки классов. Ближайший аналог, наверное, prod режим в Symfony2). Для Symfony2 включен prod режим, отключен дебаг.

Пост писался 5 июля 2010, но так и не увидел свет в день своего рождения. Публикую спустя месяц.

Сегодня я узнал, что я – необразованный ретроград – изобрел велосипед. Точнее, пародию на велосипед. Как известно, я программирую на Java и в данное время мы работаем над новой игрой, konklav.ru. Собственно, мы решили избавиться от архитектурных недостатков сервера Берсерка, и несмотря на то, что в новом движке используется множество старого кода – он довольно сильно переработан.

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

Итак, очередная статья из цикла "Хороший, качественный код". На этот раз мне бы хотелось поговорить об оформлении условного оператора if. Этот оператор присутствует почти в каждой программе, и им можно пользоваться по-разному. Как и раньше, не буду претендовать на то, что мои слова - истина в последней инстанции, и предоставлю несколько возможностей выбора.

Начнем с форматирования исходников:

Очень часто, и в книгах, и в Интернет, и (возможно) от начальства, можно слышать про необходимость комментариев. Давайте посмотрим, насколько написание комментариев является необходимым.

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

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

Я уже вскользь писал на эту тему ранее, в статье "Как не надо писать код". Но в том случае упоминалось лишь о том, что мне не нравится, а не о том, как все должно быть на самом деле.

Я не собираюсь писать, скажем, про паттерны, про них и без меня написано многое. Мне приходится (и я этому рад) работать с самым разным кодом - отличным и ужасным, разных авторов, на разных языках программирования. В связи с этим я вкратце изложу, какой стиль программирования я считаю правильным и почему. Не настаивая на том, что моя точка зрения - мудрая, правильная и единственно верная (© Ильф и Петров).

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