АНАЛИЗ ПРОИЗВОДИТЕЛЬНОСТИ ВЕБ-ФРЕЙМВОРКОВ GO ДЛЯ RESTFUL-СЕРВИСОВ

АННОТАЦИЯ

В современном мире выбор правильного веб-фреймворка является ключом к созданию приложений, способных работать с большим количеством пользователей и обеспечивающих высокую производительность. Растет спрос на Go (Golang) при разработке параллельных веб-сервисов. Важно понимать, как различные платформы Go справляются с высокой нагрузкой пользователей. Существует не так много исследований о том, насколько хорошо эти фреймворки работают в одних и тех же условиях. В этом исследовании сравниваются Beego, Echo и Gin, использующие Apache JMeter (5.6.3) для измерения времени отклика при обработке от 500 до 2000 запросов одновременно на конечных точках RESTful GET, POST и PUT. В ходе экспериментов были измерены среднее время отклика, стандартные отклонения и стабильность производительности на разных уровнях параллелизма. Результаты наглядно демонстрируют значительные различия в эффективности работы платформ. У Echo было наиболее стабильное время отклика, в то время как производительность Beego при обработке POST-запросов снижалась при высокой нагрузке. Производительность Gin была нестабильной, иногда она превосходила другие, но при определенных условиях также наблюдались внезапные скачки. В этом исследовании представлены реальные данные, которые помогут разработчикам выбрать наилучшую платформу Go для приложений. Мы предоставляем полезную информацию для повышения производительности микросервисных и облачных систем, показывая, как каждая платформа работает в условиях параллелизма. Эти результаты являются хорошей отправной точкой для будущих исследований того, насколько хорошо платформы справляются с большим количеством пользователей, проблемами безопасности и как они используются в реальном мире.

ABSTRACT

In today's world, choosing the right web framework is key to building applications that can handle a lot of users and perform well. There is a growing demand for Go (Golang) in developing concurrent web services. It's important to understand how various Go frameworks handle high user loads. There isn't much research on how well these frameworks perform under the same conditions. This study compares Beego, Echo, and Gin using Apache JMeter (5.6.3) to measure their response times when handling 500 to 2000 requests at once on RESTful GET, POST, and PUT endpoints. The experiments measured average response times, standard deviations, and how stable the performance was across different levels of concurrency. The results clearly show big differences in how well the frameworks worked. Echo had the most consistent response times, while Beego's performance dropped in POST requests when there was a high load. Gin's performance was unstable, sometimes outperforming the others but also experiencing sudden spikes under certain conditions. This study provides real-world data to help developers choose the best Go framework for applications. We provide useful information for improving performance in microservice and cloud-based systems by showing how each framework performs under concurrency pressure. These findings are a good starting point for future research on how well the frameworks can handle more users, security issues, and how they are used in the real world.

Ключевые слова: Go веб-фреймворки, конкурентность, RESTful-сервисы, микросервисы, контейнеризация Docker, оценка производительности, нагрузочное тестирование JMeter.

Keywords: Go Web Frameworks, Concurrency, RESTful Services, Microservices, Docker Containerization, Performance Evaluation, JMeter Load Testing.

Введение

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

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

Исследования показывают, что Go лучше, чем Java и Python, справляется с высокой параллельной нагрузкой [15]. Он по-прежнему эффективен для микросервисов даже при высоких нагрузках. Контейнеризация стала стандартной практикой в современных конвейерах DevOps. Поэтому важно понять, как Beego, Echo и Gin работают в контейнерных микросервисных средах.

Исследования использования Go в Индустрии 4.0 показывают, что он конкурирует с Java и Python при решении сложных алгоритмов и задач принятия решений. Однако в этих исследованиях редко сравниваются лучшие фреймворки Go в одинаковых условиях. Важно понять, как эти фреймворки справляются с различными RESTful-операциями на разных уровнях параллелизма. Данное исследование восполняет этот пробел, проверяя производительность Beego, Echo и Gin. Мы протестировали их среднее время отклика на запросы GET, POST и PUT с 500-2000 пользователями с помощью Apache JMeter (версия 5.6.3). Проведя эти тесты, мы предоставили разработчикам полезную информацию, которая поможет им выбрать правильный фреймворк для высокопроизводительных микросервисных и контейнерных приложений.

Материалы и методы исследования

Изучая, насколько хорошо работают веб-приложения и как они спроектированы при веб-разработке, можно сказать, что каждое решение влияет на то, насколько хорошо приложение работает и функционирует. В том числе выбор базы данных или модели параллелизма. В последние годы переход к микросервисам сделал еще более важным использование эффективных фреймворков, поскольку каждый сервис должен самостоятельно обрабатывать большой объем трафика [1], [6]. Go является популярным выбором для высококонкурентных систем благодаря своим легким функциям, таким как goroutines и channels [3].

В исследованиях по параллелизму Go часто сравнивают с Java, Python или другими языками. Авторы [13] обнаружили, что Go быстрее, чем Java, выполняет умножение матриц благодаря своим легким горутинам. В другой работе [14] показано, что многопоточность Go позволяет эффективно использовать аппаратное обеспечение, сохраняя при этом простоту кода. Доказано, что Go выполняет алгоритмы, вдохновленные природой, быстрее, чем Python, показав, что параллелизм Go хорошо работает для задач, требующих большого количества процессора. Эти исследования больше сосредоточены на алгоритмах и сырой производительности, чем на веб-фреймворках, но они все равно показывают, что Go хорошо справляется с высокими нагрузками, что важно для Beego, Echo и Gin.

Исследователи используют инструменты нагрузочного тестирования, такие как TTCN-3 или Apache JMeter, для проверки современных веб-сервисов [2], [7]. Но нагрузочное тестирование само по себе не решает проблемы контейнеризации, которая характерна для DevOps и микросервисов. Исследователи обнаружили, что небольшое время выполнения Go делает его хорошо подходящим для Docker [12]. Они также изучили, как встраивание Python в Go может помочь с автоматизацией в Ansible [20]. Эти исследования показывают, что низкие накладные расходы, поддержка контейнеров и автоматизация являются ключевыми при выборе веб-фреймворка для крупномасштабных систем. Хотя фреймворки Go могут справиться с большим количеством операций одновременно, важно протестировать их в реальных контейнерных средах, чтобы понять, насколько хорошо они работают.

Go известен своим сильным параллелизмом, но прямых сравнений его популярных фреймворков не так много. В статье [11] автор протестировал Fiber, Gin, Beego и Echo в нефтегазовой отрасли и обнаружил, что Echo лучше всего работает при больших нагрузках. В других исследованиях [16], [17] сравнивались веб-приложения на базе Go с Node.js, Python и PHP, и было показано, что Go в целом обладает лучшей пропускной способностью. Однако эти исследования редко сравнивают Go-фреймворки между собой. Поскольку уже существует множество различных бенчмарков, очевидно, что нам необходимо провести прямое тестирование Beego, Echo и Gin в реальных сценариях работы с RESTful API.

В веб-разработке безопасность не менее важна, чем эффективность, а защита пользовательских данных по-прежнему остается сложной задачей [8]. Добавление мер безопасности может сделать фреймворк медленнее в практических приложениях, даже если он показывает хорошие результаты в тестах. Исследования показывают, что встроенных средств безопасности фреймворка недостаточно для обеспечения защиты данных, точности и доступности сервисов [5]. Поэтому разработчикам нужен фреймворк, способный обрабатывать большой объем трафика и поддерживать важные функции безопасности без сильного падения производительности. Если при сравнении не учитывать накладные расходы на безопасность, такие как TLS, аутентификация или протоколирование, результаты могут оказаться не такими хорошими, как кажется.

Помимо безопасности, фронтенд-технологии помогают онлайн-приложениям работать без сбоев. По данным исследования популярных фронтенд-технологий Angular, React, Vue, Svelte и Blazer [9], то, как они разработаны, может сильно повлиять на пользовательский опыт. Хотя эти результаты могут повлиять на скорость работы клиентской части, они не позволяют определить, какая архитектура бэкенда лучше всего справляется с процессами, которые одновременно выполняются на стороне сервера. Кроме того, эффективность работы серверной части зависит от того, насколько хорошо база данных взаимодействует с приложением. Исследования, сравнивающие базы данных NoSQL и SQL в средах IoT, показывают, что ни одно решение для хранения данных не работает лучше во всех ситуациях [10]. Веб-фреймворки Go должны обеспечивать различные способы доступа к данным без замедления работы системы.

На уровне языка производительность при высоком параллелизме во многом зависит от сборщика мусора Go и анализа побега. Исследователь [19] предлагает метод, чувствительный к полю, который сокращает время реакции фреймворков, регулярно создающих объекты (например, при разборе JSON или маршрутизации). В других условиях, таких как Industry 4.0, авторы [18] обнаружили, что Go конкурирует с Java и Python для алгоритмов деревьев решений. Это говорит о том, что модель параллелизма и управление памятью в Go могут справиться со сложными задачами. Эти результаты показывают, что при тестировании Go-систем важно учитывать не только параллелизм, но и потребление памяти и оптимизацию компилятора.

Выбор безопасного и масштабируемого фреймворка —  дело непростое. На него влияет множество факторов, включая архитектуру, параллелизм, контейнеризацию, безопасность, интеграцию с внешним окружением, производительность базы данных и использование памяти. Исследования предлагают хороший анализ параллелизма Go, управления памятью, но не так много прямых сравнений Go-фреймворков, таких как Beego, Echo и Gin, для простых RESTful-приложений. Данное исследование призвано восполнить этот пробел путем сравнения Beego, Echo и Gin в контролируемых условиях.

A. Методология исследования

В нашем исследовании мы используем инструмент Apache JMeter (версия 5.6.3) для измерения времени отклика путем симуляции высокой пользовательской нагрузки. JMeter — один из наиболее используемых инструментов в разработке программного обеспечения для тестирования поведения веб-приложений под нагрузкой. Он помогает нам создавать реалистичные сценарии нагрузки и получать последовательные метрики для оценки производительности.

B. Экспериментальная установка

Для проведения нашего эксперимента в качестве машины использовался Macbook, подробная информация о котором приведена в таблице 1. С помощью этих конфигураций мы минимизировали внешние факторы, такие как сетевые задержки, затраты на оркестровку, чтобы обеспечить изолированные равные среды для каждого фреймворка. Версия Go 1.20 использовалась по умолчанию для каждого фреймворка, чтобы избежать различий в компиляторе и времени выполнения. В качестве базы данных использовался Postgres, запущенный в контейнере Docker на той же машине.

Таблица 1.

 Технические характеристики аппаратного и программного обеспечения

C. Показатели производительности

Эксперимент был сосредоточен на среднем времени отклика HTTP GET, POST и PUT запросов при 500, 1000 и 2000 одновременных пользователей. Кроме того, мы отслеживали минимальные и максимальные значения, чтобы выявить любые необычные скачки. Мы также наблюдали за стандартным отклонением времени отклика и отмечали, как часто запросы удавались или не удавались под высокой нагрузкой.

D. Схема эксперимента

Наша цель состояла в том, чтобы оценить каждый фреймворк в условиях высокой нагрузки, без влияния сложной бизнес-логики или внешних микросервисов. Этот метод связан с некоторыми исследованиями параллелизма в Go, но он сосредоточен в первую очередь на Beego, Echo и Gin.

1. Разработка приложений и первоначальная проверка: После настройки и реализации REST-приложений мы протестировали их с помощью Postman, чтобы убедиться, что все приложения корректно обрабатывают GET, POST и PUT запросы, прежде чем начать эксперимент с Apache JMeter. Мы также проверили соответствие форматов ответов и кодов статусов во всех фреймворках.
2. Нагрузочное тестирование: Мы смоделировали 500, 1000 и 2000 пользовательских нагрузок в Apache JMeter, постепенно увеличивая их количество в течение 20 секунд, чтобы избежать внезапных необычных скачков. Трижды тестировалась каждая комбинация фреймворка, уровня параллелизма и типа запроса, чтобы снизить случайные вариации. Поэтому в основу результатов легло среднее значение этих прогонов.
3. Сбор данных: Время отклика, показатели успешности и временные метки были экспортированы непосредственно из JMeter в CSV-файлы.
4. Анализ данных: Мы использовали pandas для чтения CSV в Jupyter Notebook, что помогло рассчитать такие метрики, как среднее, максимальное, минимальное время отклика, стандартное отклонение. Также мы использовали «matplotlib» для создания визуализации, чтобы понять тенденции производительности.

E. Высокоуровневая архитектура

На рисунке 1 показана общая архитектура тестирования. JMeter отправляет HTTP-запросы каждому фреймворку, который затем запрашивает PostgreSQL, запущенный в Docker, и получает ответы обратно в JMeter.

Рисунок 1. Высокоуровневая архитектура установки для тестирования производительности

Результаты и обсуждения

A. Обзор экспериментальных запусков

После окончательного разбора CSV-файлов с помощью pandas мы получили точные результаты времени отклика, которые сведены в таблицу.

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

Таблица 2.

Среднее время отклика (мс) для каждого фреймворка и уровня параллелизма

a. GET запросы                                b. POST запросы

c. PUT запросы

Рисунок 2. Среднее время отклика

A. GET запросы

Подфигура (a) рисунка 2 показывает, что и Beego, и Echo демонстрируют заметную стабильность в диапазоне от 20 до 40 мс, при этом Echo достигает пика в 40,77 мс при количестве пользователей 1000. Gin демонстрирует значительную нестабильность, увеличиваясь до 153,23 мс при 1000 пользователях, а затем снижаясь до 20,78 мс при 2000 пользователях. Такой всплеск производительности может быть связан с тем, как планируются goroutines или как фреймворк управляет внутренними очередями при слишком большом параллелизме. Возможно, что приложения Go могут работать неоптимально, если сборка мусора или синхронизация происходят одновременно с периодами высокого трафика. Однако производительность Gin снова стабилизируется при 2000 пользователей, что может означать, что приложение само настраивается - возможно, лучше управляя пулами goroutine или улучшая пропускную способность по мере роста нагрузки. Подобные тенденции мы наблюдали и в других тестах микросервисов на Go, что говорит о том, что у каждого фреймворка есть "золотая середина" для работы с параллелизмом.

B. POST запросы

Beego хорошо работает с 500 и 1000 пользователями (2,71 мс и 4,21 мс), но его производительность значительно падает (343,10 мс) при 2000 пользователях, как показано в подфигуре (b) на рисунке 2. Echo остается в диапазоне от 2,67 до 5,78 мс, показывая, что он хорошо справляется с маршрутизацией при больших нагрузках. Gin увеличивается до 20,56 мс при 1000 пользователях, но снижается до 1,45 мс при 2000 пользователях, что снова свидетельствует о нелинейном масштабировании. Падение производительности Beego говорит о том, что при более высоких уровнях параллелизма его ORM или стратегия пулинга соединений могут дать сбой, о чем сообщалось в другой работе [4]. Для сравнения, легковесное промежуточное ПО Echo может помочь уменьшить узкие места, а рост производительности Gin при высоких нагрузках говорит о том, что планирование параллелизма может быть непредсказуемым. Это говорит о том, что при достижении определенной нагрузки производительность фреймворка может либо значительно упасть, либо неожиданно повыситься.

C. PUT запросы

Как показано в таблице 2, Beego и Echo имеют одинаковое время отклика на PUT-запросы при различных нагрузках (9-17 мс), в то время как Gin остается стабильным до 1000 пользователей, но увеличивается до 47,89 мс при 2000 пользователей. PUT-запросы схожи с POST, поскольку они обновляют записи, что может привести к блокировке базы данных или дополнительной записи. Скачок Gin при 2000 пользователей может быть связан с дополнительной работой, необходимой для частичного обновления или блокировки. Это подтверждает ранее сделанные выводы о том, что фреймворки по-разному справляются с нагрузками, связанными с чтением и записью. Стабильность Echo совпадает с результатами исследования [2], что говорит о том, что эффективная маршрутизация помогает плавно управлять умеренным параллелизмом. Однако продвинутые инструменты, анализирующие данные и память, могут помочь снизить накладные расходы фреймворка в случаях, когда объекты часто создаются для маршрутизации или привязки данных.

D. Краткие выводы

Наши результаты показывают, что Echo работает стабильно, в то время как Beego испытывает трудности с POST при высокой нагрузке, но хорошо справляется с GET и PUT. Производительность Gin сильно колебалась, с различными пиками. Эти результаты показывают важность выбора фреймворка, который хорошо подходит для рабочей нагрузки и требований к масштабируемости.

Чтобы понять, насколько хорошо работает каждая система, мы посмотрели среднее время отклика и то, насколько оно отличается от ожидаемого. Это было сделано для различных типов запросов (GET, POST, PUT), пользовательских нагрузок (500, 1000, 2000) и фреймворков (Beego, Echo, Gin). В таблице 3 приведены основные статистические данные одного тестового прогона для каждого случая. Эти данные помогают выявить любые скачки производительности или нестабильность, которые могут быть вызваны такими вещами, как обработка параллелизма, сборка мусора или другими внутренними факторами, известными из предыдущих исследований Go.

Таблица 3.

Среднее значение и стандартное отклонение времени ответа (мс) на уровне запросов

По этим результатам видно, что среднее время отклика соответствует общим тенденциям, о которых говорилось ранее, а стандартное отклонение показывает, насколько стабилен каждый фреймворк под нагрузкой. Например, при 1000 одновременных GET-запросов Gin показывает высокое стандартное отклонение в 392,65 мс, что означает, что время отклика сильно варьируется в течение одного и того же теста. Это подтверждает предыдущие наблюдения о том, что Go-фреймворки могут испытывать скачки производительности, когда перегружаются goroutines или механизмы синхронизации. Аналогичный случай наблюдается и с Beego при 2000 POST-запросов, где стандартное отклонение достигает 1166,88 мс - признак заметной нестабильности между запросами, возможно, вызванной блокировкой или сборкой мусора во время интенсивных операций записи.

Мы также использовали односторонний дисперсионный анализ (ANOVA) для Beego, Echo и Gin для каждой комбинации метода и уровня параллелизма. В таблице 4 приведены F-статистика и ее p-значение. При уровне значимости 0,05 значение p-value ниже 0,05 может свидетельствовать о том, что среднее распределение времени отклика хотя бы одного фреймворка значительно отличается от других.

Таблица 4.

 Результаты одностороннего ANOVA среди фреймворков в каждом (метод, пользователи)

При значении p-value менее 0,05 все девять тестов показывают значительные различия между тремя моделями. Среднее время отклика Beego намного выше, чем у Echo и Gin. POST-запросы при 2000 пользователей демонстрируют наибольший разброс.

В соответствии с предыдущим обсуждением среднего времени отклика, результаты ANOVA показывают, что Echo в целом обеспечивает наиболее стабильную производительность с более низкими стандартными отклонениями в большем количестве случаев. Gin имеет конкурентоспособное среднее время отклика, но оно более изменчиво, особенно при большом количестве параллельных запросов, что позволяет предположить, что ограничения параллельности и накладные расходы на синхронизацию могут вызывать периодические скачки. Beego в целом стабилен, но в экстремальных случаях, таких как POST при 2000 пользователей, он испытывает трудности. Вероятно, это связано с параллелизмом или неэффективностью ORM во время интенсивных операций записи.

Наше исследование предоставляет полезную информацию о производительности Beego, Echo и Gin в контролируемых условиях. Однако при использовании этих результатов в производственных условиях следует учитывать некоторые факторы.

Ограничения локального окружения. Все тесты проводились на MacBook Air (M1), где веб-фреймворки и база данных PostgreSQL работали в контейнерах Docker на одной машине. Такая настройка не совсем похожа на реальную распределенную или облачную систему, но она позволила уменьшить сетевые задержки и провести корректное сравнение. Такие вещи, как балансировщики нагрузки, сетевые задержки и географические различия, могут влиять на производительность в производственных условиях, когда сервисы взаимодействуют через Интернет.

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

Существуют также ограничения на типы запросов, которые можно выполнять. Мы протестировали операции GET, POST и PUT, которые часто встречаются в RESTful API, но существует множество других HTTP-методов (например, DELETE, PATCH).

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

Будущие направления. Тестирование с распределенными базами данных, моделирование сети или создание полноценных микросервисов (например, Kubernetes) сделало бы наши результаты более применимыми.

Заключение

В целом, тесты показали, что Echo работает с очень небольшим отклонением во времени отклика. Beego хорошо работает под сильной нагрузкой POST, но также справляется с GET- и PUT-запросами. Gin нуждается в доработке, поскольку он лучше работает при высоком параллелизме, но не так хорошо при низких уровнях нагрузки. Выбор фреймворка Go зависит от рабочей нагрузки: Echo может быть особенно хорош в ситуациях с быстрыми скачками или интенсивными операциями записи, когда Beego и Gin могут выиграть от дополнительной оптимизации. Мы использовали одну машину для проведения этих тестов, но результаты дают нам хорошее представление о том, какой фреймворк лучше.

Список литературы:

1. G. Blinowski, A. Ojdowska and A. Przybylek, IEEE Access 10, 20357-20374 (2022). https://doi.org/10.1109/ACCESS.2022.3152803.
2. H. Kaur Dhalla, Journal of Physics: Conference Series 1933(1), 012041 (2021). https://doi.org/10.1088/1742-6596/1933/1/012041.
3. Abhinav P.Y., Avakash B, C. Terese Joseph and K. Chandrasekaran, 5th International Conference on Computing, 1-6 (2020). https://doi.org/10.1109/ICCCS49678.2020.9277498.
4. W. Khan, T. Kumar, C. Zhang, K. Raj and A. M. Roy, Big Data and Cognitive Computing 7(2), 97 (2023). https://doi.org/10.3390/bdcc7020097.
5. Jan-Marius G., Tufts University, 2019. http://www.cs.tufts.edu/comp/116/archive/fall2019/jgrunwaldt.
6. Y. Abgaz, A. Mccarren, P. Elger, D. Solan, N. Lapuz, M. Bivol, G. Jackson, M. Yilmaz, J. Buckley and P. Clarke, IEEE Transactions on Software Engineering 49. 4213-4242 (2023). https://doi.org/10.1109/TSE.2023.3287297.
7. T. Vassiliou-Gioles, 2020 IEEE 20th International Conference on Software Quality, 498-505 (2020). https://doi.org/10.1109/QRS-C51114.2020.00089.
8. Eriyanto A. S. and Fadhil H., 7th International Conference on ICT for Smart Society, 1-6 (2020). https://doi.org/10.1109/ICISS50791.2020.9307569.
9. Risto O., Niko M. and Tommi M., Journal of Web Engineering 21, 789-813 (2022). https://doi.org/10.13052/jwe1540-9589.21311.
10.  S. Reetishwaree and V. Hurbungs, 3rd International Conference on Emerging Trends, 229-234 (2020). https://doi.org/10.1109/ELECOM49001.2020.9297028.
11. K. E. Lie, M. S. Astriani and I. B. Kerthyayana, 2nd International Conference on Technology Innovation, 1-6 (2024). https://doi.org/10.1109/ICTIIA61827.2024.10761385.
12.  Sangam M. Biradar, R. Shekhar and A. Pranayanath Reddy, Second International Conference on Intelligent Computing and Control Systems (ICICCS), 1-4 (2018). https://doi.org/10.1109/ICCONS.2018.8663172.
13.  N. Togashi and V. Klyuev, 4th IEEE International Conference on Information Science and Technology, 213-216 (2014). https://doi.org/10.1109/ICIST.2014.6920368.
14.  C. Gao, H. Lv and Y. Tan, 3rd Asia-Pacific Conference on Communications Technology and Computer Science (ACCTCS), 603-608 (2023). https://doi.org/10.1109/ACCTCS58815.2023.00116.
15.  P. Shukla, S. Thakur, S. Arora and A. Wadhwa, 1st International Conference on Informatics (ICI), 226-228 (2022). https://doi.org/10.1109/ICI53355.2022.978691.
16.  T. Tanadechopon and B. Kasemsontitum , 7th International Conference on Information Technology (InCIT), 293-297 (2023). https://doi.org/10.1109/InCIT60207.2023.10413079.
17.  A. Nabiil, B. Hermawan, R. W. Wijaya, A. A. Gunawan and I. S. Edbert, International Conference on Information Technology and Computing (ICITCOM), 6-11 (2023). https://doi.org/10.1109/ICITCOM60176.2023.10442358.
18.  P. Dymora and A. Paszkiewicz, Applied Sciences-Basel 10(23), 8521 (2020). https://doi.org/10.3390/app10238521.
19.  B. Ding, O. Li, Y. Zhang, F. Tang and J. Chen, ACM on Programming Languages 8, 1362-1389 (2024). https://doi.org/10.1145/3689759.
20.  D. Badalyan and O. Borisenko, SoftwareX journal 19, 2022. https://doi.org/10.1016/j.softx.2022.101126.