WordPress có thể xử lý bao nhiêu người dùng?


10

Tôi muốn thiết kế một trang đăng nhập thành viên trong WP nhưng tôi có nghi ngờ rằng WordPress có thể xử lý hơn 40000 người dùng trên cùng một cơ sở dữ liệu không?

Tôi không chắc chắn về điều này vì vậy tôi đang cố gắng làm việc ở đây. Vì vậy, hãy giúp tôi nếu có ai biết chính xác về điều này để tiến hành dự án của tôi với WP.

Câu trả lời:



6

Một chút muộn để trả lời điều này, nhưng vì nó được đưa ra để tìm kiếm có liên quan, điều này sẽ được sử dụng cho ai đó:

WordPress sử dụng lược đồ cơ sở dữ liệu EAV cho một phần triển khai cơ sở dữ liệu của nó. Điều này ảnh hưởng đến cả dữ liệu và người dùng. (Chúng được giữ trong các bảng riêng biệt)

Để giải thích nó từ góc dữ liệu:

Cùng với các chi tiết liên quan đến bài đăng có thể truy cập trực tiếp trong wp_posts, nhiều meta được đăng lên bảng wp_postmeta cho mỗi bài đăng. Bất kỳ dữ liệu liên quan đến bài viết (hoặc loại bài tùy chỉnh).

Vấn đề với điều đó là, nếu bạn có HEAPS của bài đăng hoặc trang (hoặc bài đăng / dữ liệu tùy chỉnh), việc tìm kiếm bất kỳ thuộc tính nào được tìm thấy trong meta trở nên khá chậm. Trước tiên, bạn tìm kiếm tất cả các mục trong bảng meta cho các tiêu chí bạn cần, sau đó lấy bài đăng có liên quan từ bảng. Các kicker là bạn cần tìm kiếm các tiêu chí MACHI riêng. Vì vậy, một tìm kiếm cho thẻ, bạn nhận được các bài đăng có giá trị X cho 'meta1', sau đó bạn tìm kiếm các tiêu chí thứ hai, giả sử, tiêu chí tùy chỉnh và nhận id bài đăng với customcriteriavalue1 trong tiêu chí tùy chỉnh, và sau đó đi đến giao điểm của các tiêu chí này và sau đó đi đến giao lộ các chi tiết bài viết từ bảng bài viết với giao điểm đó.

Ví dụ: đưa 30.000 sản phẩm vào WooC Commerce và bạn sẽ kết thúc với ~ 1.800.000 hàng trong wp_postmeta như được giải thích trong câu trả lời dưới đây:

Đăng meta vs bảng cơ sở dữ liệu riêng biệt

Vì vậy, không chỉ điều này sẽ khiến việc tìm kiếm rất kém hiệu quả (đặc biệt là khi bạn tự tham gia trên wp_postmeta cho nhiều tiêu chí), mà thậm chí truy vấn một hàng trong số 1,8 triệu hàng cũng gây ra hiệu quả.

Thiếu lược đồ EAV.

Vì vậy, với rất nhiều bài đăng, việc triển khai db WordPress khiến cho các tìm kiếm phức tạp trở nên rất chậm.

Chạy một trang web WordPress với hàng ngàn bài đăng là hoàn toàn có thể làm được, nếu bạn sử dụng các plugin lưu trữ. Bạn có thể đi nhiều hơn. Nhưng các tìm kiếm sẽ là một vấn đề.

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

Nó cũng giống với người dùng - wp_usermeta cũng sử dụng định dạng EAV tương tự. Vì vậy, nếu bạn nhận được nhiều người dùng và có nhiều plugin lưu trữ dữ liệu người dùng khác nhau trong wp_usermeta, bạn sẽ có hiệu suất tương tự.

Chưa kể với rất nhiều người dùng, có khả năng bạn sẽ có số lượng bài đăng cao - trừ khi ứng dụng của bạn chủ yếu liên quan đến người dùng (CRM, v.v.) và bạn chọn lưu trữ dữ liệu người dùng của mình trong wp_usermeta thay vì wp_postmeta . (Mặc dù không chắc).

.........

Có một số plugin cố gắng giải quyết vấn đề này, như Meta Accelerator.

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

Plugin này lấy bất kỳ dữ liệu nào cho bất kỳ loại bài đăng nào bạn chọn và đặt chúng vào các bảng phẳng. Điều này tăng tốc độ tìm kiếm rất nhiều, và nó cũng tăng tốc truy vấn bất kỳ giá trị số ít nào.

Nhưng plugin đó đang ở giai đoạn sơ khai.

Ngoài ra, bạn có thể cài đặt ElasticSearch trong máy chủ và sử dụng plugin ElasticPress hoặc một plugin khác tích hợp nó vào WordPress để tăng tốc các tìm kiếm như vậy.


5

Tôi nghĩ bạn có thể chạy nhiều người dùng hơn. Điều duy nhất có thể giới hạn bạn là máy chủ của bạn. Bạn sẽ phải mở rộng nó đúng cách, đặc biệt là máy chủ MySQL. Ví dụ, wordpress.comthậm chí chạy hơn 40000 người dùng, nhưng họ sử dụng các hệ thống cực kỳ mạnh mẽ để ổn định, hàng tấn bộ cân bằng tải, v.v.


4

Câu hỏi đặt ra là có bao nhiêu người dùng có thể xử lý ngăn xếp php-mysql thay vì WordPress vì WP được phát triển trên 2 công nghệ chính đó.

Có thể nói, nếu bạn có thể cấu hình máy chủ với các kỹ thuật máy chủ tiên tiến, lưu trữ WP trong một máy chủ được quản lý tốt, tải cơ sở dữ liệu và truy vấn được tối ưu hóa thì WP có thể xử lý nhiều thành viên như bạn muốn.

Nếu bạn cài đặt wordpress trong một lưu trữ được chia sẻ, thì bạn đang giới hạn khả năng WP của mình. Mặt khác, nếu bạn có thể quản lý chính mình đang chạy WP từ máy chủ lưu trữ dựa trên đám mây hoặc dành riêng cho đám mây thì bạn sẽ đạt được kết quả mong muốn.

Wordpress có khả năng xử lý các mỏ đá cơ sở dữ liệu phức tạp. Bạn có thể xem https://codex.wordpress.org/Installing_WordPress này

Ngoài ra, sử dụng wordpess làm khung phát triển ứng dụng nâng cao cho phép bạn cài đặt ur để xử lý tải cơ sở dữ liệu lớn / phức tạp.

bạn cũng có thể chk loạt bài này: http://code.tutsplus.com/articles/USE-wordpress-for-web-application-development-wp_user_query--wp-35015

Hy vọng điều này sẽ giúp. cảm ơn


Đối với bản ghi, PHPphần của ngăn xếp sẽ không phải là vấn đề của bạn (Facebook được xây dựng với PHP đã được sửa đổi), nhưng MySQLrất có thể hạn chế.
Dan

3

Tôi đã tìm thấy cổ chai cho số lượng người dùng Wordpress mà bạn có thể có là thời gian chờ PHP sắp phát hành trên trang quản trị người dùng.

Giả sử tất cả người dùng của bạn có ít nhất 1 vai trò, họ có một wp_capabilitiesmục trong user_metadatabảng với một loạt các vai trò.

Trang quản trị hiển thị tổng số có bao nhiêu người dùng với mỗi loại vai trò, do đó, nó phải tải từng mảng được tuần tự hóa wp_capabilities duy nhất, hủy xác định đó và sau đó hiển thị tổng số.

Khi tôi có 300.000 người dùng, trang quản trị người dùng mất 44 giây để xây dựng.

Điều này có nghĩa là mỗi người dùng thêm 0,00014666666 giây vào thời gian tải trang.

Giả sử thời gian chờ PHP của bạn là 60 giây sẽ đặt giới hạn ở khoảng 400.000 người dùng.

Tuy nhiên tôi đang chạy một máy chủ khá cũ và chậm. Phần cứng nhanh hơn sẽ cải thiện mọi thứ rất nhiều.


Tôi không nghĩ tác động là tuyến tính nhưng tôi đồng ý với ý chính của nó, nó không phải là số lượng nhiều mà là những gì bạn thực sự sử dụng thông tin cho và nơi / khi bạn truy cập nó
Mark Kaplun
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.