%EB%A5%BC%20%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94%20Azure%20App%20Service%EC%9D%98%20MySQL%20%EC%86%8D%EB%8F%84%EA%B0%80%20%EB%A7%A4%EC%9A%B0%20%EB%8A%90%EB%A6%BC.png)
Azure App Services와 Azure Database의 연결 속도가 매우 느린 문제를 해결하려고 합니다.
저렴한 OVH 호스팅을 통해 Wordpress로 마이그레이션한 후 TTFB가 300-400ms에서 1500-3000ms로 증가하는 매우 긴 것을 발견했습니다.
문제를 앱 서비스 - 데이터베이스 연결 문제로 좁혔습니다. 문제를 정확히 찾아내기 위해 깨끗한 Wordpress 설치를 만들었습니다. P3 - 플러그인 성능 프로파일러에 따르면 WP를 새로 설치하면 38개의 데이터베이스 쿼리가 생성됩니다.
PHP/MySQL CPU 성능 통계 플러그인을 사용하여 MySql 테스트를 실행했습니다.
- Azure App Service: 20-50db 쿼리/초
- 저렴한 OVH 호스팅: 초당 200개 이상의 DB 쿼리
200 USD/월 Azure 스택이 10 USD OVH보다 약 20배 느리면 문제가 매우 분명하다고 생각합니다. (그러나 초당 ~40 db 쿼리라도 제가 목표로 하는 300ms 정도의 TTFB가 발생할 수 있다는 것을 알았습니다. ).
이 문제를 해결하기 위해 다음 테스트/변경을 시도했습니다.
- 다양한 App Service 계획(개발에서 P2v3까지)
- 다양한 Azure 데이터베이스 서버(가장 저렴한 것부터 ~300 USD/월까지)
- PHP 7.4 및 PHP 8.0
- Apache 및 nginx(php 7/8 변경 시 자동으로 제공됨)
- Azure 데이터베이스 단일 및 유연한 서버
- MySQL 및 MariaDB용 Azure 데이터베이스
- 공용 IP 및 Vnet 통합을 통해 데이터베이스 연결에 대한 앱 서비스
- 정확히 동일한 가용성 영역에 데이터베이스 배치
- SSL 및 SSL이 아닌 앱/데이터베이스 연결
- 데이터베이스 리디렉션mysqlnd_azure
- 연결 지속성을 시도했습니다.
- App Service Docker 컨테이너의 Wordpress
위에 해당사항 없음성능에 큰 변화가 생겼습니다. "작동하는" 유일한 "수정"은 캐시를 활성화하는 것입니다. 캐시에 적중되면 TTFB는 예상대로 약 100ms입니다.
또한 AWS Elastic Beanstalk/RDS 및 Google App Engine/CloudSQL을 벤치마킹했는데 완벽하게 작동했습니다(기본적으로 최대 250ms TTFB). 동일한 Azure 데이터베이스에 연결된 Azure VM(PHP+ Apache)은 정상적으로 작동합니다(<300ms TTFB).
나는 아이디어가 부족합니다. 내가 무엇을 놓치고 있나요? 명확하게 말하면, 저는 한 자릿수 응답 시간이나 최고의 성능을 달성하려고 하는 것이 아닙니다. 깨끗한 WP 설치에는 300ms가 허용됩니다.
답변1
질문에 언급되지 않았으므로 살펴봐야 할 몇 가지 사항입니다.
- 웹앱과 데이터베이스가 동일한 지역에 있는지 확인하세요. 이것은 기본적인 것처럼 보일 수 있지만 이전에 본 적이 있습니다.
- 할 수 있게 하다항상 켜짐Azure App Service 설정에서. 항상 켜짐: 트래픽이 없을 때에도 앱을 계속 로드합니다. Always On이 켜지지 않은 경우(기본값), 들어오는 요청 없이 20분 후에 앱이 언로드됩니다. 언로드된 앱은 준비 시간으로 인해 새 요청에 대한 대기 시간이 길어질 수 있습니다. 언제항상 켜짐켜져 있으면 프런트 엔드 로드 밸런서는 5분마다 애플리케이션 루트에 GET 요청을 보냅니다. 지속적인 핑으로 인해 앱이 언로드되지 않습니다.
- 검토앱 서비스 모범 사례.
답변2
나도 같은 문제가 있습니다. Azure는 매우 느리고 아무것도 작동하지 않나요?
PP_1, 캐시를 활성화한다는 게 무슨 뜻인가요? WP Rocket과 같은 플러그인을 의미합니까?
답변3
여기에도 같은 문제가 있습니다. 웹 SSH를 통해 컨테이너 인스턴스에 연결하는 테스트를 했는데 내가 찾은 것은 PHP가 필요하다는 것입니다.플러그인을 로드하는 데 200-300ms가 소요됩니다.. h 그래서 내 최종 결론은 Azure에 PHP에 문제가 있다는 것입니다.
캐싱 없이(Linux에서 PHP를 사용하여) Azure에서 괜찮은 성능에 도달한 사람이 있는지 매우 궁금합니다.
우리는 페이지를 적극적으로 캐시하도록 NGIX를 재구성하는 시작 스크립트로 앱을 구성했습니다. 마녀는 일부 사이트에서 잘 작동하지만 이상적이지는 않습니다. 이제 캐시된 페이지의 TTFB는 50ms입니다.
답변4
문제는 Azure App Services가 스토리지를 사용하는 방식에 있습니다. 이것이 플러그인을 로드하는 데 시간이 오래 걸리는 이유입니다.
즉, App Services는 Wordpress를 호스팅할 수 없습니다!