워드프레스 속도 문제 및 해결

작성일자 글쓴이
응답

워드프레스 속도에 대한 검색을 해보면 대부분 비슷한 답변만 제시하고 원천적인 문제는 그누구도 말해주지 않았습니다.

서버 고사양으로 올려라 IDC 좋은데 써라 캐시/압축으로 빠르게 하라 이미지 최적화해라 CDN 이용해라 테마 가벼운거 써라 온갖거 다 제시했지만 근본적인 원인은 css와 js 의 동기식 처리 때문이였습니다.

비동기처리 해주는 플러그인 다운로드 받아서 테마 및 기본 템플릿 css, js 파일을 비동기 처리로 등록해주면 속도는 확실히 빨라지게 됩니다.

지금 필자의 블로그 사이트가 근본적인 원인을 찾아서 적용된 결과입니다.

설민석의 제주 4.3 이야기

작성일자 글쓴이
응답

글로만 읽으면 다들 고리 타분 하다고 하니 말 잘하는 사람이 설명해주는게 금방 이해가 빠른데 예전에 논문표절로 인하여 타격을 입고 방송에서 하차하게 되었습니다.

저 왜구당 심기를 건드리는 발언을 할때 이미 예고된 결과라고 하는 사람들도 많았습니다.

Adjusting Round Robin IOPS limit from default 1000 to 1 (2069356)

작성일자 글쓴이
응답
 Symptoms
ESXi hosts using iSCSI/FC/FC/FCoE storage experiences latency issues with no signs of latency on the SAN side.
 Resolution
ESXi Round Robin PSP (Path Selection Plug-in) uses a round-robin algorithm to balance the load across all active storage paths. A path is selected and used until a specific quantity of data has been transferred. After that quantity is reached, the PSP selects the next path in the list.
The quantity at which a path change triggered is known as the limit.
ESXi Round Robin PSP supports two types of limits:
  • IOPS limit: The Round Robin PSP defaults to an IOPS limit with a value of 1000. In this default case, a new path is used after 1000 I/O operations are issued.
  • Bytes limit: The bytes limit is an alternative to the IOPS limit. The bytes limit allows for a specified amount of bytes to be transferred before the path is switched.
Adjusting the limit can provide a positive impact to performance and is recommended by some storage vendors to change IOPS limit to 1.
Example:
The default of 1000 input/output operations per second (IOPS) sends 1000 I/O down each path before switching. If the load is such that a portion of the 1000 IOPS can saturate the bandwidth of the path, the remaining I/O must wait even if the storage array could service the requests. The IOPS or bytes limit can be adjusted downward allowing the path to be switched at a more frequent rate. The adjustment allows the bandwidth of additional paths to be used while the other path is currently saturated.
Adjusting the IOPS parameter
To adjust the IOPS parameter from the default 1000 to 1, run this command:

In ESXi 6.x:

for i in `esxcfg-scsidevs -c |awk ‘{print $1}’ | grep naa.xxxx`; do esxcli storage nmp psp roundrobin deviceconfig set –type=iops –iops=1 –device=$i; done

Where, .xxxx matches the first few characters of your naa IDs.

To verify if the changes are applied, run this command:

esxcli storage nmp device list

You see output similar to:
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config: {policy=iops,iops=1,bytes=10485760,useANO=0;lastPathIndex=1: NumIOsPending=0,numBytesPending=0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba33:C1:T4:L0, vmhba33:C0:T4:L0
Note: You do not need to restart the host for the changes to take effect.
 Related Information
When an ESXi hosts cluster contains Raw Device Mappings (RDMs) that are used for Microsoft Failover Clustering, SAN port congestion matters. Adjusting the Round Robin limit value to 200 IOPS may provide better failover results.
Changing IOPS from the default to a lower value with the Path Selection Policy Round Robin option is a performance tuning setting and can help load balance across the storage processors and HBA paths in a storage array. With IOPS=1000, 1000 I/Os are sent down a path before alternating to the next path. You could potentially run into a scenario were all LUNs could be sending 1000 I/Os down the same path at the same time leaving one Storage Processor in the array processing the I/O, while the other one(s) are in an idle state. By alternating the path after one I/O, you get a better balance of I/O across the paths and thus storage processors. You get even balance of I/Os across the paths. If saturation occurs, it is very short in duration and gives the Storage Process or more time to process the I/O.
You may automate this with PowerCLI to change IOPS limit per cluster for every LUN that has Round Robin multipathing policy. For more information, see the attached 2069356_PowerCLI_-_change_RR_IOPS_per_cluster.txt file.
Note: Consult your storage vendor to recommend if this value should be changed in your environment.

SQL SERVER – 성능 저하의 가장 큰 이유(한글번역기)

작성일자 글쓴이
응답

SQL 서버의 성능 저하 – 아키텍처 불량

이는 성능이 떨어지는 SQL Server의 가장 큰 이유인 것으로 보입니다. 그러나 건축의 주제는 매우 광범위하며 건축비효율성의 모든 지점을 논의하는 것은 불가능합니다. 아키텍처의 주제는 인덱스에서 쿼리 다시 작성으로 확산되고 AlwaysOn은 읽기 전용 복제본으로 분산되어 이 항목 아래에 포함할 수 있는 무한한 것들이 있습니다. 그러나 대화 중에 강조된 몇 가지 주제가 있습니다.

SQL SERVER - Top Reasons for Slow Performance slowperformance-800x483

미래의 증거 스키마와 코드를 구축하는 것은 쉽지 않습니다. 사업을 시작할 때, 비즈니스의 요구 사항은 수년 동안 동일한 비즈니스를 운영할 때와 매우 다릅니다. 비즈니스의 성공은 또한 다른 지리의 확장과 모든 사용자 정의 코드와 임시 수정을 많이 이르게 데이터의 성장을 제공, 이는 영구적이된다. 다음은 SQL Server의 성능 저하로 이어지는 빠른 목록입니다.

이유 #1: 나쁜 스키마 디자인

많은 사람들이 요구 사항을 완전히 파악하지 않고 스키마를 구축하기 시작하고 매우 복잡한 쿼리와 끔찍한 서버 성능으로 이어지는 초기에 잘못된 디자인으로 이어질 놀라운 찾을 수 있습니다.

일반적인 실수는 다음과 같습니다.

  • 정규화 불량 – 평면 와이드 테이블 또는 정규화 이상
  • 데이터베이스의 중복 데이터
  • 잘못된 참조 무결성(외래 키 및 제약 조건)
  • 넓은 복합 기본 키(및 클러스터된 인덱스)
  • 스키마 견고성 으로 인한 스트레스 테스트가 성장 패턴을 고수하지 않습니다.

더 나쁜 스키마 디자인 관행이 많이 있지만, 비즈니스가 성공한 후에야 여러 번 우연히 발견하고 잠시 후에 스키마를 변경하기가 어렵습니다. 새 프로젝트를 시작하는 경우 항상 처음부터 적절한 스키마를 설계하고 상태 확인의필요한 모든 단계를 따르는 것이 좋습니다.

이유 #2: 비효율적인 T-SQL 쿼리 / 코드

코딩이 좋지 않은 데는 여러 가지 이유가 있으며 코드를 작성하는 개발자가 스키마 또는 새 T-SQL 기능에 익숙하지 않기 때문입니다. 나는 커서를 사용하고 루프가 단순히 INSERT를 사용하여 데이터를 삽입 할 수있는 데이터를 삽입하는 동안 많은 사용자를 보았다 … 선택하거나 선택합니다… 테이블에 넣습니다.

일반적인 실수는 다음과 같습니다.

  • 존재하지 않거나 존재하지 않는 대신 에 또는 IN을 사용하지 않음
  • INSERT 대신 커서 또는 흰색 루프사용… 선택하거나 선택합니다… 테이블 속으로
  • 필요한 열 이름 대신 SELECT* 사용
  • 논리적 또는 AND 연산자 사용 시 괄호 사용 중지
  • 복잡한 실행 계획을 만드는 하위 쿼리 중첩
  • WHERE 절의 인덱싱된 열에서 함수 사용
  • 스칼라 사용자 정의 함수의 남용
  • 조건자(조건 또는 조인)의 데이터 형식 불일치
  • 유니온 대 유니온 올의 상호 교환 사용
  • 어디서나 구별을 사용하는 불필요한
  • 동적 SQL
  • … 이 시리즈는 한 달 동안 시리즈가 될 수 있습니다.

포괄적인 데이터베이스 성능 상태 확인중에 이 문제를 자세히 설명하는 동안 언제든지 이 주제에 대해 설명하는 무료 비디오를 볼 수 있습니다.

이유 #3: 잘못된 인덱싱 전략

감옥 카드에서 벗어나기 위한 해결책으로 인덱싱을 사용하는 사람들을 보는 것은 매우 일반적이며 종종 카드를 사용하기 위해 다시 감옥에 갇히는 경우가 많습니다. 색인은 종종 성능 문제를 해결하기 위해 실버 총알로 간주되지만 솔직히 이야기는 매우 다릅니다. 인덱싱을 잘못 사용하는 경우 절대적으로 귀하에 대해 작동할 수 있습니다. 색인과 함께 많은 공포 이야기가 있습니다. 나는이 주제에 대해 많은 블로그를 했기 때문에 토론을 매우 짧게 유지할 것입니다.

일반적인 실수는 다음과 같습니다.

  • 모든 단일 외국 키 인덱싱
  • 테이블의 모든 열 인덱싱
  • 많은 단일 열 인덱스
  • 클러스터된 인덱스 위에 힙 테이블 선호
  • 테이블 의 과소 평가
  • 인덱스를 유지 관리하지 않음

다음은 인덱스 전략의 균형을 맞추는 데 도움이 되는 인덱싱을 위한 가장 인기 있는 두 스크립트입니다.

또한, 인덱스가 SELECT 문의 성능을 저하시킬 수 있는 방법을 보여 주는 무료 비디오를 여기에서 시청하는 것이 좋습니다.

다음은 후속 블로그 게시물입니다: 잘못된 색인 전략 – 10 인덱스에 대 한 하지 마십시오.

이유 #4: 잘못된 서버 배포

이것은 내가 가장 좋아하는 주제이며 사실, 나는 몇 시간 동안 그것에 대해 계속 이야기 할 수 있습니다. 교육 세션에 참석한 경우 잘못된 서버 배포 관행 목록을 알고 있어야 합니다. 가장 큰 불만, 사람들이 그들의 SQL Server를 업그레이드 할 때 듣고 새로운 소프트웨어와 하드웨어에도 불구 하 고 그들은 성능 저하. SQL Server의 성능 저하와 관련된 다양한 매개 변수가 있으며 가장 큰 매개 변수는 적절한 배포입니다.

일반적인 실수는 다음과 같습니다.

  • 최대 병렬 도0유지
  • 인덱스 레벨을 채우기 팩터로 설정하지 않음
  • 낮은 필그라스
  • 단일 TempDB 파일
  • SQL Server 데이터 및 로그 파일을 함께 호스팅
  • SQL Server 파일에서 바이러스 백신 실행
  • 최대 메모리 구성의 잘못된 값
  • 로그 파일에 대한 높은 대기 시간
  • … 그리고 더 많은 나는 종종 건강 검사 중에 논의.

#5 이유: 프로비저닝 하드웨어

나는 이것이 업계의 주요 문제였으면 좋겠다. 대부분의 경우 과도하게 프로비저닝된 하드웨어를 볼 수 있지만 SQL Server를 잘못 배포했습니다. 샘플 질문 중 일부를 보자, 나는 종종받을 수 있습니다.

  • 우리의 CPU가 100 %를 실행, 우리는 더 많은 CPU를 제공해야합니까?
  • 우리의 메모리는 SQL Server에 의해 95 % 혼란스럽습니다.
  • 디스크 대기열은 항상 매우 높으며 디스크와 별도의 워크로드를 추가해야 합니까?

솔직히, 당신은 항상 더 많은 하드웨어를 던져 성능을 향상시킬 수 있지만, 그 로 시작하는 것은 결코 사실이 아니다. 더 많은 하드웨어를 제공 하면 일시적으로 문제를 해결할 수 있습니다 하지만 영구적인 솔루션되지 않을 수 있습니다. 하나는 리소스가 소비되는 방법을 보고 하드웨어의 결정을 기반으로 하는 보다 과학적 방법을 거쳐야 합니다.

100건의 성능 튜닝 사례 중 3건에서 하드웨어를 업그레이드하는 것이 좋습니다. 대부분의 경우 CPU, IO 및 메모리와 관련된 느린 성능 문제를 해결할 수 있습니다.

성능 저하 및 지식

모든 문제에 대한 해결책은 매우 간단합니다 – 지식. 데이터 플랫폼 분야의 전문가라면 앞으로 다가올 모든 과제보다 앞서 나갈 수 있도록 계속해서 학습하고 발전해야 합니다.

서버가 느리게 실행되고 그것에 대해 토론하고자하는 경우,이 주제에 대한 자세한 논의를 위해 나에게 연락 하는 것을 망설이지 말고, 포괄적 인 데이터베이스 성능 상태 확인. 나는 당신의 서버의 건강에 대해 당신에게 이야기하고 당신이 성공을 위해 설정하는 데 도움이행복 할 것이다 .

당신은 항상 트위터와 링크드 인에나와 함께 연결할 수 있습니다 .

참고 : 피날 데이브(https://blog.sqlauthority.com)

 

출처: <https://blog.sqlauthority.com/2020/02/10/sql-server-top-reasons-for-slow-performance/>