Public guide
TAFJ Performance Tuning
TAFJ performance is shaped by the JVM, the database, caching, locking, batch design, and the behaviour of local code under load. This guide gives you an indexable public baseline for diagnosing slow Temenos Transact systems without relying on a login-gated redirect.
Practical note
Start with evidence. Capture response times, GC behaviour, database wait signals, cache timings, lock waits, and batch duration before changing configuration. Tuning without a baseline usually moves the bottleneck rather than removing it.
1. Quick Diagnosis Order
When TAFJ is slow, do not begin by increasing heap size. Work through the layers in an order that separates platform pressure from application or database design problems.
- User symptom. Confirm whether the issue is login, OFS, browser screens, COB, reports, or interfaces.
- Time window. Match the issue to deployment, COB, high message volume, backup, restore, or maintenance windows.
- JVM health. Check heap trend, GC pause time, full GC frequency, thread count, and blocked threads.
- Database health. Check connection pool pressure, long-running SQL, blocking, waits, and missing indexes.
- TAFJ runtime behaviour. Review cache read timings, lock manager configuration, batch settings, and local routines.
2. JVM Baseline
TAFJ runs inside the Java Virtual Machine, so heap sizing and garbage collection matter. The goal is a stable live set and predictable pauses, not simply the largest possible heap.
# Example starting point only — validate against your environment -Xms8g -Xmx8g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/tafj/heapdumps
Keep -Xms and -Xmx equal for production-style testing. If heap rises steadily after every busy period and never returns to a stable level, investigate retained objects, cache bloat, and custom routines before raising the heap again.
3. Read the GC Log Before Guessing
The GC log tells you whether the JVM is healthy. Look for full GC events, long pauses, humongous allocations, and a growing old generation.
| Signal | Meaning | Typical action |
|---|---|---|
| Frequent Full GC | Heap pressure or allocation pattern problem | Capture heap dump and review live set |
| Pauses over 1 second | User-facing latency risk | Check heap, object churn, and GC settings |
| Old generation keeps rising | Possible leak or cache growth | Compare heap dumps across time |
| High blocked thread count | Lock or synchronisation contention | Take multiple thread dumps |
4. Database and Query Behaviour
Many TAFJ performance incidents are database incidents wearing an application disguise. A slow screen, OFS timeout, or long COB step may be caused by a missing index, an inefficient select, blocking, or an exhausted connection pool.
-- SQL Server examples EXEC sp_who2; SELECT TOP 20 total_elapsed_time, execution_count, total_logical_reads, text FROM sys.dm_exec_query_stats CROSS APPLY sys.dm_exec_sql_text(sql_handle) ORDER BY total_elapsed_time DESC;
Confirm whether the slow path is a single expensive query, many repeated small queries, or blocking. In TAFJ migrations, repeated reads that were cheap in TAFC can become expensive when each call reaches the database.
5. Cache and Locking
Cache can help, but it can also hide bad access patterns or make a busy table noisier. Review TAFJ cache settings with actual read timings rather than assuming every table should be cached.
- Cache reference-style tables more readily than constantly changing transaction tables.
- Compare cached read time with regular read time before and after a change.
- Check lock waits when COB stalls or browser users queue behind each other.
- Keep lock duration short inside local routines and batch jobs.
6. COB and Batch Throughput
Batch performance depends on record volume, commit frequency, parallelism, query shape, and whether agents are waiting on locks or database work. Make one change at a time and compare full COB duration, step duration, and resource usage.
| Area | What to check |
|---|---|
| Selection | Does the batch select too much data or scan without a useful index? |
| Parallelism | Are agents actually busy, or blocked behind the same resource? |
| Commit frequency | Are commits too frequent or holding too much work for too long? |
| Logging | Is the job writing excessive logs inside tight loops? |
7. Minimum Production Monitoring
A smooth TAFJ environment needs trend monitoring, not only incident checks. Track JVM, database, and TAFJ-specific numbers together so the team can see what changed before users report a slowdown.
- Heap usage, full GC count, and GC pause time.
- Thread count, blocked threads, and datasource pool usage.
- Database blocking, top elapsed SQL, logical reads, and transaction log pressure.
- OFS response time, interface backlog, COB step duration, and cache timing.
Practical note
For Google indexing, this route intentionally returns public content at/guides/tafj-performance. Deeper paid material can still sit behind a separate library flow, but this URL should remain crawlable, canonical, and included in the sitemap.