Ilu użytkowników może obsłużyć WordPress?

Chcę zaprojektować witrynę logowania członka w WP, ale mam wątpliwości, czy WordPress może obsłużyć ponad 40000 użytkowników w tej samej bazie danych?

Nie jestem tego pewien, więc pochylam się tutaj. Więc proszę pomóż mi, jeśli ktoś dokładnie o tym wie, aby kontynuować mój projekt z WP.

Zgodnie ze strukturą bazy danych WP, identyfikator wp_users to Bigint (20) UNSIGNED, więc można „teoretycznie” dodać 18446744073709551615 użytkowników. http://dev.mysql.com/doc/refman/4.1/en/integer-types.html

Trochę za późno, aby odpowiedzieć na to pytanie, ale od czasu odpowiedniego wyszukiwania, przyda się to komuś:

WordPress używa schematu bazy danych EAV do części swojej implementacji bazy danych. Dotyczy to zarówno danych, jak i użytkowników. (Są przechowywane w osobnych tabelach)

Aby wyjaśnić to z punktu widzenia danych:

Wraz z bezpośrednio dostępnymi szczegółami związanymi z postami w wp_posts, liczne meta są wysyłane do tabeli wp_postmeta dla każdego postu. Wszelkie dane dotyczące posta (lub niestandardowego typu posta).

Problem polega na tym, że jeśli masz HEAPS postów lub stron (lub niestandardowych postów / danych), wyszukiwanie dowolnej właściwości znalezionej w meta jest dość wolne. Najpierw przeszukujesz wszystkie wpisy w meta tabeli pod kątem potrzebnych kryteriów, a następnie dostajesz odpowiedni post z tabeli. Kickerem jest to, że musisz szukać KAŻDEGO kryterium osobno. Więc poszukaj tagu, otrzymujesz posty o wartości X dla „meta1”, a następnie wyszukujesz drugie kryteria, powiedzmy, customcriteria i otrzymujesz identyfikatory postów z customcriteriavalue1 w customcriteria, ORAZ następnie przechodzisz przez ich skrzyżowanie, a następnie idziesz, aby uzyskać szczegóły posta z tabeli postów z tym skrzyżowaniem.

Jako przykład - włóż 30 000 produktów do WooCommerce, a skończysz z ~ 1 800 000 wierszy w wp_postmeta, jak wyjaśniono w poniższej odpowiedzi:

Publikuj meta vs. oddzielne tabele bazy danych

Tak więc, nie tylko spowoduje to, że wyszukiwanie będzie bardzo nieefektywne (szczególnie gdy wykonujesz samodzielne połączenia na wp_postmeta dla wielu kryteriów), ale nawet zapytanie jednego wiersza spośród 1,8 mil wierszy powoduje pogorszenie wydajności.

Niedobór schematu EAV.

Tak więc przy wielu postach implementacja db WordPress sprawia, że ​​złożone wyszukiwanie jest bardzo wolne.

Prowadzenie witryny WordPress z tysiącami postów jest całkiem wykonalne, jeśli używasz wtyczek buforujących. Możesz iść jeszcze więcej. Ale wyszukiwania będą problemem.

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

To samo dotyczy również użytkowników - wp_usermeta używa również tego samego formatu EAV. Więc jeśli masz wielu użytkowników i masz wiele wtyczek, które przechowują różne dane użytkownika w wp_usermeta, podejmiesz ten sam wzrost wydajności.

Nie wspominając już o tak dużej liczbie użytkowników, jest prawdopodobne, że będziesz już mieć dużą liczbę postów - chyba że twoja aplikacja ma coś wspólnego z użytkownikami (CRM itp.) I zdecydujesz się przechowywać dane użytkownika w wp_usermeta zamiast wp_postmeta . (Mało prawdopodobne).

.........

Istnieje kilka wtyczek, które próbują obejść ten problem, na przykład Meta Accelerator.

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

Ta wtyczka pobiera dane dla dowolnego wybranego typu posta i umieszcza je w płaskich tabelach. Przyspiesza to wyszukiwanie, a także przyspiesza wyszukiwanie zapytań o dowolną pojedynczą wartość.

Ale ta wtyczka jest jeszcze w powijakach.

Alternatywnie możesz zainstalować ElasticSearch na serwerze i użyć wtyczki ElasticPress lub innej wtyczki, która integruje ją z WordPress, aby przyspieszyć takie wyszukiwania.

Myślę, że możesz uruchomić jeszcze więcej użytkowników. Jedyne, co może Cię ograniczyć, to Twój serwer. Musisz odpowiednio skalować, zwłaszcza serwer MySQL. Na przykład wordpress.comdziała nawet ponad 40000 użytkowników, ale korzystają oni z wyjątkowo wydajnych systemów zapewniających stabilność, ton równoważenia obciążenia itp.

Pytanie powinno brzmieć, ilu użytkowników może obsłużyć stos php-mysql zamiast WordPress, ponieważ WP jest rozwijany na tych 2 głównych technologiach.

Mówiąc, że jeśli możesz skonfigurować serwer za pomocą zaawansowanych technik serwerowych, umieść WP w dobrze zarządzanym serwerze, zoptymalizowane obciążenie bazy danych i zapytania, wówczas WP może obsłużyć dowolną liczbę członków.

Jeśli zainstalujesz wordpress na hostingu współdzielonym, wówczas ograniczysz swoje możliwości WP. Z drugiej strony, jeśli potrafisz samodzielnie zarządzać WP z chmurowego lub dedykowanego serwera hostingowego, powinieneś uzyskać pożądany rezultat.

Wordpress jest w stanie obsługiwać złożone kamieniołomy baz danych. Możesz sprawdzić to https://codex.wordpress.org/Installing_WordPress

Również użycie wordpess jako zaawansowanego środowiska programowania aplikacji umożliwia wykonanie instalacji w celu obsługi dużego / złożonego obciążenia bazy danych.

możesz również sprawdzić tę serię: http://code.tutsplus.com/articles/using-wordpress-for-web-application-development-wp_user_query--wp-35015

Mam nadzieję, że to pomoże. dzięki

Przekonałem się, jak wielu użytkowników Wordpress może mieć limit czasu PHP, który pojawia się w grze na stronie administratora użytkowników.

Zakładając, że wszyscy użytkownicy mają co najmniej 1 rolę, mają wp_capabilitieswpis w user_metadatatabeli z szeregowym szeregiem ról.

Strona administratora pokazuje liczbę użytkowników z każdym typem roli, więc musi załadować każdą pojedynczą tablicę serializowaną wp_capabilities, odserializować to, a następnie pokazać całkowitą liczbę.

Gdy mam 300 000 użytkowników, strona administracyjna użytkowników zajmuje 44 sekundy.

Oznacza to, że każdy użytkownik dodaje 0,00014666666 sekund do czasu ładowania strony.

Zakładając, że Twój limit czasu PHP wynosi 60 sekund, co ograniczyłoby około 400 000 użytkowników.

Jednak korzystam z dość starego i wolnego serwera. Szybszy sprzęt znacznie poprawiłby sytuację.