Skip to content

Latest commit

 

History

History
95 lines (61 loc) · 7.52 KB

README.md

File metadata and controls

95 lines (61 loc) · 7.52 KB

Сервис обмена случайными картинками

Обзор

Разработка сервиса, позволяющего обмениваться случайными картинками из выбранной категории. Сервис позволяет получить картинку из категории и/или отправить картинку с меткой категории.

Взаимодействие

Поскольку взаимодействие клиента и сервера может быть описано последовательностью независимых событий то подразумевается асинхронная обработка запросов.

Основными примитивами взаимодействия являются функции, аргументы и результаты выполнения функция.

Так же не гарантируется значение результата при выполнении одного и того же запроса.

Поэтому выбрана модель взаимодействия RPC.

Формат сообщений

  • {"jsonrpc": "2.0", "method": "listCategories", "id": 3} - получение списка доступных категорий

    {"jsonrpc": "2.0", "result": [%categories%], "id": 3} - ответ со списком категорий

  • {"jsonrpc": "2.0", "method": "download", "id": 3} - получение случайной картинки из всего набора

    {"jsonrpc": "2.0", "result": [%category%, %base64_string%], "id": 3} - ответ с тегом категории и картинкой в формате base64

  • {"jsonrpc": "2.0", "method": "download", "params": {"category": %category%}, "id": 3} - получение случайной картинки из выбранной категории

    {"jsonrpc": "2.0", "result": %base64_string%, "id": 3} - ответ с картинкой в формате base64

  • {"jsonrpc": "2.0", "method": "upload", "params": {"category": %category%, "image": %base64_string%}, "id": 3} - загрузка картинки в выбранную категорию

    {"jsonrpc": "2.0", "result": %msg%, "id": 3} - ответ содержит сообщение success в случае успеха и текст ошибки

{"jsonrpc": "2.0", "error": {"code": %code%, "message": %msg%}, "id": 3} - ответ в случае ошибки обработки запроса

Картинки передаются в формате base64.

CAP

Для описанного сервиса необходимо обеспечить доступность (Availability) и устойчивость к разделению (Partition tolerance). Гарантирование доступности необходимо поскольку основной задачей сервиса является обмен картинками между пользователями. Однако не гарантируется Сonsistency, т.к. чтение осуществляется случайно.

Для обеспечения работы сервиса нет необходимости хранить реляционные связи между данными. Поэтому для упрощения работы и обеспечения масштабируемости можно использовать No-SQL.

Для обеспечения AP можно использовать Apache Cassandra с соответствующей конфигурацией.

  • Consistency Level для записи: LOCAL_ONE. Данная конфигурация требует минимум одной успешной записи реплики на локальную ноду. В этом случае обеспечивается высокая Availability участием небольшого числа нод.

  • Consistency Level для чтения: LOCAL_ONE. Принцип как и при записи. Чтение подтверждается ответом с ближайшей локальной ноды.

Нагрузочное тестирование

Основными метриками нагрузочного тестирования были выбраны время отклика(в миллисекундах) и процент неудачных ответов. Для каждого ответа дополнительно проверялись условия валидности полученных данных. Если условия не выполнялись, то ответ считался неудачным.

Для тестирования использовался сценарный подход. Он заключался в моделировании поведения пользователей. Предпочтение запросов:

  • 45.5% получение случайной картинки
  • 45.5% получение случайной картинки из выбранной категории
  • 9.1% полуяение списка категорий

По типу тестирования проводились Load test и Stress test. В качестве инструмента использовался Locus.

Тестирование проводилось на одной машине с сервисом.

Отчёт по Load test. Количество пользователей: 10. Время между запросами одного пользователя 0.1s - 1s. По результатам можно сделать вывод, что решение прошло тестирование в данной конфигурации. Процент неудачных ответов: 0%. 99% персентиль времени отклика: 210ms. Мониторинг используемых ресурсов показал что пики на Response Times связаны с использованием процессора (в эти моменты 100%). Статистика подтверждает, что эти точки можно считать выбросами.

Время отклика при числе пользователей 50 Из графика можно видеть, что время отклика значительно увеличилось. Мониторинг ресурсов показал, что узким местом является процессор(85-100% на протяжении тестирования). При этом процент неудачных ответов остаётся на уровне 0%.

Время отклика при числе пользователей 100 Видно, что задержка увеличивается примерно линейно относительно увеличения числа пользователей. Данный тест подтверждает гипотезу о том что мощность процессора является узким местом (93-100% на протяжении тестирования). Процент неудачных ответов: 1% - 5%.

При числе пользователей > 300 начинается отказ системы. Процент ошибок: >22%. (e.g. Connection reset by peer)