위키백과:PHP 스크립트 기술 토크
Wikipedia | 이 페이지는 보관 파일입니다.이 페이지의 내용을 편집하지 않습니다.추가 의견은 현재 메인 페이지로 보내주시기 바랍니다. |
간단히 말해서, 이 페이지는 죽은 것이 아닙니까?아직 미결 상태인 것과 수정된 것을 볼 수 없습니다.또한 인트로는 "여기에 버그와 기능 요청을 추가하지 마십시오"라고 말합니다. 대부분의 내용은 기능과 버그에 관한 것입니다.
네, 이 페이지는 죽었습니다.궁금한 사람은 Wikitech-l 메일링 목록으로 직접 이동하거나 메타에 대해 설정해야 합니다.위키피디아 해커가 되는 방법.
버그 수정 및 계획된 기능에 대해 "기술적" 차원에서 논의하는 자리입니다.(새로운 wikitech-l 메일링 목록도 참조하십시오.)
여기에 버그 및 기능 요청을 추가하지 마십시오. 대신 위키백과를 참조하십시오.버그를 보고하는 방법에 대한 자세한 내용은 PHP 스크립트를 참조하십시오.
심각한 버그
가능한 한 빨리 수리해야 하는 것들.
diff가 작동하지 않습니다.
저는 어려움을 겪을 수 없습니다.캐시가 이미 실행 중인 경우 캐시일 수 있습니다.누가 이것 좀 고쳐주세요! -- Magnus Manske
- 네, 캐시 버그입니다.어젯밤에 CVS에 대한 수정 사항을 확인했는데 여기에 언급하는 것을 잊었습니다.(2002/2/8) --브라이언 비버
#영원한 편집 충돌로 끝나는 REDIRECTs
- 제안? -- Magnus Manske
- 저는 여기서 당연한 것을 말하고 있지만, 이는 페이지가 지정된 페이지와 다른 페이지로 리디렉션하려고 하기 때문인 것 같습니다.이 페이지가 존재하지 않는 경우(일반적인 경우) 저장을 클릭하면 페이지가 편집 모드로 전환되어 편집 충돌이 발생합니다.페이지가 존재하는 경우 편집 충돌은 발생하지 않지만 리디렉션이 예상 위치로 이동하지 않습니다(사용자에게 리디렉션되는 Zundark/Old_Talk의 경우:Zundark 하지만 실제로는 사용자에게 도달합니다.Zundark/Old_Talk). --Zundark, 2002년 2월 3일
자원봉사자 모집
이 일들을 해킹하려면 자원봉사자들이 필요합니다!
최근 변경 사항에 대한 보조 편집 마스킹
브리온 비버와 나 자신의 패치로 고칠 수도 있습니다 -- 매그너스 맨스케.
최근 변경 사항("# 변경 사항)" 카운터를 수정합니다.
브리온 비버와 나 자신의 패치로 고칠 수도 있습니다 -- 매그너스 맨스케.
- 방금 cvs(암스테르담 시간 2002/2/400:02)를 찾아봤는데 여전히 $addoriginal 변수를 카운트에 추가하는 것 같습니다.하지만 변화를 세고 있다면 현재 페이지를 세서는 안 되기 때문에 바보 같은 생각이 듭니다.그러니 그냥 $addoriginal을 제거하면 문제가 해결됩니다. -- Jan Hidders (PS)sign-shortcut ~~ 항상 이름과 시간으로 대체하면 좋지 않을까요 :-)
일부 파서 버그 수정
- 특히 <pre> 태그.
- 제거를 대체했습니다.이전 usemod 버전과 더 유사한 동작을 하는 HTML 태그(). 즉, 몇 개의 태그를 금지하는 대신 소수만 허용합니다.따라서 no <span>, <object> 등입니다.하지만 여전히 알려지지 않은 요소/파라미터를 제거할 수 있어야 합니다. 저는 여전히 이런 장난스러운 것들을 쓸 수 있습니다.{이것은 링크가 아닌 '링크'이며 일부 JavaScript 코드를 실행합니다}(2002/02/04 20:48 PST) --Brion VIBBER
- 또한 & 뒤에 엔터티가 될 수 있는 텍스트를 엔터티로 만드는 subParseContents의 줄에 주석을 달았습니다.편집 중에 과도하게 빠져나가는 페이지를 수정하기 위해 넣은 것으로 추정되는데, 그 버그는 이제 사라진 것 같고 엔티티 이름을 쓰는 것만 어렵게 만듭니다.즉, "&"는 단순한 앰퍼샌드가 아니라 앰퍼샌드 뒤에 "amp;"가 와야 합니다. --BV
브레인스토밍
여기에 필요한 솔루션에 대한 아이디어.
PHP 스크립트 속도 향상
- "specialPages.php"를 분해합니다.
이 파일이 상당히 커져 컴파일 시간이 길어지고 있습니다.두 가지 단계를 제안합니다.
- 각 함수에 대해 "special_userlogout.dll"과 같은 페이지를 만듭니다("이 경우 사용자 로그아웃").
- 그런 다음 include 문을 변경하여 필요한 함수만 포함되도록 합니다.이것은 차례로 다른 공유 기능을 포함할 수 있습니다.
저는 이제 이것을 하기 시작했습니다. -- Magnus Manske
- 읽기 전용 페이지 캐싱(Jimbo의 아이디어).
- 까다로울 수 있습니다.보기 환경설정 및 새로 만든 페이지(빨간색/파란색 링크)에 적응해야 합니다.
- 거의 최종적인 '공통' 버전을 캐시할 수 있으며, 링크 색상과 문단 맞춤을 설정하기 위해 정규식을 실행한 다음 헤더/푸터에 삽입할 수 있습니다. 이렇게 하면 적어도 매번 위키 페이지를 구문 분석하는 것을 절약할 수 있습니다.그래도 새 페이지를 처리해야 합니다...가장 간단한 방법은 새로 만든 페이지에서 "이 페이지에 연결" 검사를 실행하고 캐시된 버전의 캐시를 만료하는 것입니다. --Brion VIBBER
취소할게요, CSS는 거기서 잘 할 거예요.어떻게 들립니까?
이것은 <span class="newlinkedge">[</span><ahref="foo" class="newlinkedge">새 링크</a><span class="newlinkedge"><ahref="foo">?</a></span>.
다음 중 하나를 정의합니다.
a.newlink {color: red; } .newlink edge {display: none; } 또는
a.newlink {color: black; 텍스트 장식: none; } .newlinkedge { } 스타일시트에?원하는 경우 "고정"될 수 있지만, 텍스트 부분은 이전 스타일의 대소문자에서 여전히 클릭할 수 있습니다. --Brion VIBB
- (2002/02/03 15:05 PST) 링크 색상, 문단 맞춤, 텍스트/배경 색상에 스타일시트를 사용하도록 CVS 버전을 변경했습니다.(부분적으로 에스페란토 현지화된 인터페이스를 찾을 수 있다면, 내 테스트 서버에서 사용해 보십시오.)스타일을 추가로 변경하려는 경우 변경해야 하는 항목 수를 줄이고 HTML 크기의 페이지 내용을 캐시 가능으로 만들어야 합니다.
제안 캐싱
- cur_cache(MEDIATEXT)라는 이름의 새 필드를 만듭니다(기본적으로 비어 있음).
- 편집 후 페이지를 저장하면 캐시가 지워집니다.
- 페이지를 볼 때,
- 캐시가 X번 사용된 경우 삭제됩니다(최신 적용).
- 캐시 항목에 텍스트가 포함되어 있으며 캐시가 현재 사용자 설정에 맞게 조정되어 표시됩니다.
- 캐시가 비어 있으면 텍스트가 렌더링되고 표시되며 캐시 필드에 저장됩니다.
- 새 페이지가 작성되면 새 페이지에 연결된 모든 페이지의 캐시가 지워집니다.
- 모듈: NUMBEROF에서 Lua 오류가 발생한 페이지가 14행: 매개 변수 1이 누락되었습니다. 템플릿 설명서를 참조하십시오.캐시되지 않음
--마그너스 맨스케
- 페이지를 편집할 때마다 캐시 필드를 업데이트하는 것이 어떻습니까?편집 후에 페이지가 표시되므로 어쨌든 페이지를 구문 분석해야 합니다. -- Jan Hidders PS.짜증나는 건 알지만 서버 CPU 시간을 소비하는 페이지를 먼저 측정해야 한다는 점을 다시 한 번 말씀드려도 될까요?그렇지 않으면 캐싱 구현이 시간과 노력을 낭비하여 코드를 불필요하게 복잡하게 만들 수 있습니다.
- 캐시되지 않은 페이지를 볼 때 내용은 렌더링됩니다.결과를 약간 변경하여 캐시로 저장할 수 있습니다.저장 시 캐시를 생성한다는 것은 특히 이러한 목적을 위해 캐시를 렌더링해야 하므로 리소스가 낭비된다는 것을 의미합니다.또한 캐시가 플러시되면 다음 편집 후까지 페이지가 다시 캐시되지 않습니다.
- 그렇긴 하지만, 우리는 당연히 특별 페이지를 확인하고 속도를 높여야 합니다.나는 이미 (킨다) 모스트 원티드를 캐시했습니다.다른 후보는 고아들이지만, 저는 그것을 어떻게 처리해야 할지 모르겠습니다. 어쨌든, 탈 고아화가 진행되면서 고아들의 목록은 더 짧아질 것이고, 그 페이지의 인기는 떨어질 것입니다.
- 또한 기본 페이지는 볼 때마다 데이터베이스 요청을 실행하여 최신 문서 수를 유지해야 합니다.
- 인터넷에 10MBit로 연결된 이 페이지를 편집하면 위키피디아는 꽤 잘 작동합니다; 저는 미국이 온라인이 되면 이것이 바뀔 것이라는 것을 압니다;) -- Magnus Manske
- 페이지를 저장할 때 캐시 필드를 지우는 것이 현명한 행동일 것입니다(그리고 페이지가 새 페이지인 경우 해당 페이지에 연결되는 모든 페이지의 캐시 필드).그런 다음 페이지가 다시 로드되면(편집된 페이지의 경우 즉시) 빈 캐시가 인식되고 페이지가 다시 렌더링되고 저장됩니다.
- 네, 그런 뜻이었어요.불분명하게 해서 죄송합니다.나는 제안서에 한 줄을 추가했습니다. -- Magnus Manske
- 모든 페이지를 한 번씩 업데이트할 수 있는 안전 장치입니다.필요 없을 수도 있지만, 높은 값으로 설정하면 큰 해를 끼치지 않을 것입니다. -- Magnus Manske
- 메인 페이지까지...그 {{blahblah}}개의 물건들을 실제로 몇 페이지나 사용합니까?우리는 그것들을 포함하는 페이지들을 캐시하지 말아야 합니까? -- 브리온 비버
서버 시간이 걸리는 항목
최근 변경사항 보기는 엄청난 리소스를 소모하고 병목 현상이 되고 있다고 생각합니다.웹 서버와 PHP 스크립트는 일반적으로 빠릅니다. db 액세스가 필요 없는 미리 보기가 빠르기 때문입니다.사이트에서 작업하는 모든 사용자는 몇 분마다 최근 변경사항을 호출합니다.짐보가 기본값을 250페이지에서 50페이지로 변경하자 서버 속도가 눈에 띄게 빨라졌습니다.최근 변경사항을 만들기 위해 전체 큐를 검색한 다음 최신 n개의 변경사항을 정렬하여 제시하는 것으로 보입니다. 그렇죠?이것은 데이터베이스가 증가함에 따라 속도가 느려진다는 것을 의미합니다.이 제안은 어떻습니까? 최근 편집에 대한 정보(페이지 제목, 사용자 이름, 주석, 타임스탬프)만 저장하는 새 테이블 recent_edits를 추가하여 모든 최근 변경 보기에 대해 해당 테이블의 첫 번째 n개 항목만 덤프하면 됩니까?최근_edits는 mysql 테이블이 아니라 가끔 정리되는 목록일 수도 있습니다.또는 준비된 Recent Changes HTML 페이지를 항상 최신 상태로 유지하고 정적으로 제공할 수도 있습니다. 2002년 2월 7일 AxelBoldt
- 저는 이것이 좋은 생각이라고 생각합니다. 결국, 최근 변화의 목록은 로드될 때마다 정확하게 완전히 바뀌지 않습니다. 새로운 것들이 맨 위에 나타나고 오래된 것들은 맨 아래 또는 중간에 관심 범위에서 떨어집니다.제가 오늘 밤에 실행해 보겠습니다.브리온 비버
- 다시 생각해보니, 이것이 정말 필요한 것일까요?표를 제목/id 뿐만 아니라 cur_timestamp로 인덱싱할 수는 없습니까?그러면 데이터베이스는 특정 시점까지 수정되지 않은 모든 항목을 쉽게 무시할 수 있습니다.저는 MySQL 전문가는 아니지만, 이것을 구현하는 방법을 잘 모릅니다(또는 실행할 수 없는 타당한 이유가 있다면).그러나 최근 변경사항의 기본 표시를 캐시하는 것은 충분히 쉬우며 몇 번의 주기를 절약해야 합니다. 변경사항보다 더 많은 보기가 있을 수 있습니다.브리온 비버
(2002/02/07 22:29 PST) Wanted Pages의 새로 고침 사이에 최소 5분의 대기 시간을 추가했습니다(special_wanted pages의 리비전 1.2 참조).php 및 wikiTextEn.php의 1.14).좋은 생각?나쁜 생각?합법적인 사용자에게 영향을 미치지 않아야 하지만 악의적이거나 실수로 새로 고침이 서버를 압도하는 것을 약간 더 어렵게 만듭니다. --Brion VIBBER
위키를 분산시키는 것은 어떻습니까?서로 다른 Wiki 서버가 서로 대화하고 자동 링크를 수행하는 것이 상대적으로 쉬웠다면 속도가 상당히 빨라질 것입니다.저는 위키피디아가 좋은 아이디어라고 생각하고 서버 공간을 제공할 준비가 되어 있습니다(저의 관심사 때문에 가급적 의료적인 부분을 선호합니다).--마티스
- 데이터베이스 운영 및 효율성
- 코드에 mysql_connect()/mysql_close() 쌍이 많이 있습니다. 로드된 페이지에 따라 데이터베이스를 5회에서 12회까지 열고 닫을 수 있습니다.이것은 나에게 과도한 것처럼 보입니다... mysql_connect()는 새 연결을 열지 않습니다. 하나가 열려 있으면 연결이 자동으로 닫힙니다.여러 연결을 열고 닫는 데 드는 오버헤드가 각 페이지에서 필요로 하는 여러 데이터베이스 작업을 실행하는 데 걸리는 전체 시간(초) 동안 하나의 연결을 여는 오버헤드보다 더 나쁘다는 것은 확실합니까?그것들을 꺼내는 것은 제 시험기의 성능에 큰 영향을 미치는 것 같지는 않지만, 저는 작은 데이터베이스를 가지고 있고 저만 그것을 사용하고 있습니다. (사실, 영구적인 연결을 사용하는 것이 이치에 맞을 수도 있습니다.) -- Brion VIBBER (2002/02/06 02:37 PST)
- 여기서 CVS에 접속할 수 없습니다.mysql_close() 행에 대해 의견을 제시하고 Jimbo가 실제로 실행 중인 버전을 업데이트할 때(한 달 정도 후) 어떻게 되는지 확인해 보는 것은 어떨까요?만약 그것이 해결된다면, 우리는 지속적인 연결을 시도할 수 있고, 만약 그렇지 않다면, 우리는 단지 #를 다시 제거할 수 있습니다. --Magnus Manske
- 좋아요, 한다.어떻게 될지 두고 보자꾸나...mwoooh 하하하...또한, 처음 계산할 때 많은 것을 놓쳤습니다. 페이지당 "데이터베이스를 10번에서 21번까지 열고 닫을 수 있습니다."로 수정하십시오.브리온 비버
- 여기서 CVS에 접속할 수 없습니다.mysql_close() 행에 대해 의견을 제시하고 Jimbo가 실제로 실행 중인 버전을 업데이트할 때(한 달 정도 후) 어떻게 되는지 확인해 보는 것은 어떨까요?만약 그것이 해결된다면, 우리는 지속적인 연결을 시도할 수 있고, 만약 그렇지 않다면, 우리는 단지 #를 다시 제거할 수 있습니다. --Magnus Manske
- 코드에 mysql_connect()/mysql_close() 쌍이 많이 있습니다. 로드된 페이지에 따라 데이터베이스를 5회에서 12회까지 열고 닫을 수 있습니다.이것은 나에게 과도한 것처럼 보입니다... mysql_connect()는 새 연결을 열지 않습니다. 하나가 열려 있으면 연결이 자동으로 닫힙니다.여러 연결을 열고 닫는 데 드는 오버헤드가 각 페이지에서 필요로 하는 여러 데이터베이스 작업을 실행하는 데 걸리는 전체 시간(초) 동안 하나의 연결을 여는 오버헤드보다 더 나쁘다는 것은 확실합니까?그것들을 꺼내는 것은 제 시험기의 성능에 큰 영향을 미치는 것 같지는 않지만, 저는 작은 데이터베이스를 가지고 있고 저만 그것을 사용하고 있습니다. (사실, 영구적인 연결을 사용하는 것이 이치에 맞을 수도 있습니다.) -- Brion VIBBER (2002/02/06 02:37 PST)
영구 데이터베이스 연결(mysql_connect 대신 mysql_pconnect)을 사용해야 합니다.동일한 암호와 사용자 이름을 지속적으로 전송하는 것은 의미가 없습니다. mysql_pconnect는 mysql_connect의 더 빠른 드롭인 대체입니다.php가 아파치 모듈로 실행되는 경우에만 속도가 빨라집니다. 제 생각에는 그렇습니다.2002년 8월 2일 액셀 볼트
- 브라우저별 페이지 레이아웃
- 그러나 페이지 레이아웃의 표는 사용자 에이전트가 Internet Explorer인지 여부에 따라 테두리 속성을 설정합니다.이것은 Internet Explorer에서 테이블의 테두리가 얇고 검은색이며 Mozilla에서는 테두리가 없는 이유를 설명합니다.매그너스, 무슨 이유라도 있나요?어떤 경우에도 테이블을 CSS 마크업으로 대체하고 싶습니다. -- Brion VIBBER
- 그 이유는 IE의 얇은 검은색 선이 마음에 들지만, 다른 브라우저들은 그것을 지원하지 않고, 보기 흉하게 보이는 모든 선을 검은색으로 그립니다(해보세요!).변경하는 방법을 알고 있다면, 바로 진행하세요 :) --Magnus Manske
- 완료, 체크인 완료.IE와 Mozilla에서는 약간 다르게 보이지만 IE의 이전 동작과 거의 같습니다.또한 Konqueror 2.2.1에서는 괜찮아 보이지만, 오페라 6에서는 볼 수 있지만(내가 가지고 있는 일부 베타 버전), Netscape 4.x에서는 여전히 표시되지 않습니다. Brion VIBBER 2002/02/04 15:21 PST
- 그 이유는 IE의 얇은 검은색 선이 마음에 들지만, 다른 브라우저들은 그것을 지원하지 않고, 보기 흉하게 보이는 모든 선을 검은색으로 그립니다(해보세요!).변경하는 방법을 알고 있다면, 바로 진행하세요 :) --Magnus Manske
- 그러나 페이지 레이아웃의 표는 사용자 에이전트가 Internet Explorer인지 여부에 따라 테두리 속성을 설정합니다.이것은 Internet Explorer에서 테이블의 테두리가 얇고 검은색이며 Mozilla에서는 테두리가 없는 이유를 설명합니다.매그너스, 무슨 이유라도 있나요?어떤 경우에도 테이블을 CSS 마크업으로 대체하고 싶습니다. -- Brion VIBBER
- 느린 코드 부분 최적화(어디서? 왜?)
- 우리는 정말로 느린 부분이 무엇인지 알고 있습니까?제 직감은 최근 변경 페이지가 가장 느리다는 것입니다. 하지만 하나의 클라이언트에만 서비스를 제공하지만 데이터베이스가 큰 서버에서 실제 측정을 수행할 수 있다면 좋을 것입니다.(큰 SQL 덤프를 가지고 있는 사람이 있습니까?)어쨌든 그렇다고 가정하고 코드를 살펴보니 두 개의 SQL 쿼리를 하나로 결합하면 훨씬 더 최적화될 수 있을 것 같습니다.현재는 데이터베이스에서 훨씬 더 효율적으로 수행할 수 있는 PHP의 JOIN과 GROUP BY를 계산합니다.그러나 이제는 타임스탬프에 숨겨져 있는 당일 그룹화 BY를 수행할 수 있습니다.그래서 이 열을 일 열과 시간 열로 나눕니다.이 작업을 수행할 수 있는 권한이 있습니까? (그러나 먼저 최근 변경사항 페이지가 속도 저하에 중요한 역할을 하는지 여부를 알고 싶습니다.)저는 Magnus가 Apache의 메모리 누수에 대해 말한 것으로 생각했습니다. 그래서 아마도 우리는 먼저 그것을 찾으려고 노력해야 할 것입니다.) - Jan Hidders
- 최근 변경사항 최적화에 대한 (이전의) 제안은 최근 5000개 이상의 변경사항을 포함하는 별도의 테이블로 만드는 것이었습니다.(표에는 RC 관련 데이터만 저장되고 실제 페이지 내용은 저장되지 않습니다.편집 기능으로 간단하게 추가할 수 있으며, 일/주 단위 유지보수로 트리밍이 가능합니다.)이 표를 사용하면 각 RC 페이지가 *전체* DB를 검색하여 가장 최근에 업데이트된 페이지를 찾을 필요가 없습니다. --Clifford Adams
- 그렇지 않습니다. 인덱스를 사용하여 이를 수행합니다.그것이 데이터베이스를 사용하는 전체적인 이유입니다. 그들은 대개 이러한 것들에 매우 영리합니다. :-) 저는 데이터베이스가 여러분을 위해 조인을 하도록 허용하는 것이 종종 성능 향상으로 이어진다는 말을 덧붙이고 싶습니다.제 말이 맞다면 이것이 큰 힘이 될 수 있습니다. -- Jan Hidders (2001/2/5 8:48 GMT+1)
- 하지만 지금은 cur_timestamp에서 인덱스를 작성하지 않고 모든 RecentChanges 요청에 대해 전체 데이터베이스를 검색합니다.그것은 최대한 빨리 고쳐야 합니다.Recent Changes 코드가 SQL join을 사용하여 훨씬 더 우아하게 작성될 수 있다는 것에 동의합니다. 2002년 2월 8일 AxelBoldt
- 그렇지 않습니다. 인덱스를 사용하여 이를 수행합니다.그것이 데이터베이스를 사용하는 전체적인 이유입니다. 그들은 대개 이러한 것들에 매우 영리합니다. :-) 저는 데이터베이스가 여러분을 위해 조인을 하도록 허용하는 것이 종종 성능 향상으로 이어진다는 말을 덧붙이고 싶습니다.제 말이 맞다면 이것이 큰 힘이 될 수 있습니다. -- Jan Hidders (2001/2/5 8:48 GMT+1)
- 최근 변경사항 최적화에 대한 (이전의) 제안은 최근 5000개 이상의 변경사항을 포함하는 별도의 테이블로 만드는 것이었습니다.(표에는 RC 관련 데이터만 저장되고 실제 페이지 내용은 저장되지 않습니다.편집 기능으로 간단하게 추가할 수 있으며, 일/주 단위 유지보수로 트리밍이 가능합니다.)이 표를 사용하면 각 RC 페이지가 *전체* DB를 검색하여 가장 최근에 업데이트된 페이지를 찾을 필요가 없습니다. --Clifford Adams
- 우리는 정말로 느린 부분이 무엇인지 알고 있습니까?제 직감은 최근 변경 페이지가 가장 느리다는 것입니다. 하지만 하나의 클라이언트에만 서비스를 제공하지만 데이터베이스가 큰 서버에서 실제 측정을 수행할 수 있다면 좋을 것입니다.(큰 SQL 덤프를 가지고 있는 사람이 있습니까?)어쨌든 그렇다고 가정하고 코드를 살펴보니 두 개의 SQL 쿼리를 하나로 결합하면 훨씬 더 최적화될 수 있을 것 같습니다.현재는 데이터베이스에서 훨씬 더 효율적으로 수행할 수 있는 PHP의 JOIN과 GROUP BY를 계산합니다.그러나 이제는 타임스탬프에 숨겨져 있는 당일 그룹화 BY를 수행할 수 있습니다.그래서 이 열을 일 열과 시간 열로 나눕니다.이 작업을 수행할 수 있는 권한이 있습니까? (그러나 먼저 최근 변경사항 페이지가 속도 저하에 중요한 역할을 하는지 여부를 알고 싶습니다.)저는 Magnus가 Apache의 메모리 누수에 대해 말한 것으로 생각했습니다. 그래서 아마도 우리는 먼저 그것을 찾으려고 노력해야 할 것입니다.) - Jan Hidders
- 액세스 횟수 기능을 제거합니다("이 페이지는 6번 액세스했습니다").데이터베이스에 대한 엄청난 수의 쓰기 작업이 성능을 저하시킬 수 있다는 느낌이 듭니다.이렇게 하는 훨씬 적은 방법은 별도의 스크립트를 사용하여 Apache 로그 파일을 매일 또는 매시간 처리하는 것입니다. --Clifford Adams
- DB에 모든 액세스를 기록할 수 있는 새로운 통계 모듈을 만드는 것이 좋을 것 같습니다. 로그에 히트를 보내는 대신 apache abelive 모드로 할 수 있습니다. 그리고 히트 카운터에 히트를 사용하여 INSERT Delayed를 사용하여 db 액세스를 정상적으로 유지하는 것이 실시간 통계와 효율성 사이의 좋은 절충점이 될 것입니다.데이터베이스 복제를 추가했다면 멋지고 확장 가능한 야수가 될 것입니다.
- http://www.mysql.com/doc/F/u/Fulltext_Search.html AxelBoldt에 설명된 대로 전체 텍스트 색인과 일치 작업을 사용하면 검색 속도가 빨라질 수 있습니다.
해결된 문제
이러한 정보는 삭제되거나 별도의 "우리가 생각하고 있던 것은 무엇입니까?"로 이동될 수 있습니다.우리가 전에 이것이 깨졌을 때 무엇을 했습니까?" 페이지.
"위키"가 있는 페이지.ptml" 하위 페이지
- 이게 왜 그런지 아는 사람?저는 제 지역 복사본으로 그것을 복제할 수 없었습니다. -- Magnus Manske
- 저는 최근에 이것들을 하나도 보지 못했습니다.$THESCRIPT의 절대 경로를 사용하여 수정되었다고 *생각*합니다. -- Brion VIBBER
130.94.122.xxx 버그
- 이것은 파괴 행위를 은폐할 수 있는 잠재력 때문에 심각합니다.
암호 변경이 작동하지 않음
자세한 내용은 위키백과를 참조하십시오.버그 보고서.이 문제가 해결될 때까지 암호를 변경한 사용자는 로그인할 수 없습니다(나처럼).--사용자:척 스미스
- 이상해요.그것은 제 지역 복사본에서 잘 작동합니다.이전 암호로 로그인을 시도했습니까? -- Magnus Manske
- 2002/2/8 이전에 수정된 것으로 보입니다.브리온 비버
