최근 1C-Bitrix에서 온라인 상점을 운영하기 위한 전용 서버를 설정하는 데 도움을 요청 받았습니다. 요청 이유는 사이트 운영이 느리기 때문입니다.
우리는 사이트를 살펴보았습니다. 실제로 일부 페이지는 로드하는 데 1분 이상 걸립니다!!! 사이트를 보다가 가장 먼저 떠오른 것은 다른 개발자가 개발한 컴포넌트의 최적이 아닌 성능이었습니다. 하지만 같은 금액은 아니죠...

초기 데이터: Xeon 서버 - 2GB 메모리, RAID. 운영체제 - FreeBSD. 버스 - 비즈니스.

글쎄, 어떻게든 상황을 바로잡도록 노력해보자...
이 기사는 모듈 작업에 대한 지침이 아니라 모듈을 사용하는 실제 사례임을 즉시 예약하겠습니다. 어쩌면 누군가에게 유용할 수도 있습니다.

감사 후 다음과 같은 주요 문제가 확인되었습니다.
1. 서버에 PHP 가속기를 설치해야 합니다.
2. /price/ 페이지에서 "nvisions:menu.sections" 구성 요소에 큰 문제가 있습니다. 데이터베이스에 요청이 생성되어 거의 1분 동안 처리됩니다. 이것이 페이지 로딩 시간이 길어지는 주된 이유입니다. , 서버에 큰 부하가 걸립니다.
3. 데이터베이스가 느리게 작동합니다(초당 687개의 쓰기 요청이 매우 적음). 문제는 서버 구성에 있을 수 있습니다. 테이블을 InnoDB로 변환하고 InnoDB를 구성해야 합니다.
4. 파일 시스템이 그다지 빠르지 않습니다. 이는 서버의 하드웨어 기능(예: RAID) 때문일 수 있지만 원칙적으로 사이트는 이 속도에서 잘 작동해야 합니다.
5. 사이트 템플릿에 문제가 있습니다(링크가 존재하지 않음). 이를 제거해야 합니다. 리소스가 많이 필요합니다.
6. 서버에서 2단계 아키텍처를 구성해야 합니다(nginx를 통해 정적 콘텐츠 제공). 이렇게 하면 Apache 서버의 로드가 크게 줄어들고 로드 중 메모리 소비가 안정화되므로 작업 속도가 빨라지고 서버의 안정성이 향상됩니다. 프로젝트 전체.

1C-Bitrix 성능 모듈의 정보를 분석해 보겠습니다.

그림은 데이터베이스 서버의 문제를 명확하게 보여줍니다. 설정이 최적이 아닐 가능성이 높습니다. 전용 서버.
파일 작업 횟수도 의심스러울 정도로 적습니다.


/price/index.php 페이지의 코드 또는 구성요소에 명백한 문제가 있습니다.
/bitrix/urlrewrite.php에 대한 생성 시간이 의심스러울 정도로 길어졌습니다. 자세히 살펴보세요.

예, 이것이 문제의 원인입니다. 템플릿에 존재하지 않는 이미지에 대한 링크가 포함되어 있으며 이로 인해 404 오류가 생성되고 Apache가 이 오류를 처리하고 본격적인 페이지를 생성하게 됩니다.

동일한 문제는 문제가 있는 템플릿과 관련된 사이트의 모든 페이지에 영향을 미칩니다.


페이지에 문제가 있는 구성 요소는 다음과 같습니다.


메뉴 구성 요소의 캐싱이 비활성화되었습니다.
페이지 요약:

자, 여기 빠른 분석이 있습니다. 성능 모듈이 "문제가 있는 곳"을 알려주는 것이 얼마나 편리한가요? 문제 해결을 시작해 보겠습니다.

우리는 링크가 있는 사진을 추가했습니다. 단지 사진만 추가했을 뿐 링크를 제거하지는 않았습니다. 왜냐하면... 타사 구성 요소를 포함하여 많은 링크가 있었습니다. 또한 이 페이지에서는 문제가 있는 타사 구성 요소(nsvision:menu.sections)를 비활성화했습니다. 그 목적은 명확하지 않습니다. (연결을 끊은 후 외부적으로는 아무것도 변경되지 않았습니다)
결과:


Urlrewrite.php는 이제 모든 적중에서 호출되지 않습니다.



보시다시피 작업 속도가 2배(!) 빨라졌습니다.

계속 진행해 봅시다:
가속기 설치. 여기서는 가속기 설치 방법을 설명하지 않겠습니다. 왜냐하면... 필요한 경우 이 정보는 언제든지 인터넷에서 찾을 수 있습니다.







eAccelerator 설치 후 결과: 생산성이 2배 더 향상되었습니다.

계속 진행해 봅시다: 데이터베이스 최적화(InnoDB로 전송 및 설정 최적화)


성능 모듈 테스트에서 볼 수 있듯이 데이터베이스 속도가 대폭 향상되었습니다.
일반적으로 데이터베이스 최적화 이후의 전반적인 성능은 파일 시스템의 느린 작동으로 인해 변경되지 않았습니다.

업데이트:
성능 모듈 권장 사항.
모듈의 권장 사항에 따라 "open_basedir" 매개변수를 비활성화합니다. 서버는 우리 프로젝트에만 사용되므로 보안 전체가 손상되지는 않습니다.

결과:

그들이 말하는 결과는 사용 가능합니다.

남은 것은 "비뚤어진" 구성 요소를 다시 작성하는 것뿐입니다. 그러면 프로젝트가 성공할 것입니다.

또한 nginx를 Apache용 프록시 서버로 설치하고 구성했습니다. 사진은 안담기 때문에... 숫자는 거의 변하지 않았습니다. 그러나 주관적인 평가에 따르면 이제 페이지 로드 속도가 몇 배 더 빨라졌습니다.

템플릿을 생성하는 데는 여전히 꽤 오랜 시간이 걸립니다(생성 시간은 시스템 커널과 거의 동일합니다). 이전 개발자가 코드를 최적으로 작성하지 않은 것 같습니다. 시간도 없고, 예산도 없고, 다른 사람의 코드를 분석하고 싶은 마음도 없습니다. 코드를 처음부터 작성하는 것이 더 쉽고 빠르며 저렴합니다.

일반적으로: Performance 모듈은 프로젝트와 서버의 작동을 디버깅하는 데 매우 유용하고 편리한 도구입니다. 개발자 여러분께 감사드립니다.

추신 개인적으로 저는 Linux 작업 경험이 거의 없습니다. 저는 처음으로 FreeBSD를 자세히 알게 되었습니다. 일부 소프트웨어를 설치한 후 구성 파일이 완전히 비어 있다는 사실에 놀랐습니다(예: MySQL). "포트"를 통해 소프트웨어를 쉽게 설치할 수 있다는 점에 만족했습니다.

", 방향 "데이터 전송 시스템".

WAN 최적화의 기술적인 복잡성을 다루기 전에 그것이 무엇인지, 그리고 무엇을 위한 것인지 알아봅시다.

최근에는 기업이 전 세계에 처리 센터를 분산시키는 분산형 컴퓨팅 모델로 IT 구조가 이동하는 것이 분명해졌습니다. 결과적으로 기업 데이터 센터(DC) 외부에 저장되는 데이터의 양과 IT 리소스의 수가 증가했으며 이제 부서장은 IT 인프라를 통합할 방법을 찾고 있습니다. 기업은 인프라 복잡성 감소, 비용 절감, 리소스 활용도 향상, 데이터 보호 측면에서 통합이 가져오는 이점을 깨달았습니다.

리소스와 데이터를 중앙 집중화하면 위에 설명된 이점이 입증되지만, IT 인프라를 최적화하려는 조직이 염두에 두어야 할 다양한 함정이 있습니다. 그들이 직면하게 될 문제 중 하나는 애플리케이션 성능이 느려지는 것입니다. 분산 컴퓨팅 모델의 인기는 최대 성능을 보장하기 위해 IT 리소스를 분산 네트워크 사용자와 최대한 가깝게 유지해야 하는 필요성에 의해 크게 주도되었습니다. 중앙 위치에 서버를 통합하면 리소스 할당 패턴이 바뀌므로 많은 응용 프로그램의 성능이 저하됩니다.

문제를 해결하기 위해 조직에서는 응답 시간을 줄이기 위해 WAN 링크의 용량을 확장하고 있습니다. 그런 다음 채널을 통한 데이터 전송의 큰 지연과 WAN 작업에 비효율적인 프로토콜 사용에 문제가 있기 때문에 채널 확장이 애플리케이션 속도에 거의 영향을 미치지 않거나 최소한으로 영향을 미친다는 사실을 발견했습니다. 또한 모스크바 외부로 대역폭을 확장하는 것은 전체적으로 비용 효율적이지 않을 수 있습니다. 그리고 바로 이러한 작업을 위해 WAN 채널 최적화 장비가 사용됩니다.

전 세계적으로 이러한 WAN 최적화 솔루션은 여러 가지 방법으로 조직의 비용을 절감할 수 있습니다.

통신 채널 대역폭 비용을 줄입니다. 실제로 조직은 추가 대역폭을 구매하지 않고도 작업을 수행할 수 있습니다. 이는 많은 기업이 WAN 최적화 프로그램을 구현하기 위한 프로젝트를 시작할 때 핵심 조건입니다.

데이터 센터의 인프라를 통합합니다. 기업은 성능 및 관리 효율성의 손실 없이 원격 사무실에서 IT 인프라(파일 및 메일 서버, 소프트웨어 배포 서버, SharePoint 포털, 테이프 드라이브 등)의 상당 부분을 제거할 수 있습니다.

원격 사무실 인프라를 단순화합니다. 일부 제조업체는 사용자가 데이터 센터 통합 이후 남은 일부 서비스(예: 인쇄 서버, DHCP 서버, 파일 서비스)를 최적화 장치에서 직접 호스팅할 수 있도록 장치에 소프트웨어 플랫폼을 제공합니다. 이를 통해 운영 비용을 더욱 절감할 수 있습니다.

WAN 최적화란 무엇입니까? 네트워크 애플리케이션의 기능을 최적화하기 위한 솔루션은 클라이언트-서버 아키텍처와 네트워크 애플리케이션의 세션 원리를 사용합니다. 주요 임무는 애플리케이션 세션을 최적화하는 것입니다. 기본적으로 회사의 중앙 및 각 지역(로컬) 사무소에 설치된 애플리케이션의 성능을 향상시키기 위한 장치 세트입니다. 이들은 모든 트래픽을 자체적으로 전달하여 애플리케이션 작업 세션을 "가로채기"하고 최적화합니다.

긴 WAN 채널을 통한 트래픽 전송 최적화 분야의 솔루션을 제공하는 제조업체가 많이 있습니다. 그 중 러시아 시장에서 가장 유명한 제품으로는 Riverbed(SteelHead 제품 포함), Cisco(WAAS 제품), Juniper(WXC 제품) 및 BlueCoat(ProxySG 제품)가 있습니다.

그들이 제공하는 장비를 최적화하는 프로세스는 데이터 압축, 캐싱, TCP 프로토콜 최적화 및 비즈니스 애플리케이션 자체의 운영 논리 최적화를 포함하는 거의 동일한 메커니즘을 기반으로 합니다.

고려 중인 모든 애플리케이션 최적화 메커니즘은 세션 분할을 사용하여 클라이언트와 서버 간을 최적화 장치와 워크스테이션 간, WAN 네트워크를 통한 장치 간, 최적화 장치와 데이터 센터(서버) 간 세 개의 세그먼트로 나눕니다. 첫 번째 및 세 번째 세그먼트에서는 세션이 LAN을 통해 실행되며 TCP 프로토콜의 단점은 애플리케이션 대기 시간에 영향을 미치지 않습니다. 두 번째 세그먼트는 TCP 속도를 조정하여 최적화됩니다. 결과적으로 WAN을 통해 트래픽을 전송할 때의 지연 및 애플리케이션 응답 시간 측면에서 필요한 최소값이 보장됩니다. 어떤 형태로든 각 옵티마이저 제조업체의 결정에 기초가 되는 메커니즘을 살펴보겠습니다.

압축 메커니즘단위 시간당 정보 전송의 정보 내용을 늘려 데이터 전송 속도를 높일 수 있습니다. 대부분의 경우 네트워크를 통해 전송되는 데이터는 최적이 아닌 형식으로 제공되며 용량이 비합리적으로 큽니다. 이제 정보를 텍스트 형식으로 표시하기 위한 XML 또는 기타 언어와 같은 애플리케이션 개발에 적극적으로 사용하면 데이터 표현에 대해 걱정할 필요가 없습니다. 이는 개발 속도와 용이성을 높이지만 동시에 본질적으로 구조화되지 않은 데이터가 네트워크를 통해 전송되어 트래픽에 많은 양의 중복이 발생하게 됩니다.

트래픽 압축은 이러한 단점을 제거합니다. 애플리케이션 최적화 엔진은 무손실 데이터 압축 알고리즘(예: Lempel-Ziv) 및 중복 블록 제거 알고리즘을 사용합니다. 이 두 가지 알고리즘의 조합을 통해 최고 수준의 무손실 정보 압축을 달성할 수 있으므로 상대적으로 낮은 속도의 채널에서도 정보의 빠른 전송이 보장됩니다.

어떤 형태로든 압축 기능은 거의 모든 최신 라우터에서 찾아볼 수 있으며, 실제로 이것이 최신 최적화 프로그램의 여정이 시작된 곳입니다. 종종 네트워크 관리자는 이것이 악명 높은 최적화라고 믿고 관리자에게 특별한 장치를 구입할 필요가 없다고 확신합니다. 그리고 나중에 살펴보겠지만 이것이 바로 그들이 틀렸던 부분입니다.

캐싱 메커니즘전송되는 트래픽의 양을 줄이는 데에도 도움이 됩니다. 분산 네트워크에서는 회사의 모든 직원이 동일한 데이터를 전송해야 하는 상황이 자주 발생합니다. 예를 들어, 소프트웨어 제품이나 바이러스 백신 소프트웨어 데이터베이스를 업데이트할 때 회사 경영진, 멀티미디어 파일 및 교육 프로그램, 공공 문서 라이브러리의 요청을 전송할 때. 최적화 장치를 사용하면 이 정보를 캐시할 수 있습니다. 즉, WAN을 통해 한 번 전송된 다음 원격 글로벌 리소스가 아닌 로컬로(가장 가까운 최적화 장치의 하드 드라이브에서) 각 사용자에게 제공됩니다.

기존 캐싱 장치와의 중요한 차이점은 최적화 프로그램이 정보를 부분/블록으로 나누어 하드 드라이브에 저장한다는 사실입니다. 새로 전송된 파일의 일부 정보를 변경하면(예: 슬라이드나 그림을 문서에 삽입하는 경우) 전체 파일이 아니라 해당 변경 사항만 전송된다는 관점에서 보면 이는 흥미로울 수 있습니다. . 전송된 정보를 블록으로 동적으로 나누고 변경 사항을 추적하는 메커니즘은 독점적이며 공개 대상이 아닙니다. 작업의 특징에 대해 이야기하면 제조업체는 두 가지 접근 방식을 사용합니다. 첫 번째 특징은 통일입니다. 하나의 파일을 다른 분기로 전송할 때 모든 원격 최적화 장치에 대한 중앙 최적화 프로그램에는 파일 복사본 하나만 저장됩니다. 두 번째 경우에는 원격 사무실(원격 최적화 프로그램) 수에 비례하여 하드 디스크 공간을 동적으로 분할하고, 하나의 파일을 모든 지점으로 전송하면 유사한 복사본이 "담당"하는 각 하드 디스크 세그먼트에 반영됩니다. 그 지점.

분명히 캐싱 메커니즘은 압축 메커니즘과 함께 작동합니다. 최적화 제조업체가 최적화 수준이 150-200X에 도달할 수 있는 아름다운 그래프를 보여주는 것은 이 두 가지 메커니즘 덕분입니다. 동일한 대용량 데이터 파일을 여러 번 전송할 때 동일한 데이터를 얻을 수 있었습니다. 첫 번째 전송 후 파일이 장치 캐시에 저장되고 하드 드라이브의 파일 위치를 가리키는 킬로바이트의 링크만 전송되었기 때문입니다. 여기서 논리적인 질문이 즉시 발생합니다. 하드 드라이브의 용량은 얼마이며 외부 스토리지를 최적화 프로그램에 연결할 수 있습니까? 일부 제조업체에서는 이러한 종류의 장비가 등장할 가능성을 언급한 적이 있습니다(그러나 이미 데이터 센터 설치 전용으로 설계되었습니다).

TCP 최적화 메커니즘운송 수준에서 일하십시오. 이는 옵티마이저 제조업체가 더 높은 수준(애플리케이션)으로 "상승"하기 시작하기 전의 주요 "전장"입니다. TCP 전송 프로토콜은 1980년에 개발되었으며 오늘날 큰 변화를 겪지 않았지만 데이터 전송 기술은 크게 변했습니다. 패킷이 손실되면 표준 TCP 프로토콜은 속도를 거의 절반으로 급격하게 감소시키며 이후 이 수준의 증가는 선형적으로 작은 단계로 발생합니다. 따라서 상대적으로 작은 수준의 패킷 손실(손실의 2~3%는 정상적인 것으로 간주)이라도 네트워크 속도의 빈번하고 급격한 손실로 이어집니다.

최적화된 TCP 프로토콜은 손실이 발생하면 속도를 2배가 아닌 몇 퍼센트만 감소시키며, 단일 패킷 손실에는 속도가 아주 약간 감소합니다. 네트워크 애플리케이션의 기능을 최적화하는 솔루션은 주로 정보 전송 속도를 높이는 것으로 나타났습니다. TCP 프로토콜의 향상된 작동 절차를 통해 데이터 전송 채널의 전체 대역폭을 최대한 활용할 수 있습니다.

애플리케이션 수준 최적화 메커니즘 WAN 채널을 통해 비즈니스 애플리케이션 자체의 가속화를 제공합니다. 불행히도 완벽과는 거리가 먼 인기 제품의 일부 프로토콜 구현입니다. 특히 Microsoft 네트워크에서 활발히 사용되는 CIFS(Common Internet File System) 프로토콜은 과도한 양의 서비스 메시지(배달 확인, 장치 준비 등)를 생성합니다. 로컬 네트워크에서는 이러한 초과로 인해 응답 시간이 크게 지연되지 않지만 분산 네트워크에서는 심각해집니다. 최적화 장치는 WAN을 통해 전송하지 않고 중요하지 않은 메시지의 대부분을 로컬에서 처리할 수 있으므로 트래픽 양을 줄이고 네트워크 인쇄, 파일 서비스 액세스 등과 같은 다양한 네트워크 애플리케이션 기능의 응답 시간을 줄일 수 있습니다. 실제로 오늘날 제조업체들이 경쟁하고 있는 곳은 바로 이 분야입니다. 가장 자주 최적화되는 프로토콜에는 CIFS, NFS, MAPI, 비디오, HTTP, SSL 및 Windows 인쇄가 포함됩니다. 이 "신사 세트"는 거의 모든 제조업체의 포트폴리오에 있지만 다양한 방식으로 최적화되어 있습니다.

위의 모든 것에서 소스에서 수신자로의 트래픽은 최소 두 개의 최적화 장치를 통과하고 각 장치에서 애플리케이션까지 처리됩니다.

모든 최적화 프로그램이 TCP 기반 애플리케이션에서 작동한다는 것을 추측하는 것은 어렵지 않습니다. 즉, 나머지 트래픽은 최적화 없이 통과된다는 의미입니다. 암호화된 트래픽에 대해서도 마찬가지입니다. SSL은 예외일 수 있습니다. 많은 최적화 프로그램이 세션을 "중단"하고 트래픽을 최적화한 후 다시 암호화할 수 있습니다.

통신 사업자의 비용을 절감하려는 분산 구조를 가진 회사는 이러한 솔루션에 관심을 가질 수 있습니다. 이는 메가바이트당 관세를 사용하는 경우(효과는 명백함)와 무제한 요금제(저속 요금제로 전환)의 경우 모두에서 나타날 수 있습니다. 오늘날 아마도 이것이 그러한 장치를 사용하는 가장 흥미로운 목적일 것입니다. 그다지 명확하지도 투명하지도 않은 다른 보너스로는 서버 통합, 원격 사무실의 IT 직원 수 감소, 애플리케이션 속도 증가로 인한 생산성 향상 등이 있습니다.

옵티마이저에 대한 관심을 끌기 위해 제조업체는 랩톱에 특수 소프트웨어를 설치하고 원격 사무실에 하나의 옵티마이저를 기반으로 가상 서버를 설치하는 기능을 통해 모바일 직원의 작업을 최적화할 수 있는 기회도 제공합니다. 랩톱용 소프트웨어는 코드가 최적화 프로그램 자체의 소프트웨어와 유사합니다. 노트북은 최적화 프로그램처럼 됩니다.

분산된 구조를 가진 기업 외에도 기업에 최적화 서비스(예: 임대)를 제공할 수 있는 운영자에게도 이 솔루션이 관심을 가질 수 있습니다. 이러한 서비스는 유럽에서 인기를 얻고 있습니다.

물론 가장 일반적인 최적화 솔루션은 Cisco WAAS입니다. 좋은 공급업체 마케팅, 좋은 솔루션 및 개발 전략이 제 역할을 합니다. 저렴하고 안정적인 WAVE 시리즈의 등장으로 Cisco의 입지는 더욱 확고해졌습니다.

주니퍼의 WXC 솔루션은 모든 트래픽이 UDP 터널로 패키징된다는 점에서 다릅니다. 모든 트래픽에 대해 최적화가 이루어집니다. 이 접근 방식에는 확실히 장점이 있습니다. 전체 트래픽에 대해 상당히 높은 "병원 평균" 최적화 값을 포함하겠습니다(대규모 고객 한 명을 대상으로 한 테스트 기준).

리버베드는 러시아에 온 지 얼마 되지 않았지만 파트너 네트워크를 적극적으로 개발하고 있습니다. 이는 경쟁 솔루션(예: 유능한 캐싱 메커니즘, 애플리케이션 최적화)에 비해 상당한 이점을 갖고 있지만 솔루션의 높은 가격으로 인해 여전히 인기가 높아지는 데 방해가 되고 있습니다.

위의 모든 내용을 요약하면 WAN 최적화는 비즈니스에 매우 투명하고 흥미로운 솔루션이지만 안타깝게도 아직 러시아 기업에서는 많은 수요를 받지 못했다는 점에 주목하고 싶습니다. 구현을 기반으로 트래픽을 평균 2~3.5배 줄이고 애플리케이션 응답 속도를 대폭 향상시킬 수 있었습니다. 예를 들어, 위성 회선을 사용하는 고객 중 한 명은 한 달 동안 테스트하는 동안 약 20시간의 응답 시간을 절약했습니다. 우리 회사의 경우 이 솔루션을 구현함으로써 네트워크 트래픽 비용을 두 배로 절약할 수 있을 뿐만 아니라 기업 애플리케이션의 속도를 평균 1.7배 높일 수 있었습니다. 동시에 프로젝트에 대한 투자 수익은 단 3개월에 불과했습니다.

어쨌든 관심이 있으시면 먼저 약 한 달 동안 솔루션을 테스트하는 것이 가장 좋으며 이러한 테스트 결과를 통해서만 특정 네트워크와 관련하여 옵티마이저 구현이 얼마나 효과적인지 말할 수 있습니다. 솔루션을 개발하고 테스트 및 설치를 수행하려면 숙련된 시스템 통합자를 참여시키는 것이 가장 좋습니다.

효과적인 SEO는 사이트의 기술적 최적화에서 단 한 번의 성가신 실수로 인해 방해를 받을 수 있지만 이로 인해 검색 엔진 로봇이 리소스를 올바르게 색인화할 수 없고 사이트의 구조를 이해할 수 없으며 사용자는 필요한 정보를 찾지 못합니다. 이 모든 것이 결국 사이트 순위를 낮추게 됩니다.

기술적 웹사이트 최적화는 검색 엔진 로봇과의 상호 작용을 개선하기 위해 리소스의 기술적 측면을 조정하는 것을 목표로 하는 일련의 조치입니다. 기술 최적화를 통해 사이트 페이지의 가장 빠르고 완전한 색인을 생성할 수 있습니다.

5가지 주요 기술 최적화 매개변수

1. Robots.txt 파일

robots.txt 파일은 각 리소스의 루트 디렉터리에 포함되어야 한다는 점에 유의하는 것이 중요합니다. 이는 PS 로봇이 사이트를 방문할 때 액세스하는 첫 번째 파일이며 해당 지침이 저장됩니다.

이 파일은 사이트의 색인 매개변수, 즉 검색 데이터베이스에 포함되어야 하는 페이지와 제외되어야 하는 페이지를 지정합니다. 또한 모든 검색 엔진 로봇에 대해 동시에 지시문을 지정할 수도 있고 각 검색 엔진의 로봇에 대해 개별적으로 지시문을 지정할 수도 있습니다. Yandex 웹마스터 도움말 사이트에서 이 파일을 컴파일하고 설정하는 방법에 대해 자세히 알아볼 수 있습니다.

Yandex.Webmaster 서비스에서 파일을 확인할 수 있습니다., 메뉴 항목 "robots.txt 분석"(https://webmaster.yandex.ru/robots.xml).

2. 사이트맵 - 사이트맵

사이트 맵은 리소스 페이지 중 하나이며 정보가 일반 책의 내용과 유사합니다. 이 페이지는 탐색 요소로 사용됩니다. 사이트 맵에는 리소스에 게시된 섹션 및/또는 모든 페이지의 전체 목록이 포함되어 있습니다.

사용자가 정보를 빠르고 쉽게 찾으려면 HTML 사이트맵이 필요하며, 사이트 색인 생성을 개선하려면 검색 엔진에 XML이 필요합니다.

사이트 맵의 도움으로 검색 로봇은 전체 구조를 확인하고 새 페이지의 색인을 더 빠르게 생성합니다.

사이트맵 확인하기(https://webmaster.yandex.ru/sitemaptest.xml)

.html 형식의 올바른 사이트맵 예:

3. 리디렉션(리디렉션)

리디렉션은 웹사이트 방문자를 한 페이지에서 다른 페이지로 리디렉션하는 데 사용됩니다. 리디렉션이 필요한 이유에 대한 많은 예가 있습니다.

1. 사이트의 도메인 이름을 변경합니다.
2. 합판 거울. 많은 사이트에는 주소에 www가 포함된 도메인에서 www가 없는 도메인으로 또는 그 반대로 구성된 301 리디렉션이 없습니다.

리디렉션은 .htaccess 파일에 입력해야 합니다. 검색 엔진은 site.ru와 www.site.ru를 서로 다른 사이트로 간주할 수 있으므로 결과에 중복된 내용이 나타날 수 있습니다. 이로 인해 검색 결과 순위 등이 어려워집니다.

기본 리디렉션 상태 코드:

• 300 - 다중 선택(다양한 옵션 중에서 선택할 수 있음);
• 301 - 영구적으로 이동됨(영원히 이동됨)
• 302 - 임시 리디렉션;
• 303 - 기타 참조(요청된 리소스는 다른 주소에서 찾을 수 있음)
• 304 - 수정되지 않음(내용이 변경되지 않았습니다. 그림, 스타일 시트 등이 될 수 있음)
• 305 - 프록시 사용(액세스는 프록시를 통해 이루어져야 함)
• 306 - 사용되지 않음(사용되지 않음)

페이지 응답을 결정하는 데 유용한 서비스: http://www.bertal.ru/

4. URL 페이지 보기 사용자 정의

모든 페이지의 주소가 일치하는지 확인하려면 사이트를 확인하는 것이 중요합니다. 예를 들어 사이트 전체의 페이지에는 닫는 슬래시가 있어야 합니다( http://site.ru/katalog/ 및 http://site.ru/products/ ). 일부 페이지가 http://site.ru/katalog처럼 보이고 일부 페이지가 http://site.ru/products/처럼 보인다면 이는 잘못된 것입니다.

사이트맵을 만든 후 내부 리소스 페이지의 주소에 오류가 있는지 확인하면 편리합니다.

5. 사이트 오류

사이트의 페이지가 로드되면 요청이 서버로 전송되며, 서버는 HTTP 상태 코드로 응답하고 페이지를 로드(또는 로드하지 않음)합니다.

기본 상태 코드:

• 200 - 페이지가 양호합니다.
• 404 - 존재하지 않는 페이지;
• 503 - 서버를 일시적으로 사용할 수 없습니다.

"404 오류"는 개선이 필요한 최적화의 가장 중요한 기술 매개변수 중 하나입니다.

페이지가 존재하고 서버가 이를 요청할 때 404 오류를 알리면 해당 페이지는 검색 엔진에 의해 색인화되지 않습니다. 그렇지 않으면 동일한 텍스트가 포함된 많은 페이지가 색인에 포함될 수 있으며 이는 순위에 매우 부정적인 영향을 미칩니다.

http://www.bertal.ru/ 또는 Yandex.Webmaster를 사용하여 상태 코드를 확인할 수 있습니다.

우리는 먼저 주의를 기울여야 할 사이트 기술 개선의 주요 매개변수만 고려했습니다. 웹사이트에서 이러한 오류를 발견하거나 제거하기 어려운 경우 전문 SEO 회사에 문의하세요.

서버 성능을 높이는 데 사용할 수 있는 방법은 여러 가지가 있지만 가장 좋은 방법은 최적화입니다.

운영 체제 최적화(FreeBSD)

• 7.x로 전환새로운 ULE 3.0 Scheduler 및 jemalloc을 사용할 수 있으므로 멀티 코어 시스템에 유용합니다. 레거시 6.x 시스템을 사용하고 있고 부하를 감당할 수 없다면 이제 7.x로 전환해야 합니다.
• 7.2로 전환 KVA를 늘리고, 기본 sysctl로 최적화하고, 슈퍼페이지를 사용할 수 있습니다. 생산성을 크게 높이는 데 도움이 될 새로운 FreeBSD 8.0이 이미 준비 중입니다.
• amd64로 전환 KVA 및 공유 메모리 볼륨을 2Gb 이상으로 늘릴 수 있습니다. 데이터베이스가 지속적으로 증가하고 더 큰 크기가 필요하기 때문에 서버 개발을 위한 조건을 만드는 것이 필요합니다.
• 네트워크 하위 시스템 언로드 FreeBSD에서는 서버를 최적화하는 데 도움이 됩니다. 이 프로세스는 ifconfig 매개변수 조정과 sysctl.conf/loader.conf 설정의 두 단계로 수행할 수 있습니다. 준비 단계에서는 네트워크 카드의 성능을 확인해야 합니다. Yandex의 드라이버는 다중 스레드를 사용하여 속도를 높이는 데 도움이 되며 종종 다중 코어 프로세스에 사용됩니다. 3등급 네트워크 카드의 경우 폴링이 가장 좋은 솔루션입니다. FreeBSD 7 튜닝의 최신 업데이트 버전이 문제 해결에 도움이 될 것입니다.
• FreeBSD와 수많은 파일디렉토리의 파일 이름 캐싱 덕분에 훌륭하게 작동합니다. 해시 테이블을 검색하면 필요한 파일을 빠르게 찾는 데 도움이 됩니다. 최대 메모리 양은 약 2MB이지만 vfs.ufs.dirhash_mem이 허용하는 한 늘릴 수 있습니다.
• 소프트 업데이트, 저널그리고산 옵션- 뛰어난 성능을 지닌 새로운 테라바이트 나사입니다. 전원이 꺼지면 fsck에 매우 오랜 시간이 걸리므로 소프트 업데이트를 사용하거나 gjournal을 통해 로그할 수 있습니다.

프런트엔드 최적화(nginx)

이 유형은 사이트의 전체 응답 시간을 늘리는 데 도움이 되지만 조기 최적화로 분류될 수 있습니다. 표준 최적화 중에서 Reset_timedout_connection에 주목할 가치가 있습니다. 파일 전송; tcp_nopush 및 tcp_nodelay.

• 필터 수락새로운 데이터가 도착하거나 유효한 http 요청을 수신하는 경우 커널에서 프로세스로 정보를 전송할 수 있도록 하는 기술입니다. 이 필터는 연결 수가 많을 때 서버의 부담을 덜어줍니다.
• 캐싱 nginx는 유연성이 특징이며 fastcgi 또는 프록시 백엔드에서 생성됩니다. 누구나 자신의 프로젝트에서 캐싱을 스마트하게 사용할 수 있습니다.
• 올인원작업자 수를 줄이면서 응답 시간을 절약하기 때문에 일부 특정 서버 로드에 매우 유용합니다. nginx의 새 버전을 사용하면 sendfile과 함께 aio를 사용할 수 있습니다.

백엔드 최적화

• APC OP에서 컴파일된 코드를 캐싱하여 로드를 줄일 수 있는 프레임워크입니다. APC 잠금은 속도가 느려지고 많은 사람들이 APC 대신 eAccelerator를 사용하기 시작하므로 업데이트할 가치가 있습니다. 잠금을 spinlock이나 pthread mutex로 바꾸는 것이 좋습니다. .php 파일 수가 많거나 APC 사용자 캐시에 자주 캐시되는 경우 APC 힌트 값을 높여야 합니다. APC 조각화는 APC를 부적절하게 사용하고 있다는 신호입니다. 그는 TTL 또는 LRU를 통해 레코드를 독립적으로 삭제할 수 없습니다.
• PHP 5.3생산성 향상에 도움이 되므로 PHP 버전을 업그레이드하는 것이 좋습니다. 하지만 더 이상 사용되지 않는 기능 목록 때문에 많은 사람들이 겁을 먹을 수도 있습니다.

데이터베이스 최적화

모든 웹 프로젝트는 조만간 메모리, 디스크 또는 프로세서 양의 제한에 직면하기 때문에 인터넷에서 MySQL의 성능을 향상시키기 위한 많은 아이디어가 있습니다. 따라서 간단한 솔루션은 문제를 해결하는 데 도움이 되지 않으며, 프로파일러(dtrace, systemtap 및 oprofile)에 더 많은 시간을 투자하고 많은 추가 소프트웨어를 사용하는 것이 좋습니다. 인덱스를 완벽하게 사용하고 정렬하고 그룹화할 수 있어야 할 뿐만 아니라 이 모든 것이 MySQL 내에서 어떻게 작동하는지 알아야 합니다. 또한 다양한 스토리지 엔진의 장점과 단점을 알고 쿼리 캐시와 EXPLAIN을 이해해야 합니다.

코드를 변경하지 않고도 MySQL을 최적화하는 방법에는 여러 가지가 있습니다. 서버 튜닝의 절반은tuningprimer, mysqltuner 및 mysqlsla 유틸리티를 사용하여 반자동 모드에서 수행할 수 있기 때문입니다.

• 5.1로 전환많은 이점을 제공하며 그 중 최적화 프로그램 최적화, 파티셔닝, InnoDB 플러그인 및 행 기반 복제를 강조할 가치가 있습니다. 사이트 속도를 높이기 위해 일부 익스트림 스포츠 애호가들은 이미 버전 5.4를 테스트하고 있습니다.
• InnoDB로 전환많은 혜택을 제공합니다. ACID를 준수하므로 단 하나의 트랜잭션으로 모든 작업이 수행됩니다. 행 수준 잠금 기능이 있어 서로 분리되어 많은 스레드를 동시에 읽고 쓸 수 있습니다.
• 내장 MySQL 캐시 - 쿼리 캐시상당히 이해하기 어려워서 많은 유저들이 비합리적으로 사용하거나 꺼두는 경우가 많습니다. 그에게는 더 많다고 해서 더 좋은 것은 아니기 때문에 이 하위 시스템을 최대화할 가치가 없습니다. 쿼리 캐시는 병렬화되어 있으므로 8개 이상의 프로세스를 사용하면 전체 프로세스 속도가 느려질 뿐 사이트 로딩 시간을 줄이는 데 도움이 되지 않습니다. 특정 테이블과 관련된 이 하위 시스템의 내용은 해당 테이블이 변경되면 무효화됩니다. 이는 쿼리 캐시가 잘 설계된 테이블을 사용할 때만 긍정적인 결과를 제공한다는 것을 의미합니다.
• 인덱스는 SELECT(아무것도 없는 경우)와 INSERT/UPDATE(추가 인덱스가 있는 경우) 모두에 해로울 수 있습니다. 더 이상 사용되지 않는 인덱스는 여전히 메모리를 차지하므로 데이터 변경 속도가 느려집니다. 이 문제를 처리하려면 간단한 SQL 쿼리를 사용해야 합니다.

포스트그레SQL

Postgres 시스템은 Enterprise 클래스에 속하고 Skype가 훌륭하게 작동하기 때문에 매우 다재다능하지만 동시에 휴대폰에도 설치할 수 있습니다. 사용 가능한 200개의 매개변수 중 45개는 기본이며 튜닝을 담당합니다.

인터넷에서 Postgres 튜닝에 대한 유용한 정보를 많이 찾을 수 있습니다. 그러나 일부 기사는 이미 오래되었으므로 게시 날짜부터 시작하여 Vacuum_mem 키가 사용되는 정보 또는maintenance_mem의 새 버전에 주의해야 합니다. 고급 프로그래머는 많은 고품질 논문을 찾을 수 있으며 아래에는 일반 사용자가 프로젝트를 개선하는 데 도움이 되는 기본 사항만 나열됩니다.

• 인덱스 PostgreSQL은 항상 첫 번째 위치에 있는 반면 MySQL에서는 항상 마지막 위치를 차지합니다. 이는 PostgreSQL 인덱스가 엄청난 기능을 가지고 있다는 사실로 설명할 수 있습니다. 프로그래머는 이러한 인덱스를 잘 이해하고 있어야 하며 GiST, GIN, 해시 및 B-트리는 물론 부분, 다중 열 및 표현식과 같은 인덱스를 언제, 사용해야 하는지 알아야 합니다.
• pgBouncer그리고 그 대안은 먼저 데이터베이스 서버에 설치되어야 합니다. 연결 풀러가 없으면 각 요청은 RAM을 사용하는 별도의 프로세스를 생성합니다. 별거 아닌 것 같지만 200개가 넘는 연결을 만들면 아무리 강력한 서버라도 정보 처리에 어려움을 겪는다. pgBouncer는 이 문제를 해결하는 데 도움이 됩니다.
• pgFouine PHP에서 mysqlsla의 유사체라고 안전하게 부를 수 있기 때문에 필수 프로그램입니다. Player와 함께 스테이징 서버의 어려운 조건에서 쿼리 최적화를 수행할 수 있습니다.

데이터베이스 언로드

데이터베이스 운영을 최적화하고 성능을 높이려면 데이터베이스 사용을 가능한 한 적게 사용해야 합니다.

• 스핑크스QL MySQL 서버로 사용할 수 있습니다. 이렇게 하려면 sphinx.conf와 cron의 인덱서 항목을 만들고 다른 데이터베이스로 전환하면 됩니다. 이러한 작업을 수행하면 코드를 변경할 필요도 없습니다. SphinxQL로 전환하면 검색 속도와 품질이 향상되고 MyISAM 및 FTS가 필요하지 않습니다.
• 비RDBMS 스토리지관계형 데이터베이스를 사용하지 않도록 허용합니다. Hive 또는 Oracle을 선택할 수 있습니다. 키-값 데이터베이스는 속도로 인해 추가 캐싱을 위해 관계형 데이터베이스의 선택 항목을 사용합니다. 대규모 PHP 프로젝트의 소유자는 탁월한 opcode 캐시 기능을 사용하여 모든 사용자 정의 데이터를 저장할 수 있습니다. 도움을 받으면 공간을 거의 차지하지 않고 실제로 메모리를 차지하지 않으며 샘플링 속도도 크게 높일 수 있기 때문에 전역적으로 중요한 변경 사항도 안정적으로 저장할 수 있습니다. 대규모 프로젝트의 경우 전역 변경 블록이 하나의 시스템에만 기록되면 트래픽이 증가하고 속도가 크게 느려지기 시작합니다. 이 문제를 해결하려면 opcode 캐셔에 전역 변수를 저장하거나 모든 서버에 걸쳐 변수를 복제하고 일관성 해싱 알고리즘에 예외를 추가해야 합니다.
• 인코딩데이터베이스를 언로드하는 효과적인 방법을 참조하세요. UTF-8이 탁월한 선택이라는 점은 주목할 가치가 있지만 러시아어에서는 많은 공간을 차지하므로 단일 언어 조건의 경우 먼저 인코딩의 합리적인 사용에 대해 생각해야 합니다.
• 비동기성은 애플리케이션이나 웹사이트의 응답 시간을 줄이는 데 도움이 될 뿐만 아니라 서버 자체의 로드를 크게 줄이는 데도 도움이 됩니다. 일괄 요청은 일반적인 단일 요청보다 훨씬 빠르게 이루어집니다. 대규모 프로젝트의 경우 RabbitMQ, ApacheMQ 또는 ZeroMQ 메시지를 사용할 수 있고 소규모 프로젝트의 경우 cron만 사용할 수 있습니다.

최적화를 위한 추가 애플리케이션

• SSHGuard 또는 그 대안 SSH의 표준 관행입니다. 무차별 공격 방지는 봇 공격으로부터 안정적인 서버 보호를 만드는 데 도움이 됩니다.
• 엑스트라백업 Percona의 설정은 많은 훌륭한 MySQL 백업 도구입니다. 그러나 이상적인 솔루션은 ZFS에서 복제본을 호출하는 것입니다. 클론은 매우 빠르게 생성되고 데이터베이스를 복원하려면 근육 구성에서 파일 경로를 변경하는 것으로 충분하기 때문입니다. 클론을 사용하면 시스템을 처음부터 복원할 수 있습니다.
• 다른 호스트로 메일 전송서버가 스팸으로 가득 찬 경우 트래픽과 IOP가 절약됩니다.
• 타사 소프트웨어와의 통합 mysql 서버 최적화에 도움이 될 것입니다. 예를 들어, smtp/imap 연결을 사용하여 메시지를 교환할 수 있는데, 이는 많은 메모리를 차지하지 않습니다. 채팅을 생성하려면 자바스크립트 클라이언트와 함께 Jabber 서버 기반을 사용하는 것으로 충분합니다. 기성 제품에 대한 어댑터를 기반으로 하는 이러한 시스템은 확장성이 뛰어납니다.
• 모니터링은 매우 중요한 구성 요소입니다. 상세한 분석 없이는 아무것도 최적화할 수 없기 때문입니다. 성능 지표, 무료 리소스 및 지연을 모니터링해야 하며 Zabbix, Cacti, Nagios 및 기타 도구가 이에 도움이 될 것입니다. 웹 성능 테스트를 사용하면 웹 사이트나 프로젝트의 로딩 속도를 계산할 수 있으므로 모니터링에 매우 유용합니다. 성능 서버를 설정할 때 철저한 분석만이 모든 문제를 제거하고 최적화를 수행하는 데 도움이 된다는 점을 기억하십시오.

쓰여진 내용의 절반을 이해하지 못했다면 그것은 중요하지 않습니다.