위키백과:성능에 대해 걱정하지 마십시오.
Wikipedia: | 이것은 안내 페이지 입니다. 그것은 위키피디아의 정책이나 지침 중 하나가 아니라 위키피디아의 규범, 관습, 기술 또는 실천요강의 어떤 측면을 기술하고자 한다.그것은 다양한 수준의 합의와 조사를 반영할 수 있다. |
 | 이 페이지는 간단히 말해서 서버 성능은 매우 중요하지만, 그들이 무엇을 하고 있는지 알고 있는 sysadmins에 의해 관리된다.성능 문제에 대한 이해를 바탕으로 정책 결정을 내리지 않도록 하십시오. |
사용자로서 사이트 성능에 대해 걱정하지 마십시오.대부분의 경우, 사이트의 서버 속도를 눈에 띄게 높이거나 느리게 하기 위해 당신이 할 수 있는 일은 거의 없다.소프트웨어는 전체적으로 사용자들의 행동이 그것을 많이 늦추는 것을 금지하도록 설계되었다.
위키미디아는 사람들에게 걱정거리를 주기 때문에 그럴 필요가 없다.
사이트 운영과 보관소가 우리의 관심사다.'우리'는 개발팀과 시스템 관리팀을 지칭하지만, 나는 이를 위해 모든 것을 한데 묶는다.만약 백과사전 쓰기, 또는 사전 만들기를 계속하기 위해 필요한 것이 있다면, 그렇게 하라.만약 그것이 부정하다면 우리에게 알려주고, 우리가 도울 수 있는 더 쉬운 방법이 있다면, 우리는 그렇게 할 것이다.
물론 상식을 채택한다.만약 어떤 것이 심각한 문제를 일으킬 수 있다는 것이 명백하다면, 불을 잡고 확인해라.하지만 "the servers, te servers!!!"라고 소리치며 뛰어다니지는 마." 뭔가를 하지 않는다는 핑계로, 그건 바보 같은 짓이야.
Wikimedia는 시스템 관리자 역할을 하기 위해 수많은 IT 전문가를 고용한다. 이러한 직원들은 WMF Wiki를 실행할 수 있는 안정적이고 대응력이 뛰어난 플랫폼을 제공할 책임이 있다.그 플랫폼은 5테라바이트 이상의 RAM과 2,400개 이상의 프로세서 코어를 가진 400개 이상의 서버로 구성된 클러스터를 형성한다.전체 아키텍처와 그 위에서 실행되는 MediaWiki 소프트웨어는 사이트의 성능에 영향을 미치는 편집자의 능력을 최소화하도록 설계되었다.더 중요한 것은 위키미디어 위키를 호스팅하기 위해 MediaWiki를 실행하는 것이 클러스터가 하는 것이다. 따라서 편집자들은 프로젝트의 목표를 더 발전시키기 위해 소프트웨어로 그들이 필요하다고 느끼는 모든 것을 해야 한다.성능은 리디렉션 사용을 피하거나 페이지 간 연결을 중지하거나 편집 전체를 피해야 하는 이유가 아니다.위키피디아의 콘텐츠가 전혀 없다면, 서버들은 가장 잘 할 수 있을 것이지만,[a] 그들의 목적을 달성하고 있지는 않을 것이다.
sysadmins가 성능 문제를 식별하면 이를 해결함
일반적으로 템플릿이나 정책 수준에서 "서버 로드"와 같은 사소한 것에 대해 크게 걱정하지 마십시오.만약 가격이 비싸다면, 우리는 그것을 고치거나 기술 수준에서 제한한다; 그것은 우리의 책임이다.
기술적인 문제로서, 시스템이 사이트에 필요한 만큼 충분히 작동하도록 하는 것은 우리의 책임이다.다시 말해서 정책적인 문제가 아니다.만약 우리가 특정한 것을 제한해야 한다면, 그리고 언제 기술적 조치를 취할 것이다...
"정책"은 가장 극단적인 경우를 제외하고는 서버 부하와 관련이 없어야 한다; 사용자 기반이 필요로 하는 것을 제공하도록 조정된 상태를 유지하는 것이 우리의 일이다.
시스템 관리자는 성능 병목 현상을 쉽게 식별할 수 있는 풍부한 프로파일링, 로깅 및 관리 데이터에 액세스할 수 있다.MediaWiki 소프트웨어의 기능이 클러스터에서 허용할 수 없는 성능을 유발하는 경우 MediaWiki 개발자 또는 sysadmins는 이를 수정하기 위한 적절한 조치를 취한다.성능 문제를 피하기 위해 도입된 제한사항의 예로는 템플릿 포함 제한, 5,000개 이상의 수정본이 있는 페이지 삭제 제한, 2MB의 페이지 최대 크기 등이 있다.
sysadmins에 의해 만들어진 몇몇 치료법은 기술적인 블록이 아니라 '일반적인' 위키 편집이다.sysadmin이 성능 고려 사항으로 인해 on-wiki 변경을 수행하는 경우 이를 되돌리거나 차단하지 마십시오. sysadmin이 변경하도록 지시하는 경우에도 마찬가지로 해당 변경 내용을 들어보십시오.그러한 행동의 과거 예로는 시스템 메시지[dead link] 편집, 사용자 차단, 고사용 템플릿 변경 등이 있다.
편집자는 사이트를 차단할 수 없으며 관리자만 해당 작업을 수행할 수 있음
나는 추측과 편집증에 기초한 템플릿에 대해 "하늘이 무너지고 있다"고 말하며 뛰어다니지 말 것을 일반적인 권고를 했다.
그렇다고 해서 실제 문제가 발견되었을 때 무시되어야 한다는 뜻은 아니다.
현실적이고, 현실적이고, 측정 가능한 문제가 있을 때, 그게 중요해.
몇몇 경우에, sysops가 그 사이트의 속도를 늦추거나 추락시키는 일을 할 수 있다.그러나 이러한 것들은 드물고 일반적으로 걱정할 가치가 없다. 관리자가 악의적으로 할 수 있는 몇 가지 정리하기가 매우 어렵지만 영구적인 데이터 손실이나 고정 불가능한 파손을 초래하는 일을 하는 것은 결코 가능해서는 안 된다.드문 경우라면 조각들을 가지러 들어오는 sysadmins의 지시를 따르라. 그러면 모든 것이 괜찮아질 것이다.분명 똑같은 일을 다시 반복해서는 안 되지만, 비슷한 일을 하는 것을 두려워해서는 안 된다.위키백과를 삭제하려다 혼나는 경우:샌드박스와 사이트 충돌, 같은 페이지를 다시 삭제하려고 하지 말고 삭제할 모든 페이지의 수정사항도 겁나게 세지 마십시오.이것은 위키피디아의 사소한 일시적 둔화보다 훨씬 더 큰 피해를 준다.뭔가 확신이 서지 않으면 #위키메디아-테크 IRC 채널의 sysadmin에게 기분이 좋아지는지 물어봐도 되지만, 일반적으로 그럴 필요는 없다.
편집자들은 여전히 해야 할 역할이 있다.
특히 템플리트 설계 분야에서는 서버 성능 최적화가 중요하며, 영향이 큰 사용자가 자주 한다.별로 어렵지 않다.나도 가끔 해봤지만, 문제의 템플릿과 기사에 대한 지식을 가진 사람들이 하는 것이 가장 좋다.
이 페이지에 있는 어떤 것도 편집자가 성과를 염두에 두어서는 안 되며, 단지 그것이 프로젝트 개발을 제한해서는 안 된다고 말하는 것은 아니다.페이지가 렌더링하는 속도가 특히 느리거나 다른 한계에 부딪히는 경우, 페이지 또는 템플릿과 모듈을 편집하여 더 나은 성능을 발휘하도록 하는 것이 유용하다.이는 로딩 시간과 같은 중요하고 측정 가능한 특성에 기초해야 하며, 여기 저기서 간단히 몇 바이트를 절약하려는 노력이나 헌팅이 없어야 한다.
일부 영역에서는 템플릿 확장 제한, 파서 보고서(페이지 내용 끝 및 편집 미리보기 페이지의 설명에 표시됨) 또는 편집 필터의 프로파일링 데이터와 같이 사용자가 보다 정확하게 성능을 측정할 수 있는 도구를 개발자가 제공했다.이러한 경우에 편집자는 측정 가능한 성능을 개선하기 위해 이러한 도구를 사용할 수 있다.
"성능에 대해 걱정하지 말라"는 사이트 전체의 성능을 말하는데, 서버의 목적은 위키 콘텐츠를 지원하는 것이지, 반대로 위키 콘텐츠를 지원하는 것이 아니다.위키 콘텐츠의 목적은 독자들에게 봉사하는 것이다. 그리고 성능 고려는 확실히 그 과정에서 한 몫을 할 수 있다.바이트 단위의 작은 크기 대신 바이트 단위의 큰 크기의 축소판 그림(예: 20kB JPEG 대신 높은 충실도의 50kB PNG)을 사용하면 페이지 로딩 속도를 확실히 늦출 수 있지만, 그것이 허용 가능한지 여부는 편집 선택이지 개발자나 시스템 관리자가 예방하거나 권장할 만한 것은 아니다.
요컨대
미신이 아니라 과학을 통해 최적화하라.
— Brion Vibber, wikitech-l, 13 January 2011
성능에 미치는 영향을 측정하고 수량화할 수 있는 항목을 사전 예방적으로 최적화하십시오.측정할 수 없는 것이 성능에 미치는 영향에 대해 걱정하지 마십시오. WMF는 사이트 전체의 성능에 대해 걱정할 시스템 관리자를 고용하고 있다.
노트
- ^ 이것은 또한 대부분의 공공 기물 파괴, 편집 전쟁, POV 밀기, 인신공격도 없앨 수 있지만, 아마도 전부는 아닐 것이다.
참고 항목
- 위키백과:기본 페이지 삭제 안 함
- Wikitech 로봇 정책
- MediaWiki 성능 지침은 개발자가 성능에 대해 어떻게 걱정하는지를 설명한다.
- Maxlag 파라미터
