О динамике производительности CRM - PullRequest
1 голос
/ 06 мая 2009

Мой начальник попросил меня провести исследование доступных CMS на рынке, потому что используемые нами в настоящее время CMS скорее беспорядок.

Для меня, как разработчика .NET, было бы здорово выбрать и внедрить Dynamics CRM из-за расширяемости и идеальной интеграции со средой .NET и хорошо известными инструментами.

Весь маркетинг звучит замечательно, но я хотел бы знать об общих НЕДОСТАТОКАХ, ВОПРОСАХ, касающихся этой системы.

Наиболее важным является то, как он работает в компании с около 150 одновременными и очень активными пользователями. Я слышал, что это очень медленно по сравнению с системой конкурентов.

Ответы [ 3 ]

2 голосов
/ 14 мая 2009

Команда разработчиков Dynamics CRM опубликовала превосходный технический документ с рекомендациями и тестами для 500 одновременно работающих пользователей. Вы можете многому научиться, изучая эту статью. Ссылка здесь:

Microsoft Dynamics CRM 4.0 Рекомендуемое оборудование для развертывания до 500 одновременно работающих пользователей

1 голос
/ 20 марта 2012

Я не могу дать какого-либо совета о том, как он сравнивается с его ведущими конкурентами. Я знаю, что главное, что это дешевле и очень активно развивается.

Я могу немного рассказать о производительности, которая может помочь.

У нас около 400 - 600 одновременно работающих пользователей. Система не особенно интенсивна для веб-серверов. У нас есть два для обеспечения устойчивости - было бы катастрофой, если бы он отключился, но эти серверы никогда не облагаются налогом. У них есть пара виртуальных ядер и 4 гигабайта оперативной памяти.

Наша база данных имеет размер 130 ГБ и размещена на 24-ядерном сервере базы данных с 48 ГБ ОЗУ. Он кластеризован, но поскольку сервер SQL не может обрабатывать два активных узла, активным является только один сервер.

Сервер баз данных действительно никогда не получает максимальную отдачу. Однако есть одно очень важное изменение, которое нам нужно было сделать, и которое, я думаю, MS советует всем пользователям крупных установок CRM сделать сейчас. По умолчанию SQL Server имеет режим блокировки, который блокирует людей, пишущих в базу данных, когда читается строка. В нашей системе (и, очевидно, многих других) это вызывало огромные проблемы.

Мы включили другой режим (я думаю, что он называется «изоляция моментального снимка») или что-то в этом роде. Чтобы быть справедливым, даже если у вас было 200 одновременных пользователей, это не будет проблемой, пока центральные таблицы, такие как Activitypointer и Account, не станут достаточно большими (в миллионах)

Итак - нет сомнений в том, что CRM 2011 может обрабатывать такое количество пользователей, если у вас есть подходящее оборудование и кто-то, кто понимает SQL Server

НТН

S

1 голос
/ 07 мая 2009

Я не могу ответить относительно количества пользователей / активности. Я могу отослать вас к статье SDK «Рекомендации по повышению эффективности». Я поговорю с вами, кто будет писать плагины (для сообщений о доступе к данным), настраиваемые страницы для доступа к веб-сервисам CRM и писать отчеты SSRS. Пара моментов, к которым я могу отнести:

  1. Отключить плагины. Это привлекательная и важная точка интеграции в CRM. Тот факт, что они считают это проблемой производительности, обескураживает. Мы видели исключения OutOfMemory, происходящие из кэша плагина. Мы обошли эту проблему путем развертывания на диске, а не в базе данных. В базе данных они перезагружают сборку и подтверждают подпись каждый раз, когда вызывается плагин. Мы считаем, что это пожирало кучу больших объектов. Вероятно, не проблема для вашей обычной реализации CRM.

  2. Ограничение полученных данных. Определенно. Избегайте поиска / списков / битов, которые вам не нужны, когда это возможно, поскольку они вызывают дополнительное объединение. Не собирается быть огромным соглашением на меньшие юридические лица. Но если вам нужны объекты с большим количеством атрибутов, это может быть. Вероятно, не проблема для нормальной настройки CRM. Хороший дизайн в других случаях должен избегать этой проблемы.

...