От SocialCalc к EtherCalc

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

Оригинал: From SocialCalc to EtherCalc
Автор: Audrey Tang
Дата публикации: 21 Сентября 2012 г.
Перевод: А.Панин
Дата перевода: 16 Декабря 2013 г.

EtherCalc является системой удаленного редактирования электронных таблиц, оптимизированной для выполнения одновременных операций редактирования и использующей SocialCalc в качестве системы обработки электронных страниц на стороне браузера. Спроектированная Dan Bricklin (создателем концепции электронных страниц), система SocialCalc является частью платформы Socialtext, предоставляющей набор инструментов удаленного взаимодействия для корпоративных пользователей.

Главной целью членов команды разработчиков платформы Socialtext в ходе работы над компонентом SocialCalc в 2006 году было достижение оптимальной производительности. При этом ключевое наблюдение заключалось в следующем: хотя расчеты на стороне клиента средствами языка JavaScript и выполняются в разы медленнее, чем на расчеты на стороне сервера средствами языка Perl, их результаты выводятся гораздо быстрее ввиду того, что при работе с сервером появляется дополнительная задержка из-за передачи AJAX-запросов по сети.

Рисунок 2.1 - Модель производительности WikiCalc и SocialCalc. Благодаря оптимизациям сред исполнения сценариев на языке JavaScript, с 2009 года время расчета снизилось с 50 мс до менее чем 10 мс.

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

Рисунок 2.2 - Взаимодействие пользователей SocialCalc

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

Платформа Socilatext должна была работать как на системах, находящихся за межсетевыми экранами, так и на облачных системах, что обуславливало уникальные требования, предъявляемые к EtherCalc в плане использования ресурсов и производительности.

На момент написания этой главы для работы платформы Socilatext требовалось два ядра центрального процессора и 4 Гб оперативной памяти при условии ее развертывания во внутренней сети с использованием VMWare vSphere. В случае использования облачного хостинга стандартный тарифный план сервиса Amazon EC2 предусматривает предоставление в два раза большего объема ресурсов, а именно 4 ядер центрального процессора и 7.5 Гб оперативной памяти.

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

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

Продолжение статьи: Начальный прототип.