vktest

Тестовое задание. Описание:
Реализовать простую систему просмотра списка товаров. Товар описывается несколькими полями: id, название, описание, цена, url картинки. Требуется реализовать:

• интерфейс создания/редактирования/удаления товара;
• страница просмотра списка товаров. Товары можно просмотривать отсортированные по цене или по id.
• поддержку количества товаров в списке до 1000000.
• устойчивость к нагрузке – 1000 запросов к списку товаров в минуту.

Время открытия страницы списка товаров < 500 мс.
Техника: PHP (без ООП), mysql, memcached. Фронтэнд - на ваше усмотрение.

Инструменты разработки

1. База данных. Как было указано в требованиях MySql
2. Memcached. Мое мнение - можно было обойтись без нее, но так как это тестовое задание, то реализовал применение.
3. Бэкенд. Использовал микрофреймворк Slim3. Предлагает удобные инструменты разрабатывать веб-приложения, REST-приложения.
4. Фронтэнд. Bootstrap JQuery.
5. Docker для деплоймента.

Решение

Решение 1

Не использовать Memcached, делать запросы по странично в БД. Однако в целях демонстрации навыков в рамках тесового задания решил сделать решение с использовванием Memcached.

Решение 2

Выгрузить все данные из БД и хранить по блочно (в блоке 1000 записей) в Memcached и делать манипуляциии с данными в кэше помимо отрправления запросов. Планировалось хранить две копии списка. Первый отсортированный по id, второй - по цене. Основная головная надо было обновить блоки при изменени добавлении и удалении. К тоу же был риск не успеть это реализовать. В итоге от этой идеи отказался.

Решение 3

По мере извлечения данных, записывать их в кэш. Далее при запросе страницы, если оно в кэше - доставать оттуда, иначе - запрос в БД. Данные запрашиваются по странично. Соттветсвенно страницы отсортированные по id и цене хранятся отдельными блоками. Также для каждого поля отдельно хранить блоки отсортированные по убыванию и возрастанию. Получается, размер страницы, номер страницы, поле и порядок сортировки формируют ключ храняния в кэше. Теперь что делать с изменениями. Для этого для ключа каждого блоко формируется префикс. Если данные меняются, то меняется и префикс (следующие обращения к странице в кэше найдены не будут). Это решение было реализовано.

Фронтэнд

Сам не фронтендщик. Использоал JQuery и Bootstrap. В js файлах отправляютя ajax-запросы на rest-api и получают ответ в json.

Docker

Всю связку приложение, mysql и memcached можно запсустить через docker-compose файл. Для приложения контейнер с зависимостями получился громоздким.

Тесты

К сожалению не успел покрыть проект тестами. Не успел разобраться с инструментами (до этого не писал на php). Посмотрел за сколько проходит CRUD запросы. Было около 200мс (это на виртуальной машине, на хосте которой крутились приложения и немного все притормаживло). Момент написания отчета пятница (17.09) вечер. Возможно за выходные покрою тестами и выведу необходимые характеристики железа, зная время отклика на один запрос, количество запросов в секунду аналитическим путем.

Достоинства и недостатки

Это то, что на мой взгляд.

Достоинства:

• Данные кэшируется, последующие запросы к данным после первого обращения извлекаются быстрее
• Добавлены индексы на поля учавствующие в сортровке, чт ускоряет их извлечение
• Приложение использует rest api, можно обращаться с любого клиента, поменять фронтенд

Недостатки:

• Размер страницы жестко закодирован в коде
• Не реализована обработка, если упадет Memcached
• Индекс играет уже обратную роль для операций изменения, удаления и вставки (но предполагается что извлечение данных производится на много чаще)