Наши партнеры

UnixForum

Библиотека сайта rus-linux.net

От SocialCalc к EtherCalc

Глава 2 из книги "Производительность приложений с открытым исходным кодом".

Оригинал: From SocialCalc to EtherCalc
Автор: Audrey Tang
Перевод: А.Панин

SocialCalc на стороне сервера

Ключевой технологией, применяемой в нашей работе, является технология jsdom, предоставляющая завершенную реализацию объектной модели документа W3C, которая позволяет фреймворку Node.js загружать переданные клиентом библиотеки на языке JavaScript в рамках симулируемого окружения браузера.

При использовании jsdom достаточно просто создать любое количество электронных таблиц SocialCalc на стороне сервера, причем каждая такая таблица будет занимать около 30 КБ оперативной памяти и работать в собственном изолированном окружении: 
require! <[ vm jsdom ]>
create-spreadsheet = ->
  document = jsdom.jsdom \<html><body/></html>
  sandbox  = vm.createContext window: document.createWindow! <<< {
    setTimeout, clearTimeout, alert: console.log
  }
  vm.runInContext """
    #packed-SocialCalc-js-code
    window.ss = new SocialCalc.SpreadsheetControl
  """ sandbox

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

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

В апреле 2012 года после чтения доклада о EtherCalc на конференции OSDC.tw я получила приглашение от компании Trend Micro для участия в собрании разработчиков с целью адаптации EtherCalc к работе в составе программируемой подсистемы визуализации системы для мониторинга веб-трафика в реальном времени.

Для данного варианта эксплуатации мы создали API REST, предназначенный для доступа к отдельным ячейкам с использованием запросов GET/PUT, а также непосредственной передачи команд электронной таблице с использованием запросов POST. В ходе собрания разработчиков новый обработчик REST-запросов принимал сотни запросов в секунду, обновляя графики и представленное формулами содержимое ячеек в браузере без каких-либо признаков замедления обработки команд или утечек памяти.

Однако, при демонстрации работы системы в конце дня, когда мы направили поток данных для обработки средствами EtherCalc и начали вводить формулы в открытую в браузере электронную таблицу, сервер внезапно прекратил обработку запросов, заморозив все активные соединения. Мы перезапустили процесс Node.js и обнаружили только то, что он потребляет 100% времени центрального процессора, прекращая обработку запросов спустя некоторое время.

Поразившись, мы решили использовать набор данных меньшего объема, с которым система работала корректно и позволяла завершить демонстрацию своих возможностей. Но меня все равно волновал следующий вопрос: "Какое обстоятельство в первую очередь привело к остановке работы серверного приложения?"

Продолжение статьи: Профилирование Node.js.