Trac의 특정 인스턴스가 빠르게 실행되지 않고 큰 지연이 있음을 발견했습니다. 이것은 프로젝트의 시작 시점에 있으므로 Trac에는별로 없다 (플러그인과 SVN에로드 된 코드 제외).Trac의 성능을 향상시키는 방법
설정 정보 : 이것은 WebFaction에서 호스팅하는 SELinux 시스템을 통해 이루어집니다. 아파치 뒤에 있으며 SSL을 통한 연결이 있습니다. 현재 .htpasswd 파일은 액세스를 제어하는 데 사용됩니다.
Trac의 성능을 향상시킬 수있는 방법이 있습니까?
설정에 대해 더 알지 못하면 말하기 어렵지만, Trac이 파이썬 런타임을 메모리에 유지하는 mod_python과 같은 형태로 실행되고 있는지 확인하는 것이 한 가지 쉬운 방법입니다. 그렇지 않으면 모든 HTTP 요청으로 인해 Python이 실행되고 모든 모듈을 가져온 다음 마지막으로 요청을 처리합니다. mod_python (또는 FastCGI, 선호하는 것)을 사용하면 로딩을 제거하고 좋은 물건으로 곧바로 건너 뜁니다.
또한 Trac 데이터베이스가 커지고 사이트를 사용하는 사용자가 늘어남에 따라 기본 SQLite 데이터베이스가 더 이상 사용되지 않을 것입니다. 이 시점에서 데이터베이스를 PostgreSQL 또는 MySQL로 마이그레이션하는 것은 동시 요청을 훨씬 빠르게 처리 할 수 있기 때문에 고려해야합니다.
마지막으로, MySQL 지원은 매우 베타 테스트를 거쳤으며 추천되었습니다. 데이터베이스의 postgres 가져 오기를 시도했지만 마일스톤과 관련된 몇 가지 사항이 누락되었습니다. –
저는 8 개월 동안 MySQL에서 Trac을 실행 해 왔으며 성능이 좋은 것으로 보입니다. 내가 만난 유일한 문제는 Trac과 MySQL 간의 연결이 8 시간 동안 사용되지 않으면 (즉, 야간에) 삭제된다는 것입니다. 이 문제를 해결하기 위해 Trac 홈페이지에 6시에 연결하는 스크립트가 있습니다. –
우리는 FastCGI와 함께 최고의 행운을 얻었습니다. 또 다른 중요한 요소는 인증을 위해서만 https을 사용하는 것이었지만 다른 모든 트래픽에는 http을 사용했습니다. 얼마나 차이가 나는지 정말 놀랐습니다.
두 번째는 FastCGI를 사용하는 것입니다. 배포판에는 아직 설치하지 않았지만 끔찍한 설치가 아니라면 설치하기가 쉽지 않습니다. FCGI를 사용하면 Apache와 Python 사이의 호환성 문제가 발생했습니다. modPython (수정 된 Centos 4.3) –
크롬 파일을 정적으로 검색하고 만료 - 헤더도 도움이 될 수 있습니다. this page 끝 부분을 참조하십시오.
내가
select disctinct name from wiki
5 초 이상 걸리는 경우 것으로 나타났습니다 (예를 들어 때문에이 표에 백만 행 -이 실화는 (우리는)를 작성하는 스크립트를했다), 검색 위키 페이지가 매우 느려지고 2*t*n을 취합니다. 여기서 t은 인용 된 쿼리 (> 5s)의 실행 시간이고 n은 조회 한 페이지에있는 tracwiki 링크 수입니다. 이것은 (하드 코딩 된) 5s 캐시가이 쿼리에 만료되기 때문에 발생합니다. 그것은 trac에 의해 어떤 색이 연결되어야 하는지를 알려주기 위해 사용됩니다. 우리는 값을 30 초로 다시 하드 코드했습니다 (많은 페이지가 필요하므로 매 30 초마다 6-7 초를 기다려야합니다).
문제의 원인이 아닐지 모르지만 문제 일 수 있습니다. Trac 인스턴스의 속도를 높이는 행운을 비네.
내 특별한 문제가 아닙니다. – torial
이 값은 0.12 이후로 고정되어야합니다. –
운영 체제, 웹 서버, 사용 된 프로토콜, 사용 된 인증 체계와 같은 설정에 대한 자세한 정보를 제공 할 수 있습니다. – nosklo
세부 정보가 추가되었습니다. 제안에 감사드립니다. – torial