Скільки користувачів може працювати з WordPress?

Я хочу створити сайт для входу в WP, але я сумніваюся, що WordPress може обробляти більше 40000 користувачів на одній базі даних?

Я не впевнений у цьому, тому я перестаю працювати тут. Тож будь ласка, допоможіть мені, якщо хтось точно знає про це, щоб продовжити мій проект із WP

Відповідно до структури бази даних WP, ідентифікатор у wp_users є Bigint (20) НЕЗНАЧЕНО, тому ви могли "теоретично" додати 18446744073709551615 користувачів. http://dev.mysql.com/doc/refman/4.1/uk/integer-types.html

Трохи запізнився відповісти на це, але оскільки він з’явиться для відповідного пошуку, це буде корисно комусь:

WordPress використовує схему баз даних EAV для частини своєї бази даних. Це впливає і на дані, і на користувачів. (Вони зберігаються в окремих таблицях)

Щоб пояснити це з точки зору даних:

Поряд із безпосередньо доступними деталями, пов’язаними з публікацією у wp_posts, у таблицю wp_postmeta для кожної публікації розміщуються численні мета. Будь-які дані, що стосуються публікації (або спеціального типу публікації).

Проблема з цим полягає в тому, що якщо у вас є HEAPS публікацій або сторінок (або користувацьких публікацій / даних), ви можете шукати будь-які властивості, знайдені в мета. Ви спочатку шукаєте всі записи в мета-таблиці за необхідними критеріями, а потім отримуєте відповідну публікацію з таблиці. Найбільше, що вам потрібно окремо шукати критерії EACH. Таким чином, один пошук тегу, ви отримуєте повідомлення зі значенням X для 'meta1', потім шукаєте другі критерії, скажімо, customcriteria і отримуєте ідентифікатори ідентифікаторів пошти з customcriteriavalue1 у customcriteria, а потім берете перехрестя цих, а потім переходите до отримання реквізити допису з таблиці повідомлень із цим перетином.

Як приклад - поставте 30 000 продуктів у WooCommerce, і ви отримаєте ~ 1800000 рядків у wp_postmeta, як пояснено нижче у відповіді:

Опублікувати мета проти окремих таблиць баз даних

Таким чином, не тільки це зробить пошук дуже неефективним (особливо, коли ви самостійно приєднуєтесь до wp_postmeta за кількома критеріями), але навіть навіть запит на один рядок серед 1,8 мільйонів рядків спричиняє хіт на продуктивність.

Дефіцит схеми EAV.

Отже, маючи багато публікацій, впровадження WordPress db робить складні пошуки дуже повільними.

Запуск веб-сайту WordPress з тисячами публікацій цілком здійсненний, якщо ви використовуєте плагіни кешування. Ви можете піти ще більше. Але пошуки будуть проблемою.

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

Те ж саме і з користувачами - wp_usermeta також використовує той самий формат EAV. Отже, якщо ви отримаєте багато користувачів і маєте багато плагінів, які зберігають різні дані користувачів у wp_usermeta, ви приймете той самий показник ефективності.

Не кажучи вже про так багато користувачів, ймовірно, що у вас вже буде велика кількість публікацій - якщо тільки ваш додаток не має відношення до користувачів в основному (CRM тощо), і ви вирішите зберігати свої користувацькі дані в wp_usermeta замість wp_postmeta . (Навряд чи все-таки).

.........

Є деякі плагіни, які намагаються обійти цю проблему, як-от Meta Accelerator.

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

Цей плагін приймає будь-які дані для будь-якого вибраного вами типу публікації та розміщує їх у плоских таблицях. Це значно прискорює пошук, а також прискорює запит на будь-яке особливе значення.

Але цей плагін ще знаходиться в зародковому стані.

Крім того, ви можете встановити ElasticSearch на сервер і використовувати плагін ElasticPress або інший плагін, який інтегрує його в WordPress, щоб прискорити такі пошуки.

Я думаю, ви можете запустити ще більше користувачів. Єдине, що може вас обмежити - це ваш сервер. Вам доведеться правильно її масштабувати, особливо сервер MySQL. Наприклад wordpress.comпрацює навіть більше 40000 користувачів, але вони використовують надзвичайно потужні системи для стабільності, тонни балансирів навантаження і т.д.

Питання має полягати в тому, скільки користувачів може обробляти стек php-mysql замість WordPress, оскільки WP розробляється за цими двома основними технологіями.

Якщо говорити, що якщо ви можете налаштувати сервер за допомогою передових серверних методик, розміщення WP на хорошому керованому сервері, оптимізована завантаження бази даних та запити, то WP може обробляти стільки членів, скільки вам потрібно.

Якщо ви встановите wordpress на спільному хостингу, ви обмежуєте свої WP-можливості. З іншого боку, якщо ви можете керувати роботою WP з хмарного або виділеного хостинг-сервера, тоді ви повинні отримати бажаний результат.

Wordpress здатний обробляти складні кар'єри баз даних. Ви можете ознайомитись із цим https://codex.wordpress.org/Installing_WordPress

Також використання wordpess як розширеної системи розробки додатків дозволяє вам робити встановлення ур для обробки великої / складної завантаження бази даних.

Ви також можете chk цієї серії: http://code.tutsplus.com/articles/using-wordpress-for-web-application-development-wp_user_query--wp-35015

Сподіваюсь, це допоможе. Дякую

Я знайшов горщик пляшки для того, скільки користувачів Wordpress у вас може бути тимчасовий час очікування PHP, який починає грати на сторінці адміністратора користувачів.

Якщо припустити, що всі ваші користувачі мають принаймні одну роль, яку вони мають wp_capabilitiesзаписати вuser_metadata таблиці із серіалізованим масивом ролей.

Сторінка адміністратора показує кількість користувачів з кожним типом ролей, тому вона повинна завантажувати кожен wp_capability серіалізований масив, несеріалізувати це, а потім показувати загальну кількість.

Коли у мене є 300 000 користувачів, адміністратору сторінки користувачів потрібні 44 секунди.

Це означає, що кожен користувач додає 0,00014666666 секунд до часу завантаження сторінки.

Якщо припустити, що час очікування вашого PHP становить 60 секунд, це встановить обмеження приблизно в 400 000 користувачів.

Однак у мене працює досить старий і повільний сервер. Швидше обладнання значно покращить речі.