Для масштабирования сайтов CMS часто бывает совместимость с сторонними инструментами.
Мой недавний опыт работы с Drupal, но инструменты одинаковы для других инструментов на основе AMP (например, PHP/Apache/MySQL), как и большинство CMS с открытым исходным кодом.
Настоящая ключевая вещь, которую вы определяете для вас, будет совместимость каждой CMS с этими стандартными инструментами для достижения масштабируемости. Это почти более важно, чем конкретные возможности масштабирования самой CMS, которые в большинстве современных CMS (агрессивное кэширование и т. Д.) Практически одинаковы.
Типичные части головоломки для Linux следующие. Вы должны оценить, какая из этих частей имеет значение для вас, и которая будет работать с выбранной вами CMS.
- Лак: Этот обратный прокси-сервер HTTP будет сидеть перед вашим основным веб-сервером и эффективно обслуживать анонимные запросы страниц, где это возможно. Если у вас есть сайт с большим количеством анонимного (не вошедшего в систему) трафика, то Varnish в значительной степени даст вам такую же производительность, какую вы получите, если на вашем сайте были статические HTML-страницы. Улов: ваша CMS должна сотрудничать с лаком либо через дополнительный модуль, либо непосредственно знать, как вести себя за одним из этих прокси. Анонимные страницы должны быть поданы без каких-либо уникальных файлов cookie на них, или Varnish не может это сделать.
- Memcached: Этот кеш объектов в памяти используется в качестве альтернативы кеш-таблицам в вашей базе данных SQL. Как мы все знаем, доступ к памяти в 1000 раз быстрее, чем доступ к диску, поэтому разумно, что если вы храните эти кэшированные биты в памяти, вместо того, чтобы использовать базу данных и вращать диски для запуска запросов .., что ваш сайт будет быть очень быстрым. Также разумно, что вам нужно достаточно ОЗУ для хранения лишних копий материала в памяти.
- Кэширование в CMS: все современные CMS пытаются сделать это, а также могут, это ключ к производительности. Ахиллесовой пятой всех современных CMS является то, что вы не можете действительно кэшировать зарегистрированные данные очень хорошо (т. Е. Панель мониторинга, которая имеет разные характеристики для каждого пользователя).Поэтому, если ваши пользователи вошли в систему, скажем, на сайте сообщества или что-то в этом роде, то ни то, ни другое не будут способствовать этому.
- CDN: Когда люди CMS бросают «использование CDN», они означают пару вещей. Один из них - это то, что звучит, как хосты, такие как статические файлы в сети доставки контента, предоставляемые Google или Amazon или кем-то, и все будет загружаться быстрее. Но другое означает, что нужно настроить несколько параллельных имен DNS для загрузки контента. Ваш браузер будет загружать сразу 6 вещей максимум из одного домена. Если вы делаете: a.example.com, b.example.com, c.example.com, d.example.com, e.example.com, а затем, если ваша CMS поддерживает этот метод CDN, тогда браузер может загрузить 30 вещи одновременно, а не 6 - он может захватить 6 элементов (файлы .css, .js, изображения и т. д.) с каждого из., b., c., d. и e.example.com. Это ускоряет работу сайтов, но снова ваша CMS должна поддерживать его (встроенный или через какой-то дополнительный модуль)
- Репликация базы данных? Это всегда колючий, если вы говорите об этом в MySQL. Независимо от базы данных репликация является трудной проблемой для решения, особенно если она должна быть двухсторонней репликацией (каждая сторона должна читать и писать). Если вы делаете все выше, и покупаете лучшее оборудование, которое можете, и придерживайтесь базы данных на своем высокопроизводительном сервере без каких-либо других сервисов на нем, а хороший быстрый RAID-массив 10 говорит с 6 дисками, чтобы получить действительно потрясающий диск производительность ........ тогда вы, вероятно, могли бы пройти долгий путь с одной основной базой данных. (было бы разумной идеей репликации на резервную машину, если бы у вас были все яйца в одной корзине). В любом случае, к этому моменту вы находитесь в стандартной репликации базы данных ... Ваша CMS может поддерживать несколько записей в базе данных, но в большей степени это вопрос «как вы кластерируете», а не «то, что CMS вы кластеризуете». Я был бы удивлен, если бы какая-либо из современных альтернатив не позволяла вам устанавливать более одного имени базы данных для кластеризации, и вы всегда можете сделать это в DNS, объединив имя хоста вашего DNS-сервера. Опять же, хотя это не связано с вашим выбором CMS.
И для того, чтобы закончить все это, и, чтобы ответить на ваш вопрос, я, конечно же, рекомендую Drupal в качестве надежной масштабируемой CMS. Легко ли масштабировать его, чтобы он запускал сайт, например examiner.com или whitehouse.gov, или университетский сайт с сотнями, если не тысячами субсайтов и миллионами узлов? Черт возьми нет! Кроме того, эта проблема не будет легкой в любой CMS, которую вы выберете. Но вы также должны быть в состоянии выбрать любую современную популярную CMS и заставить ее работать быстро, если вы решите все вышеперечисленное.
Спасибо Костя. Я рассмотрю это. Если есть другие, пожалуйста, продолжайте. – SixfootJames