Измерение производительности Play Framework 2.0

Измерение производительности Play Framework 2.0

Я уже рассказывал о программной платформе Typesafe Stack 2.0. В том посте шла речь об одном из компонентов платформы — фрэймворке Akka 2.0, реализующем модель акторов на JVM. Сегодня я хочу написать о возможностях другой составляющей Typesafe Stack — фрэймворке Play 2.0. Хотя о функциональности данного компонента уже рассказывали здесь и здесь, тема производительности решений под управлением Play 2.0 по-моему осталась не раскрытой.

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

Тестируемое приложение

Прежде чем перейти к описанию тестируемого приложения, следует прояснить основные архитектурные особенности фрэймворка Play 2.0. HTTP-сервер Play основан на высокопроизводительной библиотеке Netty. Это не только позволяет использовать его «из коробки», исключая настройку какого-либо сервлет-контейнера, но и обеспечивает возможность асинхронной обработки клиентских запросов. В классическом синхронном варианте обработки, любой поступающий запрос, для ответа на который требуется выполнить некоторое вычисление, будет занимать поток операционной системы все время пока осуществляется данное вычисление. Play же позволяет на время вычисления вернуть поток в пул сервера и снова занять поток для ответа, когда вычисление будет готово. Технически это означает возможность одновременного подключения большего количества клиентов, чем в синхронном варианте.

Тестируемое приложение будет выполнять три основных функции:

• создавать comet-соединение с браузером клиента (/wait?cid={connection_id})
• принимать поступающее значение и рассылать его в консоли браузеров всех имеющихся comet-соединений (/put?v={value})
• закрывать все существующие comet-соединения (/closeall)

При разработке использовалась библиотека Akka 2.0. Приложение разработано на языке Scala, так как с моей точки зрения он более удобен для работы с Akka, по-сравнению с Java. Ниже я приведу основные части кода, чтобы только показать простоту работы с подключениями в Play 2.0 и не уходить от сути данного поста. Весь код можно получить из git-репозитория, ссылка на который приведена в конце публикации.

Актор comet-подлючения

...
  lazy val channel: PushEnumerator[String] = ch
...
  def receive = {    
    case Message(message) =>
    {
      channel.push(message)
    }
...
    case Close =>
    {
      channel.push("closed")
      channel.close()
      self ! Quit
    }
  }
...

Переменная channel — это источник данных для comet-подключения (тип — Enumerator), который, как будет показано ниже передается комет-подлючению через адаптер Comet (тип — Enumeratee). Подробнее о работе с источниками-преобразователями-потребителями потоков данных в Play можно прочитать здесь. Передача данных в comet-сокет осуществляется вызовом функции channel.push(message). Закрытие comet-сокета — вызовом channel.close().

Основной актор приложения

В функции актора ConnectionSupervisor входят: создание comet-соединения, отправка сообщения в созданные соединения, закрытие всех соединений.

...  
  var connectionActors = Seq.empty[ActorRef]
  def receive = {
    case SetConnect(connectionId) =>
    {
      lazy val channel: PushEnumerator[String] = Enumerator.imperative(
        onComplete = self ! Disconnect(connectionId)
      )
      val connectionActor = context.actorOf(Props(new ConnectionActor(channel)), connectionId)
      connectionActors = connectionActors :+ connectionActor
      sender ! channel
    }
    case BroadcastMessage(message) =>
    {
      connectionActors.foreach(_ ! Message(message))
    }
    case CloseAll =>
    {
      connectionActors.foreach(_ ! Close)
    }
  }
...

Ссылки на созданные акторы хранятся в последовательности connectionActors (тип — Seq[ActorRef]). При установлении соединения создается канал channel, который передается в новый актор ConnectionActor. Актор добавляется к списку акторов. Как рассылаются сообщения и закрываются соединения должно быть понятно из кода.

Актор хранения текущего значения

Предполагается, что в StorageActor поступает значение, производятся какие-либо действия и значение рассылается во все comet-соединения, а также возвращается клиенту. Таким образом имитируется поведение некоторого реального приложения, когда клиент делает запрос и ожидает на него ответ.

...
  var value = ""
  def receive = {
    case Put(v) => 
    {
      value = v
      connectSupervisor ! BroadcastMessage(value)
      sender ! value
    }
  }
...

Контроллер Application

...
object Application extends Controller {
...
  def waitFor(connectionId: String) = Action {
    implicit val timeout = Timeout(1.second)
    AsyncResult {
      (ActorsConfig.connectSupervisor ? (SetConnect(connectionId)) ).mapTo[Enumerator[String]].asPromise.map { chunks =>
        Ok.stream(chunks &> Comet( callback = "console.log"))
      }
    }
  }  
  def broadcastMessage(message: String) = Action {
    ActorsConfig.connectSupervisor ! BroadcastMessage(message)
    Ok
  }  
  def putValueAsync(value: String) = Action {
    implicit val timeout = Timeout(1.second)
    Async {
      (ActorsConfig.storageActor ? Put(value)).mapTo[String].asPromise.map { value =>
        Ok(value)
      }
    }
  }
  def closeAll = Action {
    ActorsConfig.connectSupervisor ! CloseAll
    Ok
  }
}

На методы данного контроллера отображаются адреса из поступающих HTTP-запросов (описание маршрутов находится в файле conf/routes). Наибольший интерес здесь представляет метод waitFor, который создает comet-сокет и связывает с ним канал типа Enumerator[String]. Канал в сокет отправляется актором в ответ на сообщение SetConnect. Каждое поступающее в канал сообщение передается в браузер клиента как параметр функции, указанной в объекте Comet( callback = "console.log"). В данном случае — это функция console.log.

Со стороны клиента comet-соединение создается с помощью скрытого элемента , например:

<iframe src='/wait?cid=1' style='display:none'/>

Учитывая довольно низкую мощность аппаратной части системы, под управлением которой было запущено тестируемое приложение, полагаю, что полученные результаты более чем интересные. Play Framework 2.0 оказался не только удобным инструментом разработки, но и сервером приложений, удовлетворяющим современным требованиям производительности онлайн систем.

Автор: tolyasik