부하가 높은 사이트에서 PHP를 사용하기 위한 전술

부하가 높은 사이트에서 PHP를 사용하기 위한 전술

이 질문에 답하기 전에 저는 높은 서버 로드를 얻을 수 있을 만큼 인기 있는 것을 개발한 적이 없습니다.PHP와 몇 가지 최적화 기술을 알고 있지만, 저를 지구에 막 착륙한 외계인 취급해 주세요.

---

PHP에서 툴을 개발하고 있습니다.PHP가 제대로 작동한다면 많은 사용자를 확보할 수 있습니다.그러나 프로그램을 개발할 수 있는 능력은 충분히 있지만, 엄청난 트래픽을 처리할 수 있는 것을 만드는 것에 대해서는 거의 아무것도 모릅니다.몇 가지 질문이 있습니다(이 질문도 리소스 스레드로 자유롭게 전환하십시오).

데이터베이스

현재로서는 PHP5의 MySQLi 기능을 사용할 예정입니다.그러나 사용자 및 콘텐츠와 관련하여 데이터베이스를 어떻게 설정해야 합니까?실제로 여러 데이터베이스가 필요합니까?현재 모든 것이 하나의 데이터베이스로 혼재되어 있습니다.사용자 데이터를 하나의 데이터베이스로, 실제 콘텐츠를 다른 데이터베이스로, 마지막으로 핵심 사이트 콘텐츠(템플릿 마스터 등)를 다른 데이터베이스로 확산하는 것을 검토하고 있습니다.이 배경에는 쿼리를 서로 다른 데이터베이스로 전송하면 하나의 데이터베이스 = 3개의 로드 소스로 인해 쿼리의 부하가 완화되기 때문입니다.또, 모두 같은 서버에 있는 경우에도 유효합니까?

캐싱

페이지를 작성하고 변수를 교환하는 데 사용되는 템플릿 시스템이 있습니다.기본 템플리트는 데이터베이스에 저장되며 템플리트가 호출될 때마다 캐시된 복사본(html 문서)이 호출됩니다.현재 이 템플릿에는 정적 변수와 동적 변수라는 두 가지 변수가 있습니다.정적 변수란 일반적으로 페이지 이름, 사이트 이름과 같은 자주 변경되지 않는 변수입니다. 동적 변수는 각 페이지 로드 시 변경되는 항목입니다.

이에 대한 질문입니다.

다른 기사에 대한 코멘트가 있다고 칩시다.어느 쪽이 더 좋은 해결책입니까?페이지가 로드될 때마다 심플한 코멘트템플릿을 저장하고 (DB 콜에서) 코멘트를 렌더링하거나 코멘트가 추가/편집/삭제될 때마다 코멘트 페이지의 캐시된 복사본을 HTML 페이지로 저장합니다.

마침내.

PHP에서 부하가 높은 사이트를 실행하기 위한 힌트나 포인터가 있습니까?Facebook과 Yahoo!가 우선시하는 실용적인 언어라고 확신합니다만, 주의해야 할 것이 있습니까?

비슷한 사이트는 없습니다.jmeter나 benchmark 등의 툴을 사용하여 문제점의 위치를 확인할 필요가 있습니다.추측과 개선에 많은 시간을 할애할 수 있지만, 변화를 측정하고 비교하기 전에는 실질적인 결과를 볼 수 없습니다.

예를 들어, 수년 동안 MySQL 쿼리 캐시는 당사의 모든 성능 문제에 대한 해결책이었습니다.사이트 속도가 느린 경우 MySQL 전문가는 쿼리 캐시를 켜는 것이 좋습니다.쓰기 부하가 높을 경우 캐시가 실제로 마비되는 것으로 나타났습니다.테스트 안 하고 켰으면 모를 거예요.

그리고 스케일링이 끝나지 않았다는 것도 잊지 마세요.10req/s를 처리하는 사이트에서는 1000req/s를 지원하려면 변경이 필요합니다.10,000req/s를 지원해야 할 정도로 운이 좋다면 아키텍처도 완전히 달라질 수 있습니다.

데이터베이스

• MySQLi 사용 안 함 - PDO는 '현대' OO 데이터베이스 액세스 계층입니다.사용하는 가장 중요한 기능은 쿼리의 자리 표시자입니다.서버측 준비 및 기타 최적화 기능을 사용할 수 있을 만큼 스마트합니다.
• 이 시점에서 데이터베이스를 해체하고 싶지 않을 수도 있습니다.하나의 데이터베이스가 잘리지 않는 경우 앱에 따라 몇 가지 스케일업 기술을 사용할 수 있습니다.추가 서버에 복제하는 것은 일반적으로 쓰기보다 읽기가 더 많은 경우에 잘 작동합니다.샤딩은 데이터를 여러 기계로 분할하는 기술입니다.

캐싱

• 데이터베이스에 캐시하고 싶지 않을 수 있습니다.데이터베이스는 일반적으로 병목현상이므로 I/O를 추가하는 것은 일반적으로 좋지 않습니다.APC나 Zend와 같은 유사한 기능을 수행하는 여러 PHP 캐시가 있습니다.
• 캐시를 켜고 끄고 시스템을 측정합니다.당신의 캐시가 페이지를 바로 보내는 것보다 더 무겁다고 장담합니다.
• DB에서 코멘트 및 기사 데이터를 작성하는 데 시간이 오래 걸리는 경우 memcache를 시스템에 통합합니다.쿼리 결과를 캐시하여 memcached 인스턴스에 저장할 수 있습니다.이점을 확인하려면 memcache에서 데이터를 검색하는 것이 데이터베이스에서 데이터를 어셈블하는 것보다 빠를 필요가 있다는 점을 기억해야 합니다.
• 문서가 동적이지 않거나 생성된 후 단순한 동적 변경이 있는 경우 디스크에 html 또는 php를 쓰는 것을 고려해 보십시오.디스크에서 기사를 찾는 index.php 페이지가 있을 경우 클라이언트에 스트리밍합니다.그렇지 않으면 문서를 생성하고 디스크에 쓴 후 클라이언트에 보냅니다.디스크에서 파일을 삭제하면 페이지가 다시 작성됩니다.문서에 주석이 추가된 경우 캐시된 복사본을 삭제하십시오. 그러면 재생성됩니다.

저는 사용자 수가 1,500만 명이 넘는 사이트의 개발 책임자입니다.초기에 계획을 세우고 신중하게 확장했기 때문에 확장 문제는 거의 없었습니다.여기 제 경험에서 제안할 수 있는 전략 몇 가지가 있습니다.

스키마 우선 스키마를 정규화 해제합니다.즉, 여러 개의 관계형 테이블을 갖는 대신 하나의 큰 테이블을 갖는 것을 선택해야 합니다.일반적으로 Join은 여러 준비 및 데이터 수집을 통해 디스크 I/O를 소비하기 때문에 소중한 DB 리소스를 낭비하는 것입니다.될 수 있을 때 그들을 피하세요.

여기서의 단점은 용장 데이터의 저장/풀링입니다.단, 데이터 및 케이지 내 대역폭은 매우 저렴하고(디스크 용량이 커짐), 복수의 준비 I/O는 매우 비싸기 때문에(서버의 수 증가) 허용됩니다.

인덱싱 쿼리에서 하나 이상의 인덱스를 사용해야 합니다.단, 자주 쓰거나 업데이트하면 인덱스가 비싸집니다.이것을 피하기 위한 몇 가지 실험적인 요령이 있다.

인덱싱되지 않은 열을 인덱싱된 열과 병렬로 실행할 수 있습니다.그런 다음 인덱싱되지 않은 열을 인덱싱된 열에 일괄적으로 쓰는 오프라인 프로세스를 사용할 수 있습니다.이렇게 하면 mySQL이 인덱스를 재계산해야 하는 시기를 더 잘 제어할 수 있습니다.

전염병처럼 계산된 쿼리를 피합니다.쿼리를 계산해야 하는 경우 쓰기 시간에 한 번 해보십시오.

캐싱 Memcached를 강력히 추천합니다.PHP 스택(Facebook)에서 가장 큰 플레이어에 의해 증명되었으며 매우 유연합니다.여기에는 DB 계층에서 캐싱하는 방법과 비즈니스 로직 계층에서 캐싱하는 방법 두 가지가 있습니다.

DB 계층 옵션을 사용하려면 DB에서 검색된 쿼리의 결과를 캐싱해야 합니다.md5()를 사용하여 SQL 쿼리를 해시하고 데이터베이스로 이동하기 전에 이를 검색 키로 사용할 수 있습니다.이것의 장점은 구현이 매우 쉽다는 것이다.단점(구현에 따라 다름)은 캐시 유효기간과 관련하여 모든 캐시를 동일하게 취급하기 때문에 유연성이 떨어진다는 것입니다.

저희 회사에서는 비즈니스 레이어 캐싱을 사용하고 있습니다.즉, 시스템의 각 구체적인 클래스가 자체 캐싱 스키마와 캐시 타임아웃을 제어합니다.이것은 우리에게 꽤 효과가 있었지만 DB에서 검색된 항목이 캐시에서 검색된 항목과 다를 수 있으므로 캐시와 DB를 함께 업데이트해야 합니다.

DATA 샤딩 복제는 지금까지의 성과만 가져옵니다.예상보다 빨리 쓰기가 병목현상이 됩니다.이를 보완하려면 데이터 샤딩을 가능한 한 조기에 지원해야 합니다.그렇지 않으면 나중에 자살하고 싶을 거예요.

구현은 매우 간단합니다.기본적으로 데이터 스토리지에서 주요 권한을 분리해야 합니다.글로벌 DB를 사용하여 기본 키와 클러스터 ID 간의 매핑을 저장합니다.이 매핑을 쿼리하여 클러스터를 가져온 다음 클러스터를 쿼리하여 데이터를 가져옵니다.이 룩업 조작의 hell을 캐시하여 무시해도 될 정도의 조작을 할 수 있습니다.

이것의 단점은 여러 조각의 데이터를 결합하는 것이 어려울 수 있다는 것입니다.하지만, 당신은 그것을 회피할 수 있습니다.

오프라인 처리 사용자가 필요하지 않으면 백엔드를 기다리게 하지 마십시오.작업 대기열을 작성하고 오프라인으로 처리할 수 있는 모든 프로세스를 사용자의 요청과 별도로 이동하십시오.

저는 PHP와 MySQL을 통해 수백만/히트/월급을 받는 몇몇 사이트에서 일해 왔습니다.기본은 다음과 같습니다.

1. 캐시, 캐시, 캐시캐싱은 웹 서버 및 데이터베이스의 부하를 줄이는 가장 간단하고 효과적인 방법 중 하나입니다.캐시 페이지 콘텐츠, 쿼리, 고가의 계산 등 I/O에 얽매이는 모든 것.Memcache는 매우 단순하고 효과적입니다.
2. 최대 한도를 넘으면 여러 서버를 사용합니다.(복제가 있는) 여러 웹 서버와 여러 데이터베이스 서버를 가질 수 있습니다.
3. 웹 서버에 대한 전반적인 요청 수를 줄입니다.여기에는 Expires 헤더를 사용하여 JS, CSS 및 이미지를 캐시해야 합니다.스태틱 콘텐츠를 CDN으로 이동하여 사용자의 작업 속도를 높일 수도 있습니다.
4. 측정 및 벤치마크프로덕션 머신에서 Nagios를 실행하고 개발/QA 서버에서 로드 테스트를 수행합니다.서버에 언제 불이 붙을지 알아야 예방할 수 있습니다.

Flickr 엔지니어 중 한 명이 작성한 확장 가능한 웹 사이트 구축을 추천합니다.

scalability에 관한 제 블로그 투고도 확인해 주세요.다국어 및 플랫폼을 사용한 확장에 관한 프레젠테이션 링크도 많이 있습니다.http://www.ryandoherty.net/2008/07/13/unicorns-and-scalability/

PDO / MySQLi / MySQLND 관련 정보

@gary

MySQLi는 목적이 다르기 때문에 사용하지 말라고만 할 수 없습니다.PDO는 거의 추상화 레이어(실제로 그렇지는 않지만)와 비슷하며 MySQLi는 MySQL 접속에 특화되어 있는 반면 여러 데이터베이스 제품을 쉽게 사용할 수 있도록 설계되었습니다.PDO가 MySQLi와 비교되는 상황에서 최신 액세스레이어라고 하는 것은 잘못된 것입니다.그것은 진행이 mysql -> mysqli -> PDO가 되어 있다는 것을 나타내고 있기 때문입니다.

MySQLi와 PDO 중에서 선택할 수 있습니다.여러 데이터베이스 제품을 지원해야 하는 경우 PDO를 사용합니다.MySQL만 사용하는 경우 PDO와 MySQLi 중에서 선택할 수 있습니다.

PDO가 아닌 MySQLi를 선택한 이유는 무엇입니까?아래를 참조해 주세요.

@ross

MySQLnd는 최신 MySQLnd 핵심 언어 수준 라이브러리이지만 MySQLi를 대체하는 것은 아닙니다.MySQLi(PDO와 마찬가지로)는 PHP 코드를 통해 MySQL과 상호 작용하는 방식을 유지합니다.둘 다 libmysql을 PHP 코드 뒤에 있는 C 클라이언트로 사용합니다.문제는 libmysql이 코어 PHP 엔진 외부에 있다는 것입니다.그것이 mysqlnd가 되는 이유입니다.즉, 코어 PHP의 내부 드라이버를 사용하여 효율을 최대화하는 네이티브 드라이버입니다.특히 메모리 사용량에 관계됩니다.

MySQLnd는 MySQL 자체 개발 중이며 최근 RC 테스트 중인 PHP 5.3 브랜치에 출시되어 올해 말 출시 준비가 되었습니다.MySQLd를 MySQLi와 함께 사용할 수 있습니다.PDO에서는 안 돼요이를 통해 MySQLi는 (전부는 아님) 많은 영역에서 성능을 향상할 수 있으며 PDO와 같은 추상화가 필요하지 않은 경우 MySQL 상호 작용에 가장 적합한 선택이 될 수 있습니다.

즉, MySQLnd는 현재 PHP 5.3 for PDO로 제공되고 있기 때문에 ND에서 PDO로 성능 향상의 이점을 얻을 수 있지만 PDO는 여전히 일반적인 데이터베이스 계층이기 때문에 MySQLi만큼 ND에서 성능 향상의 이점을 얻을 수 없을 것입니다.

2006년판이지만 유용한 벤치마크는 여기에서 찾을 수 있습니다.이 옵션과 같은 것도 알고 있어야 합니다.

MySQLi와 PDO 중 하나를 결정할 때 고려해야 할 사항이 많습니다.사실, 요청 수가 지나치게 많을 때까지는 문제가 되지 않습니다.이 경우, 사물을 추상화하여 MySQL 드라이버를 제공하는 확장자보다는 MySQL용으로 특별히 설계된 확장자를 사용하는 것이 더 합리적입니다.

각각 장점과 단점이 있기 때문에 어느 것이 가장 좋은가 하는 것은 간단한 문제가 아니다.내가 제공한 링크를 읽고 스스로 결정을 내린 다음 테스트하고 알아내야 합니다.이전 프로젝트에서 PDO를 사용한 적이 있고, 좋은 확장이지만, 순수한 성능을 위해 새로운 MySQLND 옵션이 컴파일된 MySQLi를 선택합니다(PHP 5.3이 출시되었을 때).

일반

• 실제 부하가 나타나기 전에는 최적화를 시도하지 마십시오.맞힐지 모르지만 그렇지 않으면 시간낭비예요.
• jmeter, xdebug 또는 다른 도구를 사용하여 사이트를 벤치마킹합니다.
• 로드가 문제가 되기 시작하면 오브젝트 또는 데이터 캐싱이 관련되어 있을 가능성이 높으므로 일반적으로 캐싱 옵션(메모된 옵션, MySQL 캐싱 옵션)을 읽어보십시오.

코드

• 코드의 프로파일링을 통해 병목현상이 어디에 있는지, 코드에 있는지, 데이터베이스에 있는지 알 수 있습니다.

데이터베이스

• 다른 데이터베이스로의 이식성이 중요하지 않으면 MYSQLi를 사용하고 그렇지 않으면 PDO를 사용합니다.
• 벤치마크에서 데이터베이스가 문제인 것으로 판명된 경우 캐시를 시작하기 전에 쿼리를 확인하십시오.EXPLY를 사용하여 쿼리 속도가 느려지는 부분을 확인하십시오.
• 조회가 최적화되고 데이터베이스가 캐시된 후에는 여러 데이터베이스를 사용할 수 있습니다.데이터, 쿼리 및 읽기/쓰기 동작의 종류에 따라 여러 서버에 복제하거나 샤딩(데이터를 여러 데이터베이스/서버에 분할)하는 것이 적절할 수 있습니다.

캐싱

• 코드, 객체 및 데이터를 캐싱하는 데 많은 쓰기가 수행되었습니다.APC, Zend Optimizer, memcached, QuickCache, JPCache 관련 기사를 검색합니다.실제로 필요하기 전에 이 작업을 몇 가지 실시하면 최적화되지 않은 상태로 시작하는 것에 대한 걱정이 줄어듭니다.
• APC와 Zend Optimizer는 opcode 캐시로 코드 재파싱 및 재컴파일을 방지하여 PHP 코드 속도를 높입니다.일반적으로 설치가 간단하고 조기에 실행할 가치가 있습니다.
• Memcached는 쿼리, PHP 함수 또는 객체 또는 전체 페이지를 캐시하는 데 사용할 수 있는 일반 캐시입니다.이 코드를 사용하려면 코드를 구체적으로 작성해야 합니다.캐시된 오브젝트의 작성, 갱신 및 삭제를 처리하는 중앙 지점이 없는 경우 관련 프로세스가 될 수 있습니다.
• QuickCache 및 JPCache는 Memcached와 유사한 파일 캐시입니다.기본 개념은 단순하지만 코드가 필요하며 생성, 업데이트 및 삭제의 중앙 지점이 있어 더 쉽습니다.

여러가지 종류의

• 부하가 높은 경우 대체 웹 서버를 고려하십시오.Lightttp 및 nginx와 같은 서버는 Apache보다 훨씬 적은 메모리로 대량의 트래픽을 처리할 수 있습니다. Apache의 파워와 유연성을 희생할 수 있다면(또는 이러한 기능이 필요하지 않은 경우가 많습니다).
• 오늘날 하드웨어는 놀라울 정도로 저렴하기 때문에 "괴물 서버를 구입하자"가 아니라 많은 코드 블록을 최적화하기 위한 노력을 낭비해야 합니다.
• 이 질문에 "MySQL" 및 "스케일링" 태그를 추가하는 것을 고려해 보십시오.

APC는 절대적인 필수입니다.캐싱 시스템이 훌륭할 뿐만 아니라, 자동 캐시된 PHP 파일을 통해 얻을 수 있는 혜택은 축복입니다.다중 데이터베이스 아이디어에 대해서는, 같은 서버에 다른 데이터베이스를 두는 것으로부터 얻을 수 있는 것은 별로 없다고 생각합니다.쿼리 시간 동안 속도가 다소 향상될 수 있지만, 이 세 가지 코드가 모두 동기화되어 있는지 확인하면서 코드를 배포하고 유지하는 데 드는 노력이 가치가 있을지는 의문입니다.

또한 Xdebug를 실행하여 프로그램의 병목현상을 찾을 것을 강력히 권장합니다.최적화를 쉽게 할 수 있었습니다.

첫째, 크누스가 말했듯이, "최신 최적화는 모든 악의 근원"이다.지금 당장 이러한 문제를 해결할 필요가 없다면 먼저 올바르게 작동하는 제품을 제공하는 데 집중하십시오.말하자면, 최적화가 기다릴 수 없다면.

데이터베이스 쿼리를 프로파일링하고 무엇이 느리고 무엇이 자주 일어나는지 파악한 후 최적화 전략을 생각해 보십시오.

Memcached는 모든 유형의 콘텐츠를 효율적으로 캐싱하기 위해 많은 부하가 높은 사이트에서 사용하는 것이기 때문에 Memcached에 대한 PHP 오브젝트 인터페이스가 매우 좋습니다.

서버 간에 데이터베이스를 분할하여 로드밸런싱(예를 들어 필요한 데이터를 사용하여1 ~ #의 용장 데이터베이스 간에 랜덤 번호를 생성하여 그 번호를 사용하여 접속할 데이터베이스 서버를 결정하는 등)을 사용하는 것도 효율을 높이는 훌륭한 방법입니다.

과거에는 부하가 상당히 높은 사이트에서는 이 모든 것이 꽤 잘 해결되었습니다.이것이 시작에 도움이 되기를 바랍니다:-)

Xdebug(tj9991 권장)와 같은 것으로 앱을 프로파일링하는 것은 필수입니다.무작정 사물을 최적화하기 위해 돌아다닌다는 것은 말이 안 된다.Xdebug는 코드의 실제 병목 현상을 찾아내는 데 도움이 됩니다.이것에 의해, 최적화 시간을 현명하게 소비해, 실제로 다운 다운의 원인이 되고 있는 코드의 덩어리를 수정할 수 있습니다.

Apache를 사용하는 경우 테스트에 도움이 되는 또 다른 유틸리티는 Sign입니다.서버나 애플리케이션이 부하가 높은 경우에 어떻게 반응할지를 예측하는데 도움이 됩니다.

PHP용 opcode 캐시(APC 또는 다른 많은 캐시 중 하나)도 많은 도움이 됩니다.

저는 한 달에 700만에서 800만 페이지뷰의 웹사이트를 운영하고 있습니다.그렇게 많지는 않지만, 우리 서버가 부하를 느끼기에 충분합니다.델이 선택한 솔루션은 심플했습니다.데이터베이스 수준의 메모리 캐시입니다.이 솔루션은 데이터베이스 로드가 주요 문제인 경우 잘 작동합니다.

먼저 Memcache를 사용하여 전체 개체와 가장 자주 사용되는 데이터베이스 결과를 캐시했습니다.동작은 했지만 버그도 발생했습니다(좀 더 주의했다면 버그 중 일부를 피할 수 있었을지도 모릅니다).

그래서 접근 방식을 바꿨습니다.데이터베이스 래퍼(이전 데이터베이스와 완전히 동일한 방법으로 전환이 용이함)를 구축한 후 memcached 데이터베이스 액세스 방식을 제공하기 위해 하위 분류했습니다.

이제 쿼리에서 캐시된(및 오래된) 결과를 사용할 수 있는지 여부만 결정하면 됩니다.사용자가 실행하는 대부분의 쿼리는 이제 Memcache에서 직접 가져옵니다.업데이트 및 삽입은 예외이며, 기본 웹 사이트의 경우 로깅 때문에만 발생합니다.이 다소 간단한 방법으로 서버 로드를 약 80% 절감했습니다.

캐싱은 memcached와 같은 확장/헬퍼 패키지가 없어도 PHP에서 DOT SIMPLE입니다.

필요한 것은 출력 버퍼를 작성하는 것 뿐입니다.ob_start().

글로벌 캐시 함수를 만듭니다.불러ob_start기능을 콜백으로 전달합니다.함수에서 페이지의 캐시된 버전을 찾습니다.존재한다면, 그것을 섬기고 끝내라.

존재하지 않는 경우 스크립트는 처리를 계속합니다.일치하는 ob_end()에 도달하면 지정한 함수를 호출합니다.이 때 출력 버퍼의 내용을 가져와 파일에 드롭하고 파일을 저장한 후 종료합니다.

유통기한/쓰레기 컬렉션을 추가합니다.

그리고 많은 사람들은 네가 둥지를 틀 수 있다는 걸 알지 못한다.ob_start()/ob_end()이미 출력 버퍼를 사용하여 애드버타이즈나 구문 강조 표시 등을 하고 있는 경우는, 다른 것을 네스트 할 수 있습니다.ob_start/ob_end불러.

PHP의 캐싱 확장에 대한 조언에 감사드립니다. 다른 캐싱 확장자를 사용하는 이유를 설명해 주시겠습니까?IRC를 통해 memcached에 대해 좋은 말은 들었지만 APC에 대해서는 들어본 적이 없습니다.그들에 대해 어떻게 생각하십니까?여러 개의 캐싱 시스템을 사용하는 것이 상당히 역효과적이라고 생각합니다.

사실 많은 사람들이 APC와 memcached를 함께 사용합니다.

내가 틀렸던 것 같아.MySQLi는 아직 개발 중입니다.그러나 기사에 따르면 PDO_MySQL은 현재 MySQL 팀에 의해 제공되고 있습니다.기사 내용:

MySQL 확장 기능(mysqli)이 대표적입니다.Charsets, Prepared 스테이트먼트, Stored Procedure 등 MySQL Server의 모든 기능을 지원합니다.드라이버는 하이브리드 API를 제공합니다: 원하는 대로 프로시저 또는 객체 지향 프로그래밍 스타일을 사용할 수 있습니다.mysqli는 PHP 5 이상과 함께 제공됩니다.PHP 4의 종료일은 2008-08-08입니다.

PHP 데이터 개체(PDO)는 데이터베이스 액세스 추상화 계층입니다.PDO를 사용하면 다양한 데이터베이스에 동일한 API 호출을 사용할 수 있습니다.PDO는 SQL 추상화를 제공하지 않습니다.PDO_MYSql은 PDO용 MySQL 드라이버입니다.PDO_MYSql은 PHP 5.3 MySQL 개발자가 적극적으로 참여하고 있습니다.Unified API의 PDO 이점은 MySQL 고유의 기능(예: 여러 문)이 Unified API를 통해 완전히 지원되지 않는다는 점에 있습니다.

PHP용 최초 MySQL 드라이버 ext/mysql 사용을 중지하십시오.2004년에 MySQL 확장 기능(mysqli)이 PHP 5와 함께 도입된 이후 가장 오래된 드라이버를 사용할 이유가 없습니다.ext/mysql은 문자 집합, 준비된 문 및 저장 프로시저를 지원하지 않습니다.MySQL 4.0의 기능 세트로 제한됩니다.MySQL 4.0에 대한 확장 지원은 2008-12-31에서 종료됩니다.이러한 낡은 소프트웨어의 기능 세트에 한정하지 말아 주세요.mysqli로 업그레이드하려면 Converting_to_MySQLi를 참조하십시오.mysql은 유지보수 전용 모드입니다.

제가 보기에 그 기사는 MySQLi에 치우친 것 같습니다.나는 PDO에 편중되어 있는 것 같아요.MySQLi보다 PDO가 더 좋아요.그것은 나에게 직설적이다.API는 제가 프로그래밍한 다른 언어에 훨씬 더 가깝습니다.OO 데이터베이스 인터페이스가 더 잘 작동하는 것 같습니다.

PDO에서 사용할 수 없는 MySQL 기능은 아직 발견하지 못했습니다.만약 그랬다면 난 놀랄거야.

PDO도 매우 느리고 API도 매우 복잡합니다.휴대성이 문제가 되지 않는다면 제정신인 사람은 그것을 사용해서는 안 된다.사실 99%의 웹 앱에서는 그렇지 않습니다.MySQL 또는 Postrgre만 사용하시면 됩니다.SQL 또는 현재 사용하고 있는 SQL입니다.

PHP의 질문이나 고려해야 할 것은 무엇입니까?나는 섣부른 최적화가 모든 악의 근원이라고 생각한다.;) 먼저 어플리케이션을 완료하고 프로그래밍에 관한 한 깨끗하게 유지하며 약간의 문서화를 수행하고 유닛 테스트를 작성합니다.위의 모든 것을 통해, 그 시점에서 코드 리팩터링에 문제가 없습니다.하지만 당신은 먼저 그것을 끝내고 사람들이 그것에 어떻게 반응하는지 보기 위해 그것을 밀어내고 싶어합니다.

물론 pdo도 좋지만 mysql과 mysqli에 대한 성능 논란이 있었지만 지금은 수정이 된 것 같습니다.

휴대성을 상정하고 있는 경우는 pdo를 사용하는 것이 좋습니다만, 그렇지 않은 경우는 mysqli를 사용하는 것이 좋습니다.여기에는 OO 인터페이스, 준비된 문, pdo가 제공하는 대부분의 기능(휴대성 제외)이 있습니다.

게다가 퍼포먼스가 정말로 필요한 경우는, PHP 5.3의 (네이티브 mysql) MysqLnd 드라이버를 준비해 주세요.이 드라이버는 php와 더욱 긴밀하게 통합되어 퍼포먼스와 메모리 사용률(및 퍼포먼스 튜닝을 위한 통계 정보)이 향상됩니다.

클러스터화된 서버(및 YouTube와 같은 부하)를 가지고 있다면 Memcache도 좋지만, 저는 APC를 먼저 사용해보고 싶습니다.

이미 많은 좋은 답변이 있었습니다만, XCache라고 하는 대체 opcode 캐시를 알려드리고 싶습니다.가벼운 기고자에 의해 작성되었습니다.

또한 향후 데이터베이스 서버의 로드밸런싱이 필요할 경우 MySQL Proxy를 사용하여 이 작업을 수행할 수 있습니다.

두 툴 모두 기존 애플리케이션에 매우 쉽게 연결할 수 있기 때문에 필요할 때 큰 번거로움 없이 최적화를 수행할 수 있습니다.

첫 번째 질문은 그것이 얼마나 클 것으로 예상하느냐는 것이다.또한 인프라스트럭처에 얼마나 투자할 계획입니까?여기서 질문할 필요성을 느끼기 때문에 한정된 예산으로 작은 규모로 시작할 것으로 예상됩니다.

사이트를 사용할 수 없는 경우 성능은 중요하지 않습니다.가용성을 확보하려면 수평적 확장이 필요합니다.당신이 현명하게 빠져나갈 수 있는 최소한의 서버는 apache, php 및 mysql을 실행하는 2대입니다.하나의 DBMS를 다른 DBMS의 슬레이브로 설정합니다.어떤 이유로 방금 읽은 데이터를 다시 읽을 필요가 없는 경우(마스터 사용)를 제외하고 마스터에 대한 모든 쓰기 및 로컬 데이터베이스에 대한 모든 읽기 작업을 수행합니다.노예를 자동으로 승진시키고 마스터를 철책할 수 있는 장비를 갖추었는지 확인합니다.웹 서버 주소에 라운드 로빈 DNS를 사용하여 슬레이브노드에 대한 어피니티를 높입니다.

이 단계에서 데이터를 다른 데이터베이스 노드에 분할하는 것은 매우 좋지 않습니다.단, 같은 서버상의 다른 데이터베이스 간에 분할하는 것을 검토해 주십시오(Facebook을 추월하면 노드 간 분할이 용이해집니다).

사이트의 퍼포먼스를 측정하고 병목현상을 특정할 수 있는 감시 및 데이터 분석 툴이 준비되어 있는지 확인합니다.대부분의 성능 문제는 SQL을 더 잘 작성하거나 데이터베이스 스키마를 수정함으로써 해결할 수 있습니다.

템플릿 캐시를 데이터베이스에 보관하는 것은 어리석은 생각입니다.데이터베이스는 구조화된 데이터의 중앙 공통 저장소가 되어야 합니다.템플릿 캐시를 웹 서버의 로컬 파일 시스템에 보관합니다. 더 빨리 사용할 수 있고 데이터베이스 액세스 속도가 느려지지 않습니다.

op-code 캐시를 사용하십시오.

많은 시간을 들여 사이트와 로그를 조사하여 왜 이렇게 느려지는지 파악해 보십시오.

클라이언트에 가능한 한 많은 캐시를 푸시합니다.

mod_gzip을 사용하여 가능한 모든 것을 압축합니다.

c.

제 첫 번째 조언은 이 문제를 생각하고 사이트를 설계할 때 염두에 두되 무리하지 말라는 것입니다.새로운 사이트의 성공을 예측하는 것은 종종 어렵습니다.그리고 저는 당신의 시간을 일찍 끝내고 나중에 최적화하는 데 쓰는 것이 더 나을 것입니다.

일반적으로 Simple이 빠릅니다.템플릿에 의해 속도가 느려집니다.데이터베이스로 인해 속도가 느려집니다.복잡한 라이브러리로 인해 속도가 느려집니다.템플릿을 서로 겹쳐서 데이터베이스에서 가져와 복잡한 라이브러리에서 해석하는 경우 --> 시간 지연은 서로 증가합니다.

기본적인 사이트를 확립하고 실행한 후 테스트를 실시하여 어디에 노력을 들여야 하는지를 나타냅니다.어디를 겨냥해야 할지 알 수가 없어요.대부분의 경우 작업 속도를 높이기 위해 코드의 복잡성을 풀어야 합니다.이 때문에 코드의 크기가 커지고 유지보수가 어려워지기 때문에 필요한 경우에만 작업을 수행할 수 있습니다.

제 경험으로는 데이터베이스 접속을 확립하는 데 비교적 많은 비용이 들었습니다.무사히 빠져나갈 수 있다면, 사이트의 1면 페이지와 같이 트래픽이 가장 많은 페이지에서 일반 방문자용 데이터베이스에 연결하지 마십시오.데이터베이스 접속을 여러 개 작성하는 것은 거의 도움이 되지 않습니다.

@개리

MySQLi 사용 안 함 - PDO는 '현대' OO 데이터베이스 액세스 계층입니다.사용하는 가장 중요한 기능은 쿼리의 자리 표시자입니다.서버측 준비 및 기타 최적화 기능을 사용할 수 있을 만큼 스마트합니다.

지금 PDO에 대해 알아보고 있는데, 당신 말이 맞는 것 같습니다. 하지만 MySQL이 PHP용 MySQLd 확장을 개발하고 있다는 것은 알고 있습니다. MySQL 또는 MySQLi 중 하나를 성공시킬 것으로 생각합니다. 어떻게 생각하십니까?

---

@Ryan, Eric, tj9991

PHP의 캐싱 확장에 대한 조언에 감사드립니다. 다른 캐싱 확장자를 사용하는 이유를 설명해 주시겠습니까?IRC를 통해 memcached에 대해 좋은 말은 들었지만 APC에 대해서는 들어본 적이 없습니다.그들에 대해 어떻게 생각하십니까?여러 개의 캐싱 시스템을 사용하는 것이 상당히 역효과적이라고 생각합니다.

반드시 프로파일링 테스터를 분류하겠습니다.그들에 대한 당신의 추천에 감사드립니다.

MySQL에서 곧 전환한다고는 생각하지 않습니다.그래서 PDO의 추상화 기능은 필요 없다고 생각합니다.DavidM 기사 덕분에 많은 도움이 되었습니다.

Apache 웹 서버의 출력 캐시인 mod_cache를 ASP의 출력 캐시와 유사하게 조사합니다.그물.

네, 아직 실험적인 건 알겠지만 언젠가는 최종안이 될 거예요.

모듈화와 추상화라는 것을 아무도 이미 언급하지 않았다니 믿을 수 없다.사이트가 많은 기계로 확장되어야 한다고 생각하는 경우, 가능한 한 많은 기계로 확장할 수 있도록 설계해야 합니다.즉, 데이터베이스가 로컬호스트에 있다고 가정하지 않는 등의 어리석은 일을 의미합니다.또한 데이터베이스 추상화 레이어(PDO 등)를 작성하는 등 처음에는 번거로운 작업도 수반됩니다.

그리고 그것은 틀로 작업하는 것과 같은 것을 의미합니다.데이터 추출 레이어를 리팩터링함으로써 나중에 성능을 얻을 수 있도록 코드에 레이어가 필요합니다.예를 들어, 일부 오브젝트가 다른 데이터베이스에 있는 것을 학습함으로써 코드에 대해 알거나 신경 쓸 필요가 없습니다.

마지막으로 불필요한 문자열 복사 등 메모리 사용량이 많은 작업에 주의하십시오.PHP의 메모리 사용량을 줄일 수 있다면 웹 서버에서 더 높은 성능을 얻을 수 있으며 부하 분산 솔루션을 사용할 때 확장됩니다.

대량의 데이터를 캐싱해도 데이터를 줄일 수 없는 경우 스핑크스를 확인하십시오.우리는 더 나은 텍스트 검색뿐만 아니라 더 큰 테이블을 다룰 때 MySQL의 데이터 검색 대체 수단으로 SphinxSearch를 사용함으로써 좋은 결과를 얻었습니다.SphinxSE(MySQL 플러그인)를 사용하는 경우 캐싱으로 인한 성능 향상을 여러 번 초과하여 애플리케이션 구현이 매우 어렵습니다.

캐시에 관한 포인트는, 효율적인 애플리케이션 구축에 있어서, 가장 복잡하지 않고, 가장 중요한 부분입니다.덧붙여서 memcached는 훌륭하지만 어플리케이션이 1대의 서버상에 있는 경우 APC는 약 5배 고속입니다.

MySQL Performance 블로그의 "Cache Performance Comparison" 게시물에는 http://www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/이라는 주제에 대한 몇 가지 흥미로운 벤치마크가 있습니다.

언급URL : https://stackoverflow.com/questions/24675/tactics-for-using-php-in-a-high-load-site