Библиотека сайта rus-linux.net
От SocialCalc к EtherCalc
Глава 2 из книги "Производительность приложений с открытым исходным кодом".
Оригинал: From SocialCalc to EtherCalc
Автор: Audrey Tang
Перевод: А.Панин
SocialCalc на стороне сервера
Ключевой технологией, применяемой в нашей работе, является технология jsdom, предоставляющая завершенную реализацию объектной модели документа W3C, которая позволяет фреймворку Node.js загружать переданные клиентом библиотеки на языке JavaScript в рамках симулируемого окружения браузера.
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.