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


10

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

Я не уверен в этом, поэтому я прекращаю свою работу здесь. Поэтому, пожалуйста, помогите мне, если кто-нибудь точно знает об этом, чтобы продолжить мой проект с WP.

Ответы:



6

Немного поздно, чтобы ответить на этот вопрос, но так как он подходит для релевантного поиска, он пригодится кому-то:

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

Чтобы объяснить это с точки зрения данных:

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

Проблема в том, что если у вас есть HEAPS постов или страниц (или пользовательских постов / данных), то поиск любого свойства, найденного в meta, становится довольно медленным. Сначала вы ищете во всех записях мета-таблицы необходимые критерии, а затем получаете соответствующую запись из таблицы. Главное, что вам нужно искать КАЖДЫЙ критерий отдельно. Таким образом, при поиске по тегу вы получаете сообщения со значением X для «meta1», затем вы ищете второй критерий, скажем, customcriteria, и получаете идентификаторы записей с customcriteriavalue1 в customcriteria, и затем берете их пересечение и затем переходите к детали сообщения из таблицы сообщений с этим пересечением.

В качестве примера - поместите 30 000 продуктов в WooCommerce, и вы получите ~ 1 800 000 строк в 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, чтобы ускорить такой поиск.


5

Я думаю, что вы можете запустить еще больше пользователей. Единственное, что может вас ограничить - это ваш сервер. Вам придется масштабировать его правильно, особенно сервер MySQL. Например, wordpress.comработает более 40000 пользователей, но они используют сверхмощные системы для обеспечения стабильности, тонны балансировщиков нагрузки и т. Д.


4

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

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

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

Wordpress способен обрабатывать сложные базы данных. Вы можете проверить это https://codex.wordpress.org/Install_WordPress

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

Вы также можете просмотреть эту серию: http://code.tutsplus.com/articles/using-wordpress-for-web-application-development-wp_user_query--wp-35015

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


Для справки, PHPчасть стека не будет вашей проблемой (Facebook построен с модифицированным PHP), но MySQLвполне может быть ограничением.
Дан

3

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

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

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

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

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

Предполагается, что ваш тайм-аут PHP составляет 60 секунд, что ограничит 400 000 пользователей.

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


Я не думаю, что воздействие является линейным, но я согласен с его сущностью, это не столько число, сколько то, для чего вы фактически используете информацию, и где / когда вы получаете к ней доступ
Марк Каплун
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.