2013-06-05 5 views
4

Нам нужно наше веб-приложение Sitecore для обработки 60-80 веб-запросов в секунду. Мы используем Sitecore 7.0. Мы попробовали развертывание сервера 1 сервера WebServer + 1, но оно обрабатывает только 20-25 запросов в секунду. Веб-сервер ставит в очередь все остальные запросы в памяти. По мере увеличения нагрузки память заполняется. (Мы сделали все улучшения производительности Sitecore). Нам нужна производительность 4X, чтобы достичь цели :).Улучшения производительности Sitecore

Удастся ли достичь этой цели, обновив существующий сервер, или нам нужно добавить больше веб-серверов в производственную среду.

Примечание: Мы также используем индексацию Lucene.

ответ

11

Вот некоторые вещи, которые вы можете рассмотреть без изменения общей архитектуры развертывания

CDN разгрузить СМИ и статический ресурс запросы

Это оставляет сервер доставки контента, доступного для обработки важных запросов контента и отображение логика.

Пример www.cloudflare.com

Настройка и использование Sitecore встроенного кэширования

Это из руководства:

Исследование и конфигурации Sitecore кэшей разбивается на несколько задач , Таким образом, каждая задача более сфокусирована и упрощена. Основное внимание уделяется конфигурации и настройке на Sitecore Database кэшей (упреждающая выборка, данные и пункт кэши.)

Для конфигурации свойств кэширования вывода рендеринга, клиент должен быть осведомлены как конфигурации Sitecore Cache Ссылка и Компонент презентации презентаций Sitecore. Укажите, как правильно включить и свойства для истечения срока действия этих кэшей.

Отъезд Sitecore Tuning Guide

Найти медленных запросов или управления

Это звучит как приложение следует Sitecore передового опыта, но я оставляю эту записку для тех, кто может найти этот ответ. Используйте встроенный режим отладки Sitecore для определения самых медленных элементов управления и подуровней. Кроме того, если у вас установлена ​​Google Analytics, есть отчет «Медленные страницы», который может дать вам некоторую информацию о том, где замедляется ваше приложение.


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

  1. Раздельное Content Delivery и Content Management
    Для меня первый логический шаг, прежде чем балансировки нагрузки серверов доставки контента, чтобы отделить управление контентом из уравнения. Это довольно легко, и Scaling Guide проведет вас через создание HistoryEngine, чтобы обновить индексы Lucene.

  2. Настройка нагрузки Balancer с 2-х или более Content Delivery серверов
    После того, как вы сделали первый шаг, это может быть столь же легко, как клонировать сервер доставки контента и добавить его к балансировки нагрузки «пул». Есть несколько вещей, которые нужно учитывать здесь: поддерживает ли ваше веб-приложение вход в систему? Поэтому вам нужно будет беспокоиться о липких сеансах или машинных клавишах. Использует ли ваше веб-приложение файловый носитель вместо blob-медиа? Мне не приходилось иметь дело с этим, но я понимаю, что это еще одно соображение.

  3. Scale вашего SQL решение
    Я видел приложения с до четыре балансировки нагрузки серверов доставки контента и SQL Server не есть проблема - я думаю, что это будет уникальным для каждого случая в зависимости от многих факторов: лошадиная сила и настройка SQL Server, модель контента вашего приложения, сложность ваших запросов, настройка кеширования на серверах доставки контента и т. д. Опять же, Scaling Guide охватывает SQL-зеркалирование и отказоустойчивость, так что это будет ваша первая остановка на это происходит.


Наконец, я хотел бы сказать, контакт Sitecore. Эти ребята, вероятно, видели больше того, что пошло правильно, и что случилось с установками, и вы можете найти правильный путь. Удачи!

+1

Очень хороший отклик, разделение доставки контента и управление контентом помогут сохранить стабильность при работе редакторов. Вероятно, он не принесет большей производительности при тестировании, но он будет работать в режиме реального времени. Также получите столько кеширования с кешем Sitecore и используйте другие стратегии кэширования для внешних данных (RSS-каналы, устаревшие данные и т. Д.). Также, чтобы обеспечить бесперебойную работу после запуска, обязательно запустите некоторые задания на maintence на SQL Сервер. Самый простой - запустить перестройку один раз в неделю и действительно поддерживать стабильность работы. – Holger

1

Этот ответ написана с точки зрения разработчика Sitecore:

Итог: Вы должны точно выяснить, где узкие места производительности. Это займет некоторое копание, но будет очень полезно. Вы, безусловно, можете без проблем обслужить 60-80 запросов/без каких-либо проблем ... но, конечно, это делает много предположений о характере вашего сайта и запросах.

Для моего сайта я обнаружил, что реализация кэширования Sitecore является субпараметром ... В моем приложении я создал очень простые и агрессивные кэш-приложения для приложений, и это создало все различия в мире. Например, у нас есть 900+ элементов «Партнер», где размещаются рекламные объявления наших сайтов ... и просто поместить все эти объекты в массив в объекте Application значительно ускорил запрос страницы. Поиск объекта в Hashtable, индексированный его Item.Name или ID, будет намного быстрее, чем Sitecore.Context.Database.GetItem («/ itempath») или вызов SelectItems() (по крайней мере, это мой опыт). Если ваша архитектура и набор данных позволят эту стратегию, у нас был хороший опыт.

Еще одна вещь, на которую следует обратить внимание - это визуализация XSLT. Лично я полностью их избегаю в пользу ASP.NET UserControls. Реализация XSLT выполняется медленно. До 10 раз медленнее, чем собственный UserControl, отображающий тот же HTML. Поэтому, если у вас есть несколько таких ... замените какой-то пользовательский код, и вы увидите мир разницы.