최적화 팁 및 요령

웹 서비스를 최적화해야하지만 시작할 위치를 알지 못합니다. 우리는 GWT, PHP 및 PostgreSQL을 실행 중입니다. 성능 데이터가 최고조에 이르지 못했을 때 주요 최적화가 데이터베이스에서 이루어질 것이라고 추측합니다.최적화 팁 및 요령

DB 구조 조정이나 색인 생성에 대해 알지 못합니다. (실제로 DB를 실제로 알지는 마라.) 모든 포인터는 세 영역 중 하나에서 크게 감사합니다!

출처

2010-02-23 Jonas Byström

항상 측정으로 시작하십시오. 병목 현상이 어디 있는지 알 때까지 무엇을 개선해야할지 모릅니다. "성능 데이터를 들여다 보지 않고도"적절한 호출을하지는 않을 것입니다. 또는 적어도 은 성능이 손상되는 부분을 잘못 추측합니다. 어쩌면 당신은 나를 추측하는 것이 더 낫습니다 :) (물론 코드에 데이터베이스에있을 수도 있습니다 ...)

측정 도구는 다양한 유형의 요청을 얼마나 오래 로그하는 지 확인할 수 있습니다 전체 프로파일 러, 쿼리 분석기 등으로 가져 가십시오. 데이터베이스 측에서 거의 확실하게 EXPLAIN을 사용하여 쿼리 실행 계획을 살펴보고 싶습니다. 그러나 그 전에는 어떤 쿼리가 당신을 아프게하는지 알고 싶을 것입니다. 처음부터 웹 서비스 자체에 대한 요청은 비용이 많이 든다.

출처

2010-02-23 14:04:01

자주 그리고 자주 프로필. 스파이크 솔루션을 만들 때 디자인 타임에 프로파일 링을 시작하십시오. 성능 테스트의 일부로 프로파일 링을 포함하십시오. 프로파일 제작 작업. 하나는 개발 프로세스에서 항상 잠재적 인 "핫스팟"목록을 가져야합니다. –

측정을 돕는 도구가 있다면 그 정도는 큽니다. –

"php profiler"아래의 빠른 검색은 많은 조회수를 제공합니다. 몇 가지 상용 솔루션이있는 것으로 보이며 몇 가지 무료 옵션도 있어야합니다. – TMN

db를 만지기 전에 (그리고 그 전에 병목 현상을 식별하기 위해) best practices from yahoo을 살펴보십시오. 작은 속도 향상을 위해 많은 시간을 보내고 싶지는 않습니다. 일반적으로 링크의 팁을 사용하면 큰 속도 향상을 얻을 수 있습니다.

프론트 엔드를 프로파일 링하려면 page speed을 사용할 수 있습니다.

출처

2010-02-23 14:06:35

나머지 부분에서는 먼저 병목 현상을 확인해야합니다.

마찬가지로 지금까지 DB에 대한 우려가 난 (확인 된 경우에만) 느린 쿼리 속도를

http://www.postgresql.org/docs/8.2/static/sql-createindex.html

CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] name ON table [ USING method ] 
    ({ column | (expression) } [ opclass ] [, ...]) 
    [ WITH (storage_parameter = value [, ... ]) ] 
    [ TABLESPACE tablespace ] 
    [ WHERE predicate ]

일부를 할 수 있는지 확인하십시오 당신의 테이블에 어떤 인덱스를 생성 제안 간다 색인을 사용하지 않을 때 읽기 언제

출처

2010-02-23 14:10:14 used2could

최적화 팁 및 요령

답변

관련 문제