I created a custom field plugin for JIRA that connects to our SQL Server database to fetch customer information. The plugin works perfectly in our test environment, but when I deployed it to production, I’m experiencing serious performance problems.
When the custom field is active, editing any issue takes an additional 2-3 seconds to load the page. If I disable the field, everything works normally again. The weird part is that our development setup has zero delays with the same configuration.
Both environments use identical database connections - same JTDS driver (version 1.2.4), same connection string format, and same SQL Server instance. I’ve double-checked all the settings and they match exactly.
Has anyone encountered similar database performance differences between JIRA environments? What could cause this slowdown in production only?
check your jira logs for db timeout warnings. prob have network latency with sql server in prod that isn’t in tests. even 50ms/query adds up when custom fields make multiple calls. we faced it too - firewall was inspecting prod traffic but not test!
Sounds like a connection pooling issue. Production has multiple users hitting your custom field at once, which can crush your database connections if they’re not handled right. I had the exact same problem - field worked great in testing but was painfully slow in production. Turned out each field instance was creating its own database connection instead of reusing the pooled ones. Check if your plugin’s actually using JIRA’s connection pooling instead of making direct connections. Also, throw some caching on that customer data if it doesn’t change much. Even a 5-minute cache will cut down database hits big time when multiple users view the same issues. The performance hit you’re seeing gets worse because production users keep hammering the same database queries over and over.
Had this exact issue last year. Query execution plans were totally different between environments, even though the database connections were identical. SQL Server picks different execution paths based on table stats, indexes, and how your data’s distributed. Your production DB probably has way more data than test, so the optimizer’s choosing slower paths. Run your custom field SQL queries directly in Management Studio on both environments and compare the execution plans. I bet production’s doing table scans while test uses indexes properly. Also check if your production database stats are current - outdated stats kill query performance. One more thing: see if your production SQL Server’s getting hammered by other apps. That could explain those consistent 2-3 second delays.