Пользовательское поле JIRA работает медленнее в производственной среде при доступе к базе данных - PullRequest
Новая
       7

Пользовательское поле JIRA работает медленнее в производственной среде при доступе к базе данных

2 голосов
/ 10 февраля 2012

Я развернул плагин настраиваемого поля «Клиент» в JIRA, который обращается к базе данных SQL Server на сервере.Что происходит, когда я иду, чтобы отредактировать проблему, если у меня включено настраиваемое поле, тогда загрузка веб-страницы занимает дополнительные 2-3 секунды.Если я затем перейду и отключу настраиваемое поле, задержки вообще не будет, страница загружается мгновенно, поэтому она определенно связана с этим новым настраиваемым полем.Также важно отметить, что в среде разработки вообще нет задержки, независимо от того, включено пользовательское поле или нет.

Это странно, потому что драйвер SQL, который я использую в ОБА производственной среде и среде разработкиявляется «net.sourceforge.jtds.jdbc.Driver».Кроме того, URL-адрес, который я использую для доступа к базе данных клиентов в ОБА производственной среде и среде разработки, снова совпадает: jdbc: jtds: sqlserver: //: ". Также используется та же самая версия драйвера: jtdsверсия 1.2.4.

Я не могу думать ни о чем другом, что могло бы вызвать проблему.

Любая помощь будет высоко ценится.

Спасибо всем.

1 Ответ

2 голосов
/ 10 февраля 2012

Что ж, до сих пор практически нет ничего необычного в средах производства и разработки, которые на расстоянии считаются идентичными, но на самом деле это не так;)

Например, настраивает ли произвольное поле «тяжелые» операции SQL случайно? В этом случае даже незначительные различия между средами dev и ops могут иметь все значение в итоге:

  • Версия SQL Server и сведения о конфигурации
  • Версия драйвера JDBC (вы уже это проверили)
  • Версия JIRA и сведения о конфигурации
  • Любая существенная разница в оборудовании может иметь аналогичные последствия, например, доступная память, скорость памяти, скорость жесткого диска, производительность процессора, количество ядер и т. д.

Лучший подход в подобных случаях - почти всегда пытаться выявить узкое место по фактическим измерениям, будь то с помощью инструментов кода или мониторинга SQL-сервера или решений внешнего мониторинга - особенно последние два должны помочь вам определить медленные запросы SQL, если есть.

Удачи!

...