Быстродействие системы с точки зрения пользователя

Скорость загрузки приложения

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

Но приложение — это не один исполняемый файл, а набор скриптов, библиотек, вёрстки и графики. Постоянные запросы к frontend-серверу за этими компонентами могут сильно замедлить работу. Мы используем технологию одностраничного приложения SPA (Single Page Application). Она позволяет значительно ускорить View (представление) в схеме данных MVC (Model-View-Controller), перенеся все сложные расчёты на конечное устройство пользователя.

В обычном приложении мы загружаем сервер обработкой вёрстки и исполнением скриптов, а также загружаем канал, передавая эту информацию. А в случае SPA весь необходимый для работы код (HTML, CSS и JavaScript) загружается вместе со страницей, и его обработка производится локально мощностью рабочей станции — обращение к backend-серверу минимально, загружаются только необходимые в данный момент данные.

С одной стороны, использование SPA может увеличить время первичной загрузки, с другой — дальнейшая работа будет выполняться быстрее.

Следовательно, скорость загрузки приложения зависит от ширины полосы канала Интернет, производительности рабочей станции, а также технологии используемого frontend-решения. SPA позволяет ускорить работу интерфейса, минимизируя работу с Сетью и сокращая число запросов к БД.

Скорость отрисовки содержимого окна и SPA

Работа с приложением в большинстве случаев — работа с данными. Данные генерируются, загружаются в БД с помощью пользовательского интерфейса или других источников и выводятся по запросу в соответствующие блоки SPA. Используя SPA, мы делаем frontend и backend настолько независимыми, что позволяем пользователям программировать отельные виджеты клиентского интерфейса, куда происходит загрузка данных из базы. Их работа полностью осуществляется локально, backend-сервер в ней не участвует, а значит, передача кода и вёрстки этого элемента не осуществляется — только данные.

Для реализации Single Page Application мы выбрали одну из самых популярных библиотек JavaScript — React. Она входит в топ-3 самых популярных инструментов для создания пользовательских интерфейсов, собрала многочисленное сообщество и постоянно развивается. Технология была разработана компанией Facebook и отлично зарекомендовала себя в работе с большими нагрузками социальной сети.

Для решения задачи быстродействия пользовательского интерфейса React JS позволяет при обновлении страницы производить загрузку только нового контента. Условно окно приложения можно разделить на блоки. Если в одном блоке нажать кнопку для обновления данных, то перезагрузка информации произойдёт лишь в том блоке, который отвечает за её отображение, — все остальные останутся статичны. Более того, загрузив данные в своё хранилище, React в дальнейшем может показывать данные из него, а из БД запрашивать только те сведения, которые изменились, а не обновлять весь блок.

Например, пользователь открыл страницу со списком инцидентов. Страница содержит саму таблицу записей инцидентов, а также графические элементы — кнопки, фильтры и т. п. Щелчок по одной из записей (инциденту) в таблице открывает его полные характеристики. Возврат обратно к списку приводит к перезагрузке страницы инцидентов, однако с сервера загружаются только обновлённые данные в таблицу, а все остальные элементы (кнопки, надписи, фильтры и т. п.) отображаются из кэша, к БД за ними приложение уже не обращается.

Обработка запроса и обращение к базе данных

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

Число транзакций зависит от реализации самого приложения. Так, в одном случае клик в интерфейсе может сгенерировать 5000 обращений к базе, следовательно, 200 таких кликов — это миллион транзакций. Для рекламного буклета эта цифра звучит впечатляюще, а в реальной работе она обозначает лишь 20 кликов мышкой десятью пользователями системы. Наша платформа может обработать такой клик, совершив всего 100 обращений к базе. Получаем меньшее число транзакций, а значит, меньший трафик к БД для реализации тех же действий. Поэтому мы учитываем «хиты», то есть действия пользователя с приложением, которые приводят к обращению к БД.

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

Расчёт «хитов» — обращений к странице, а не к БД — позволяет клиентам точно оценить необходимое быстродействие платформы под задачи своей компании, а для разработчика — рассчитать необходимость и требования к горизонтальному масштабированию, которое позволяет наиболее эффективно распределять нагрузку, повышать производительность и улучшать пользовательский опыт. Об этом мы расскажем в будущих статьях.

Быстрая и отказоустойчивая работа базы данных — это одна из самых сложных задач любого проекта по разработке. На неё ложится самая большая нагрузка, и в случае «падения» без информации остаётся любой интерфейс, каким бы быстрым и эргономичным он ни был. Мы снижаем до минимума число запросов к БД, чтобы сделать её максимально доступной, и считаем не транзакции, а скорость обработки реальных действий пользователя.

Технологии работают на пользователя

Наша задача — обеспечить пользователю высокую скорость работы с системой, и реализуем мы это с помощью современных технологий. Чтобы интерфейс работал быстро, а запросы выполнялись отдельно и не снижали скорость его отклика, мы внедрили SPA и кешируем «горячие» данные как на сервере, так и на локальной машине.

Методика расчёта производительности по числу обращений пользователя к серверу позволяет точно определить необходимую производительность и обеспечить её с помощью распределения нагрузки и горизонтального масштабирования. В ESM-системе SimpleOne могут одновременно комфортно работать как сотни пользователей, так и тысячи. Платформа позволяет удовлетворять растущие нагрузки бизнеса и с увеличением числа пользователей, и после расширения функциональных возможностей с помощью No Code и инструментов Low Code, а также доработок Pro Code.