Сколько пользователей может обрабатывать WordPress?

Согласно структуре базы данных WordPress, ID в таблице wp_users имеет тип Bigint(20) UNSIGNED, поэтому "теоретически" можно добавить 18446744073709551615 пользователей. http://dev.mysql.com/doc/refman/4.1/en/integer-types.html

Отвечаю с небольшим опозданием, но так как этот вопрос актуален в поиске, мой ответ может кому-то пригодиться:

WordPress использует схему базы данных EAV (Entity-Attribute-Value) для части своей реализации. Это касается как данных, так и пользователей. (Они хранятся в отдельных таблицах)

Поясню на примере данных:

Помимо непосредственно доступных деталей записи в таблице wp_posts, многочисленные метаданные хранятся в таблице wp_postmeta для каждой записи. Это любые данные, относящиеся к записи (или пользовательскому типу записи).

Проблема в том, что при большом количестве записей или страниц (или пользовательских данных), поиск по любому свойству, находящемуся в метаполях, становится очень медленным. Сначала вы ищете все записи в таблице метаданных по нужному критерию, затем получаете соответствующие записи из основной таблицы. Причем каждый критерий нужно искать отдельно. Например, сначала ищете по тегу, получаете ID записей со значением X для 'meta1', затем ищете по второму критерию (например, customcriteria) и получаете ID записей со значением customcriteriavalue1 в customcriteria, после чего находите пересечение этих ID и только затем получаете детали записей из таблицы wp_posts по этому пересечению.

Для примера - добавьте 30 000 товаров в WooCommerce, и вы получите около 1 800 000 строк в wp_postmeta, как объясняется в этом ответе:

Метаданные записи vs отдельные таблицы базы данных

Таким образом, это делает поиск крайне неэффективным (особенно при использовании self-join в wp_postmeta для нескольких критериев), и даже запрос одной строки из 1,8 миллиона строк влияет на производительность.

Недостаток схемы EAV.

Таким образом, при большом количестве записей реализация базы данных WordPress делает сложные поиски очень медленными.

Запуск сайта на 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 обслуживает даже более 40 000 пользователей, но они используют сверхмощные системы для стабильности, множество балансировщиков нагрузки и так далее.

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

Если предположить, что у всех пользователей есть хотя бы одна роль, то в таблице user_metadata у них будет запись wp_capabilities, содержащая сериализованный массив ролей.

Страница администрирования отображает количество пользователей для каждого типа роли, поэтому она должна загрузить каждый сериализованный массив wp_capabilities, десериализовать его и затем показать общее количество.

Когда у меня 300 000 пользователей, страница администрирования пользователей загружается за 44 секунды.

Это означает, что каждый пользователь добавляет 0,00014666666 секунд к времени загрузки страницы.

Если предположить, что время ожидания PHP составляет 60 секунд, то предел будет около 400 000 пользователей.

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

Вопрос должен быть не в том, сколько пользователей может обработать стек php-mysql, а в том, сколько может обработать WordPress, поскольку WP разработан на основе этих двух основных технологий.

Учитывая это, если вы можете настроить сервер с использованием продвинутых серверных техник, разместить WordPress на хорошо управляемом сервере, оптимизировать нагрузку на базу данных и запросы, то WP сможет обрабатывать столько пользователей, сколько вам нужно.

Если вы устанавливаете WordPress на shared-хостинг, то вы ограничиваете возможности вашего WP. С другой стороны, если вы можете самостоятельно управлять размещением WordPress на облачном или выделенном сервере, то сможете достичь желаемого результата.

WordPress способен обрабатывать сложные запросы к базе данных. Вы можете ознакомиться с этим руководством: https://codex.wordpress.org/Installing_WordPress (установка WordPress).

Кроме того, использование WordPress в качестве продвинутого фреймворка для разработки приложений позволяет сделать вашу установку способной обрабатывать большие и сложные нагрузки на базу данных.

Также вы можете ознакомиться с этой серией статей: http://code.tutsplus.com/articles/using-wordpress-for-web-application-development-wp_user_query--wp-35015 (использование WordPress для разработки веб-приложений).

Надеюсь, это поможет. Спасибо.