Skip to content
SAYGINSOFT BİLİŞİM HİZMETLERİ

Solutions · 04

Performance Engineering

We find the cause of slowness, not the symptom. We trace bottlenecks to their root cause with data and apply measurable, lasting improvements.

01Problems we solve

What organisations most often face in this area.

  • P.01

    Slowdowns at peak hours

    The application slows at certain times of day; the problem is intermittent and hard to catch.

  • P.02

    Plan regressions

    A query that was fast yesterday is slow today; a statistics or parameter change broke its plan.

  • P.03

    Blocking and deadlocks

    Concurrent transactions wait on each other; users see timeouts and errors.

  • P.04

    Solving with hardware

    Every slowdown is met with more CPU and memory; cost rises and the problem returns.

02Diagnostic view

From symptom to root cause: three perspectives.

Performance work does not start from a single metric. The wait profile, query plan history and waits between sessions are read together.

Illustrative example — not real client data

Wait Statistics breakdown

Relative share — shows where the system spends its time waiting.

  • PAGEIOLATCH_*

    Waiting for data pages from disk

  • LCK_M_*

    Lock waits (blocking)

  • CXPACKET / CXCONSUMER

    Parallel query coordination

  • WRITELOG

    Writing to the transaction log

  • SOS_SCHEDULER_YIELD

    CPU pressure

Query Store — plan regression

Plan APlan BPlan changeRoot cause removed

Query duration over time; a statistics change leads to a new plan that takes longer. The fix is to remove the cause, not just force a plan.

Blocking chain

Session 51 — open transaction

  • Session 63 — update
  • Session 72 — report query
  • Session 88 — update

We find the session at the head of the chain and fix the transaction and query pattern causing the wait.

On PostgreSQL the same method uses pg_stat_statements, pg_stat_activity, pg_locks and EXPLAIN (ANALYZE, BUFFERS).

03Our approach

How we work.

  1. 01

    Measure

    Wait profiles, resource consumption and the most expensive queries are identified; a baseline is set.

  2. 02

    Root-cause analysis

    Query Store, DMV and Extended Events data trace the problem from symptom to cause.

  3. 03

    Controlled improvement

    Index, query and configuration changes are tested and applied with a rollback plan.

  4. 04

    Verify impact

    Improvements are measured against the baseline; regressions keep being watched.

04Technical scope

Engineering depth.

Diagnosis

  • Query Store analysis
  • Wait Statistics review
  • DMVs and Extended Events
  • PostgreSQL: pg_stat_statements, EXPLAIN (ANALYZE)

Optimisation

  • Index analysis and design
  • SQL code optimisation
  • Query plan and statistics management
  • Configuration tuning

Concurrency

  • Blocking analysis
  • Deadlock analysis
  • Isolation level review
  • Resource usage optimisation

05Value to the organisation

What changes for management.

Lasting gains

The problem is not patched over; its cause is removed, so it does not return.

Resource efficiency

More work from existing hardware; unnecessary investment avoided.

Measurable results

Each improvement is reported with before-and-after data.

Related solutions

Let's review your environment together.

Let's clarify the current state with a discovery call or a health assessment and set priorities together.

Talk to Our ExpertsSee the health check