I've been conducting a detailed performance analysis of various security orchestration platforms, and I've recently set up a fresh, single-node ThreatConnect instance for benchmarking in a controlled lab environment. The hardware is more than adequate: 8 vCPUs, 32GB RAM, and NVMe storage. After the initial setup with a few basic indicators and observables, I'm encountering a perplexing issue that I'd like the community's input on.
Executing what should be a trivial search—such as a simple tag lookup or an indicator value query via the REST API—sometimes results in response times exceeding 30 seconds. This is on a system with virtually no data load and no other concurrent users. The latency is not consistent; it happens sporadically, which makes me suspect it's not a pure query complexity issue but rather something in the underlying stack's warm-up or connection management.
My initial profiling, using `curl` with timing outputs and cross-referencing with server-side logs, suggests the delays are happening at the application layer, not in network transit. The database (PostgreSQL) itself responds to direct, simplified versions of the generated queries in under 100ms.
Here are the specific points I've investigated so far:
* **JVM Warm-up:** As a Java-based application, I considered JIT compilation overhead. However, the sporadic nature suggests this isn't a one-time cold-start cost. It happens intermittently even after the service has been running for hours.
* **Connection Pool Exhaustion/Initialization:** Latency could be introduced if HTTP threads are blocked waiting for a fresh database connection. I haven't yet tuned the default HikariCP or Tomcat JDBC settings.
* **Caching Misconfiguration:** The first query for a particular type might trigger a cache load. If the cache configuration is overly aggressive or has a poor eviction strategy for a small dataset, it could cause overhead instead of benefit.
* **Plugin or Integration Scanning:** I've seen similar behavior in other platforms where background processes periodically scan for plugins or validate license files, momentarily stalling request-handling threads.
Has anyone else performed granular latency analysis on ThreatConnect, particularly on a fresh install? I'm looking to isolate the component—be it the core service, the underlying Solr/Elasticsearch indexing layer (if used), or the database interaction pattern.
My next step is to enable more verbose TRACE-level logging and potentially use APM tools to generate flame graphs of the slow requests. I'm particularly interested in the actual SQL queries being generated and their execution plans during these slow events. Any prior experience or configuration tweaks to mitigate this would be valuable.
--perf
--perf