GAE에서 호스팅되는 일부 사이트를 방문한 결과 매우 느린 것으로 나타났습니다. 많은 사람들이 거의 평소보다로드하는 데 오래 걸립니다.Google App Engine - 속도가 빠름
시간 (초) [YSlow에]
9.9 giftag.com
3.1 hotskills.net
1.9 jeeyo.net
1.5 appspot.com
그것이 Bigtable을 너무 느린 ... 또는 무엇인가, 앱 엔진 클라우드가 너무 느립니다인가요?
YSlow 플러그인을 사용하여이를 측정하고 YSlow가 사이트의 속도가 느린 이유 (교활한 이름이 단서)를 알려줍니다. 예를 들어, gifttag.com의 경우 YSlow는 다음을보고합니다.
이 페이지는 9 개의 외부 Javascript 스크립트를 가지고 있습니다. 그들을 하나로 결합 해보십시오. 이 페이지는 3 개의 외부 스타일 시트를 가지고 있습니다. 하나로 결합 해보십시오. 이 페이지 에는 13 개의 외부 배경 이미지가 있습니다. CSS 스프라이트와 결합 해보십시오.
그래서 'E'등급이 적용됩니다. 사이트의로드 성능이 저하 될 것입니다.
아무 것도 appengine과 아무 관련이 없습니다.
GAE의 데이터 액세스가 밀리 초로 측정 데이터베이스에 비해 초 정도이다. 차이점은 BigTable이 Read Uncommitted의 독점적 인 분리 수준과 편안한 일관성으로 인해 수백만 개의 동시 액세스로 확장된다는 것입니다.
RDBMS는이를 계산할 수 없으며 일관성 보장을 제공 할 수 없습니다. 일부 애플리케이션의 경우 확장성에 대한 강력한 보장이 필요하기 때문에 솔직히 말해서별로 원하지 않습니다.
YSlow는 클라이언트 측 속도 측정 (CSS, 자바 스크립트, 브라우저 렌더링, 이미지로드 등)이기 때문에 서버 측 웹 앱의 속도와 아무 관련이 없습니다. 그러나 다른 측면에서 볼 때 많은 조회수와 트래픽이 발생하지 않으면 App Engine에서 애플리케이션이 느려질 수 있다고 들었습니다. 이렇게하면 App Engine이 파이썬 런타임 환경을 캐시하지 않게되고 (콜드 스타트), 트래픽이 적은 응용 프로그램의 성능에 큰 차이를 만들 수 있습니다.
아니요, gae의 데이터 액세스는 [수십 밀리 초]입니다 (http://code.google.com/status/appengine/detail/datastore/2011/01/27#ae-trust-detail-datastore). - 대기 시간). 그 그래프의 평균은 60ms이지만 클라이언트에서 측정 된 전체 HTTP 요청 지속 시간을 측정하기 때문에 과장됩니다. 서버에서 측정 된 개별 읽기 작업은 10-20ms와 비슷합니다. RDBMS보다 확실히 느리지 만 3 단계가 아니라 한 자리수 (또는 그 미만) 만 가능합니다. – ryan