#php #mongodb #api #slim #restful-architecture
#php #mongodb #API #slim #restful-архитектура
Вопрос:
Моя системная архитектура представляет собой сервер веб-приложений, который запускает стек LAMP с PHP-Slim 3 для использования в качестве API, а также интерфейса веб-приложения. API позволяет как get-запросам извлекать данные, так и сенсорным устройствам отправлять их каждую секунду. На этом же сервере мы запускаем алгоритм обработки, написанный на Python, который выполняется каждые 5 минут для обработки данных за 600 секунд.
MongoDB находится на отдельном сервере со своими собственными ресурсами. В начале с несколькими датчиками производительность была хорошей, как вы могли себе представить. Но со временем, когда индексы растут пропорционально объему данных, а также с увеличением числа датчиков, отправляющих данные, запросы get от интерфейса веб-приложения замедлились до такой степени, что даже отображение графика вызывает большую задержку, которая блокирует отправку данных датчика. Это большая проблема, и ее нужно решить для нас.
Я думал, что веб-приложение, вероятно, нуждается в разделении на 3 компонента — один веб-сервер для POST API, один для веб-приложения и другой для обработки запросов API get. Таким образом, у нас было бы 3 отдельных подключения к серверу MongoDB, и, надеюсь, у нас не было бы негативных последствий блокировки get-запросов при публикации данных.
Мой вопрос в том, как бы мне начать делать это с помощью PHP Slim?
Комментарии:
1. Ну, не похоже, что проблема связана с Slim или может быть решена только с помощью Slim. Вы пробовали кэширование? Например, вы можете кэшировать денормализованные / подготовленные для отображения данные с помощью Redis. И не могли бы вы, пожалуйста, объяснить «алгоритм обработки, написанный на Python, который выполняется каждые 5 минут для обработки данных за 600 секунд»?
2. Я рассмотрю кэширование, потому что мы определенно не делаем этого в настоящее время. Алгоритм обработки берет пакет данных датчиков за последние 600 секунд и выполняет ряд различных преобразований для нормализации данных (следовательно, почему это делается на Python). Он запускается как crontab каждые 5 минут и обрабатывает данные для всех сенсорных устройств, которые были активны за последние 10 минут. Расширение с помощью большего количества датчиков и непрерывного ведения журнала данных приведет меня в область больших данных.
Ответ №1:
Это действительно не проблема slim, это проблема базы данных. Ваше приложение slim, вероятно, просто извлекает данные из БД … что делает узким местом либо время, затраченное на ожидание ответа БД, либо время передачи всех данных, которые будут отправлены из вашей БД в приложение slim.
Попытайтесь выяснить, где находится узкое место. Запустите запрос к БД в командной строке и посмотрите, сколько времени потребуется для локального получения данных … если это МБ данных, то время передачи даже в центре обработки данных будет проблемой…. Я видел, что у дерьмовых контроллеров домена 500 КБ, поэтому даже несколько МБ данных будут заметно медленными.