워드 프레스는 몇 명의 사용자를 처리 할 수 ​​있습니까?


10

WP에서 회원 로그인 사이트를 디자인하고 싶지만 WordPress가 동일한 데이터베이스에서 40000 명 이상의 사용자를 처리 할 수 ​​있습니까?

나는 이것에 대해 확신하지 못해서 여기에서 내 일을 멈췄습니다. WP로 프로젝트를 진행하기 위해 누군가 이것에 대해 정확히 알고 있다면 도와주세요.

답변:



6

이 답변에 약간 늦었지만 관련 검색이 나오기 때문에 누군가에게 유용 할 것입니다.

WordPress는 데이터베이스 구현의 일부로 EAV 데이터베이스 스키마를 사용합니다. 이것은 데이터와 사용자 모두에게 영향을 미칩니다. (그들은 별도의 테이블에 보관됩니다)

데이터 각도에서 설명하려면 :

wp_posts에서 직접 액세스 가능한 게시물 관련 세부 사항과 함께 수많은 메타가 각 게시물의 wp_postmeta 테이블에 게시됩니다. 게시물과 관련된 모든 데이터 (또는 맞춤 게시물 유형)

문제는 게시물이나 페이지 (또는 사용자 정의 게시물 / 데이터)의 힙이 있으면 메타에서 발견 된 속성을 검색하는 것이 상당히 느려진다는 것입니다. 먼저 메타 테이블의 모든 항목을 검색하여 필요한 기준을 찾은 다음 테이블에서 관련 게시물을 가져옵니다. 중요한 것은 각 기준을 별도로 검색해야한다는 것입니다. 태그를 검색하면 'meta1'에 대해 X 값을 가진 게시물을 얻은 다음 customcriteria와 같은 두 번째 기준을 검색하고 customcriteria에서 customcriteriavalue1을 가진 게시물 ID를 얻은 다음 교차점을 가져 와서 교차점이있는 게시물 테이블의 게시물 세부 정보

예를 들어 WooCommerce에 30,000 개의 제품을 넣으면 wp_postmeta에서 ~ 1,800,000 개의 행이 아래 답변에 설명 된대로 끝납니다.

메타 게시 대 별도의 데이터베이스 테이블

따라서 검색이 매우 비효율적 일뿐만 아니라 (특히 여러 기준으로 wp_postmeta에서 자체 조인을 수행 할 때), 1,8mil 행 중에서 단일 행을 쿼리하더라도 성능이 저하됩니다.

EAV 스키마 부족.

따라서 많은 게시물을 통해 WordPress db 구현은 복잡한 검색을 매우 느리게 만듭니다.

캐싱 플러그인을 사용하면 수천 개의 게시물로 WordPress 사이트를 실행하는 것이 가능합니다. 더 많이 갈 수 있습니다. 그러나 검색은 문제가 될 것입니다.

............

사용자와 동일합니다-wp_usermeta도 동일한 EAV 형식을 사용합니다. 따라서 많은 사용자를 확보하고 wp_usermeta에 다양한 사용자 데이터를 저장하는 플러그인이 많은 경우 동일한 성능 저하를 가져옵니다.

앱이 사용자와 주로 관련이있는 항목 (CRM 등)이 아닌 경우 사용자 데이터를 wp_postmeta 대신 wp_usermeta에 저장하도록 선택하지 않는 한, 많은 사용자에게 이미 많은 게시물이있을 가능성은 말할 것도 없습니다. . (아마도).

.........

Meta Accelerator와 같이이 문제를 해결하려고하는 플러그인이 있습니다.

https://wordpress.org/plugins/meta-accelerator/

이 플러그인은 선택한 게시물 유형에 대한 모든 데이터를 가져와 플랫 테이블에 넣습니다. 이렇게하면 검색 속도가 빨라지고 단일 값 쿼리 속도도 빨라집니다.

그러나 그 플러그인은 아직 초기 단계입니다.

또는 서버에 ElasticSearch를 설치하고 ElasticPress 플러그인 또는 WordPress에 통합 된 다른 플러그인을 사용하여 검색 속도를 높일 수 있습니다.


5

더 많은 사용자를 실행할 수 있다고 생각합니다. 당신을 제한 할 수있는 유일한 것은 서버입니다. 특히 MySQL 서버를 올바르게 확장해야합니다. 예를 들어 wordpress.com40000 명 이상의 사용자 를 실행하지만 안정성, 수많은로드 밸런서 등을 위해 강력한 시스템을 사용합니다.


4

WP가 두 가지 주요 기술로 개발됨에 따라 WordPress 대신 php-mysql 스택 핸들을 사용할 수있는 사용자 수는 몇 명이어야합니다.

고급 서버 기술로 서버를 구성하고, 우수한 관리 서버에서 WP를 호스트하고, 데이터베이스로드 및 쿼리를 최적화하면 WP가 원하는 수의 멤버를 처리 할 수 ​​있다고합니다.

공유 호스팅에 wordpress를 설치하면 WP 기능이 제한됩니다. 반면에 클라우드 기반 또는 전용 호스팅 서버에서 WP를 실행하는 자신을 관리 할 수 ​​있으면 원하는 결과를 얻을 수 있습니다.

워드 프레스는 복잡한 데이터베이스 쿼리를 처리 할 수 ​​있습니다. https://codex.wordpress.org/Installing_WordPress에서 확인할 수 있습니다

또한 고급 응용 프로그램 개발 프레임 워크로 wordpes를 사용하면 설치시 대규모 / 복잡한 데이터베이스로드를 처리 할 수 ​​있습니다.

이 시리즈를 읽을 수도 있습니다 : http://code.tutsplus.com/articles/using-wordpress-for-web-application-development-wp_user_query--wp-35015

이것이 도움이되기를 바랍니다. 감사


레코드 PHP의 경우 스택 의 일부가 문제가되지는 않지만 (Facebook은 수정 된 PHP로 빌드 됨) MySQL제한적 일 수 있습니다.
Dan

4

Wordpress 사용자 수에 따른 병목 현상이 사용자 관리 페이지에서 시작되는 PHP 시간 초과라는 것을 알았습니다.

모든 사용자에게 하나 이상의 역할이 있다고 가정하면 테이블에 일련의 역할 배열 이있는 wp_capabilities항목이 user_metadata있습니다.

관리 페이지에는 각 역할 유형의 사용자 수를 표시하므로 모든 단일 wp_capabilities 직렬 배열을로드하고 직렬화 해제 한 다음 총 수를 표시해야합니다.

30 만 명의 사용자가 있으면 사용자 관리 페이지를 빌드하는 데 44 초가 걸립니다.

이는 각 사용자가 페이지로드 시간에 0.00014666666 초를 추가 함을 의미합니다.

PHP 시간 초과가 60 초라고 가정하면 약 400,000 명의 사용자가 한도를 초과하게됩니다.

그러나 나는 꽤 오래되고 느린 서버를 실행하고 있습니다. 하드웨어가 빠를수록 상황이 크게 개선됩니다.


나는 그 영향이 선형 적이라고 생각하지 않지만 그것의 요지에 동의한다. 그것은 그다지 많은 수는 아니지만 실제로 당신이 정보를 어디에 그리고 언제 / 어떻게 접근하는지에 대한 정보
Mark Kaplun
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.