0
내 시스템 아키텍처는 PHP Slim 3과 함께 LAMP 스택을 실행하는 웹 애플리케이션 서버이며 API 및 웹 애플리케이션 프론트 엔드 역할을합니다. API를 사용하면 두 get 요청에서 데이터를 검색 할 수 있지만 매 초마다 센서 장치에서 POST를 수행 할 수 있습니다. 이 동일한 서버에서 Python으로 작성된 처리 알고리즘은 5 분마다 실행되어 600 초 분량의 데이터를 처리합니다.PHP Slim Application MongoDB - 게시물 요청 차단 요청
MongoDB는 자체 자원으로 별도의 서버에 위치합니다. 처음에는 센서가 거의 없었으므로 성능은 좋았습니다. 그러나 데이터 양에 비례하여 색인이 증가하고 데이터를 게시하는 센서의 수가 증가함에 따라 웹 응용 프로그램 프론트 엔드의 get 요청은 그래프 표시조차도 큰 지연을 유발하는 지점까지 느려졌습니다 센서 데이터의 게시. 이것은 큰 문제이며 우리를 위해 해결되어야합니다.
필자는 웹 애플리케이션이 POST API를위한 하나의 웹 서버, 웹 애플리케이션을위한 하나의 웹 서버, API 요청을 처리하는 다른 하나의 세 가지 컴포넌트로 분할해야한다고 생각 해왔다. 그런 식으로 우리는 MongoDB 서버에 3 개의 개별 연결을 할 수 있으며 잘하면 데이터 게시에 대한 요청을 얻는 데 방해가되지 않을 것입니다.
제 질문은 PHP Slim을 사용하여 어떻게 시작합니까?
글쎄, 문제는 슬림과 같지 않거나 슬림만으로 해결 될 수 있습니다. 캐싱을 시도 했습니까? 예를 들어 Redis를 사용하여 디스플레이 데이터에 대해 비정규 화/준비를 캐싱 할 수 있습니다. 그리고 "5 분마다 실행하여 600 초 분량의 데이터를 처리하는 Python으로 작성된 알고리즘 처리"를 설명해 주시겠습니까? –
캐싱에 대해 살펴 보겠습니다. 현재이 작업을 확실히 수행하고 있지 않기 때문입니다. 처리 알고리즘은 마지막 600 개의 센서 데이터의 배치를 취하고 데이터를 정규화하기 위해 다양한 변형을 수행합니다 (따라서 이것이 파이썬에서 수행되는 이유). 5 분마다 crontab으로 실행되며 지난 10 분 동안 생방송 된 모든 센서 장치에 대한 데이터를 처리했습니다. 더 많은 센서와 지속적인 데이터 로깅으로 확장하면 큰 데이터 영역으로 이동하게됩니다. – ugotchi