Добро пожаловать в мой блог! Изначально он не задумывался как блог CRM разработчика, но жизнь сама внесла нужные коррективы. Тут я публикою все свои наблюдения относительно обозначенных в заголовке систем. Если Вы найдете в нем что-то интересное для Вас, как для заказчика, то буду рад сотрудничать с Вами! В моей компетенции 100% задач по MS CRM 3.0/4.0/2011:
MVP 2010, 2011
- Консалтинг
- Проектирование
- Разработка
- Обучение
MVP 2010, 2011
Оптимизация CRM
Запись от Артем Enot Грунин размещена 09.03.2017 в 18:09
Теги administration, performance
Вопрос быстродействия CRM (как и любой другой системы) рано или поздно возникает на любом проекте и на любом железе. Как правило, заказчик винит вас, вы вендора, вендор рекомендует провести контроль качества кода, но все вместе мы забываем о инфраструктуре. Сразу скажу, что я не большой специалист в администрировании разного рода инфраструктурных продуктов, но за годы работы чему-то все равно пришлось научиться. Если вы не наблюдаете деградации производительности системы под нагрузкой - она одинаково сильно тормозит и во время простоя, и во время работы - значит это проблема конфигурации или инфраструктуры.
Итак, краткий перечень операций, которые обязательно нужно проделать на любом проекте и в любой конфигурации системы. Если даже это не помогает - это повод задуматься, и искать проблему в вашем решении.
1. Поднять уровень совместимости базы данных CRM. Современные версии CRM поддерживают современные версии SQL. Тем не менее, даже на чистой инсталляции, базы организации создаются "по шаблону" и имеют Database Compatibility Level соответствующий SQL 2008. Данный факт вынуждает SQL Server работать в режиме совместимости с базой почти десятилетней давности, что негативно сказывается на производительности. Изменения уровня совместимости в свое время рекомендовалось инженерами MS Premier Field Support, однако пруф потерялся, остались только цитированные источники. Как это сделать? https://msdn.microsoft.com/en-us/library/bb933794.aspx. Версию нужно поднимать до последней. Мой опыт говорит, что изменение этого параметра дает солидный выхлоп производительности, особенно в части загрузки списков. Будьте внимательны! В сети встречаются упоминания, что CRM 2016 имеет проблемы с блокировкой для SQL 2014
2. Изменить параметры кэширования IIS. В современных версиях IIS, параметр omitVaryStar должен быть включен по умолчанию, но лучше проверить. Это глобальный параметр, поэтому он влияет на все сайты развернутые на вашем сервере. Как это сделать? http://crmtipoftheday.com/2014/11/18...take-this-pill. Опыт показал, что этот параметр дает ощутимый прирост скорости открытия форм
3. Включить сжатие AJAX и WCF трафика. Еще один глобальный параметр IIS, который официально рекомендуется MS и Premier Field Support: https://blogs.msdn.microsoft.com/crm...rk-performance. Мне показалось, что загрузка формы слегка увеличилась, но не столь ощутимо, как после предыдущих настроек. Помните, что сжатие трафика сильнее нагружает фронт энд, но автоматически выключается при достижении определенного лимита загрузки памяти и процессора
4. Включить поддержку CLR для SQL. Хранимые CLR процедуры более производительны, чем процедуры TSQL, но поддержка CRL по умолчанию выключена из соображений безопасности. Как ее включить? https://msdn.microsoft.com/ru-ru/library/ms131048.aspx. Система должна сама подхватить изменение этого параметра и использовать CLR версии своих процедур. Данный параметр должен существенно влиять на скорость отображения диграмм и панелей мониторинга
5. Если вы используете NLB кластеризацию, вы обязательно должны настроить SPN так как написано в Implementation Guide! Если инсталляция делается под учетной записью с правами на создание SPN, система сама пропишет необходимые SPN для асинхронного сервиса и сервиса песочницы. Для веб приложения их всегда нужно прописывать руками. Если вы этого не сделаете, от вашего кластера будет больше вреда, чем пользы. Почему? Без этого токен авторизации выданный одному фронт-энду не будет работать на другом. Балансировщик нагрузки распределяет запросы случайным образом, поэтому браузеру должно повезти два раза подряд обратится к одному и тому же серверу - первый раз для авторизации, а второй для загрузки веб-ресурса, например, скрипта. Современные браузеры загружают страницы в несколько потоков, что увеличивает шанс получить кромешный ад из access denied и успешных запросов и увеличить нагрузку на сеть.
Чтобы избежать проблем на клиентской части, можно поиграть тонкими настройками CRM OrgDB, такими как DisableIECompatMode: https://support.microsoft.com/en-us/kb/2691237, или указать минимальную версию IE чтобы принудительно обновились идиоты, которые не ставят обновления «потому что потом тормозит», или «потом нужно перезагружаться».
Теперь что касается обслуживания базы данных. Ей нужен хороший админ! Понимаю, что мысль не новая, но ее часто упускают. Только специально обученный человек может правильно настроить бэкапы, создать нужные индексы и т.д. К этой задаче ни в коем случае нельзя подключать разных самоделкиных со скриптами из интернета - нужен реальный специалист, к которым, кстати, я себя НЕ отношу. Что совершенно точно не нужно делать:
• Шринковать базу, чтобы она занимала меньше места
• Создавать все индексы, которые предложил адвайсор, или статистика
• Резать файл лога!!!!
• Заниматься прочей херней, в которой вы не разбираетесь
Если вы делаете что-то из этого - немедленно перестаньте и срочно ищите того, кто может все починить.
Хорошего вам быстродействия!
Итак, краткий перечень операций, которые обязательно нужно проделать на любом проекте и в любой конфигурации системы. Если даже это не помогает - это повод задуматься, и искать проблему в вашем решении.
1. Поднять уровень совместимости базы данных CRM. Современные версии CRM поддерживают современные версии SQL. Тем не менее, даже на чистой инсталляции, базы организации создаются "по шаблону" и имеют Database Compatibility Level соответствующий SQL 2008. Данный факт вынуждает SQL Server работать в режиме совместимости с базой почти десятилетней давности, что негативно сказывается на производительности. Изменения уровня совместимости в свое время рекомендовалось инженерами MS Premier Field Support, однако пруф потерялся, остались только цитированные источники. Как это сделать? https://msdn.microsoft.com/en-us/library/bb933794.aspx. Версию нужно поднимать до последней. Мой опыт говорит, что изменение этого параметра дает солидный выхлоп производительности, особенно в части загрузки списков. Будьте внимательны! В сети встречаются упоминания, что CRM 2016 имеет проблемы с блокировкой для SQL 2014
2. Изменить параметры кэширования IIS. В современных версиях IIS, параметр omitVaryStar должен быть включен по умолчанию, но лучше проверить. Это глобальный параметр, поэтому он влияет на все сайты развернутые на вашем сервере. Как это сделать? http://crmtipoftheday.com/2014/11/18...take-this-pill. Опыт показал, что этот параметр дает ощутимый прирост скорости открытия форм
3. Включить сжатие AJAX и WCF трафика. Еще один глобальный параметр IIS, который официально рекомендуется MS и Premier Field Support: https://blogs.msdn.microsoft.com/crm...rk-performance. Мне показалось, что загрузка формы слегка увеличилась, но не столь ощутимо, как после предыдущих настроек. Помните, что сжатие трафика сильнее нагружает фронт энд, но автоматически выключается при достижении определенного лимита загрузки памяти и процессора
4. Включить поддержку CLR для SQL. Хранимые CLR процедуры более производительны, чем процедуры TSQL, но поддержка CRL по умолчанию выключена из соображений безопасности. Как ее включить? https://msdn.microsoft.com/ru-ru/library/ms131048.aspx. Система должна сама подхватить изменение этого параметра и использовать CLR версии своих процедур. Данный параметр должен существенно влиять на скорость отображения диграмм и панелей мониторинга
5. Если вы используете NLB кластеризацию, вы обязательно должны настроить SPN так как написано в Implementation Guide! Если инсталляция делается под учетной записью с правами на создание SPN, система сама пропишет необходимые SPN для асинхронного сервиса и сервиса песочницы. Для веб приложения их всегда нужно прописывать руками. Если вы этого не сделаете, от вашего кластера будет больше вреда, чем пользы. Почему? Без этого токен авторизации выданный одному фронт-энду не будет работать на другом. Балансировщик нагрузки распределяет запросы случайным образом, поэтому браузеру должно повезти два раза подряд обратится к одному и тому же серверу - первый раз для авторизации, а второй для загрузки веб-ресурса, например, скрипта. Современные браузеры загружают страницы в несколько потоков, что увеличивает шанс получить кромешный ад из access denied и успешных запросов и увеличить нагрузку на сеть.
Чтобы избежать проблем на клиентской части, можно поиграть тонкими настройками CRM OrgDB, такими как DisableIECompatMode: https://support.microsoft.com/en-us/kb/2691237, или указать минимальную версию IE чтобы принудительно обновились идиоты, которые не ставят обновления «потому что потом тормозит», или «потом нужно перезагружаться».
Теперь что касается обслуживания базы данных. Ей нужен хороший админ! Понимаю, что мысль не новая, но ее часто упускают. Только специально обученный человек может правильно настроить бэкапы, создать нужные индексы и т.д. К этой задаче ни в коем случае нельзя подключать разных самоделкиных со скриптами из интернета - нужен реальный специалист, к которым, кстати, я себя НЕ отношу. Что совершенно точно не нужно делать:
• Шринковать базу, чтобы она занимала меньше места
• Создавать все индексы, которые предложил адвайсор, или статистика
• Резать файл лога!!!!
• Заниматься прочей херней, в которой вы не разбираетесь
Если вы делаете что-то из этого - немедленно перестаньте и срочно ищите того, кто может все починить.
Хорошего вам быстродействия!
Всего комментариев 0
