Performance Testing i Optymalizacja - Kompleksowy przewodnik 2025

k6 - Modern Developer-Friendly Tool

k6 to open-source load testing tool od Grafana Labs. Scripting w JavaScript/TypeScript, minimal footprint, świetna integracja z CI/CD. Najlepszy wybór dla nowoczesnych DevOps teams.

// k6 load test example
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },  // ramp up to 100 users
    { duration: '5m', target: 100 },  // stay at 100 users
    { duration: '2m', target: 200 },  // spike to 200 users
    { duration: '5m', target: 200 },  // stay at 200 users
    { duration: '2m', target: 0 },    // ramp down to 0
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1000'], // 95% < 500ms, 99% < 1s
    http_req_failed: ['rate<0.01'],  // error rate < 1%
  },
};

export default function () {
  const res = http.get('https://api.example.com/products');

  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 500ms': (r) => r.timings.duration < 500,
  });

  sleep(1);
}

Zalety: JavaScript scripting (łatwy dla web devs), minimal resource usage, built-in metrics, Grafana integration. Wady: No GUI (code only), młodsza społeczność vs JMeter.

Apache JMeter - Industry Standard

JMeter to mature open-source tool od Apache Foundation. GUI-based test creation, ogromna społeczność, support dla legacy protocols (SOAP, FTP, LDAP). Idealny dla enterprise z complex requirements.

Konfiguracja: Thread Groups (users), Samplers (HTTP requests), Listeners (results visualization), Assertions (validation), Timers (think time). XML-based test plans versioned w Git.

Zalety: GUI dla non-coders, plugins ecosystem, distributed testing, wide protocol support. Wady: Heavy resource consumption, XML complexity, slow UI.

Gatling - High-Performance Scala Tool

Gatling to open-source tool napisany w Scala. Asynchronous non-blocking architecture, DSL dla test scenarios, excellent reporting. Najlepszy dla high-load testing (10k+ concurrent users).

// Gatling Scala DSL example
import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._

class ApiLoadTest extends Simulation {

  val httpProtocol = http
    .baseUrl("https://api.example.com")
    .acceptHeader("application/json")

  val scn = scenario("API Load Test")
    .exec(
      http("Get Products")
        .get("/products")
        .check(status.is(200))
        .check(responseTimeInMillis.lte(500))
    )
    .pause(1)

  setUp(
    scn.inject(
      rampUsers(100) during (2.minutes),
      constantUsersPerSec(50) during (5.minutes)
    )
  ).protocols(httpProtocol)
   .assertions(
     global.responseTime.percentile3.lt(1000),
     global.failedRequests.percent.lt(1)
   )
}

Zalety: Highest throughput, reactive architecture, beautiful HTML reports, efficient resource usage. Wady: Scala learning curve, smaller community vs JMeter.

Strategia indeksowania bazy danych

Indeksy to najważniejsza optymalizacja bazy danych. Brakujący indeks na kolumnach w WHERE/JOIN = pełne skanowanie tabeli zamiast szybkiego wyszukania. Różnica? 5ms kontra 5000ms dla tabeli z milionem wierszy. To tysiąckrotna różnica w wydajności aplikacji.

-- PostgreSQL: Znajdź missing indexes
EXPLAIN ANALYZE
SELECT * FROM orders
WHERE customer_id = 123 AND status = 'active';
-- Output: Seq Scan on orders (cost=0.00..25000.00)  <- BAD!

-- Dodaj composite index
CREATE INDEX idx_orders_customer_status
ON orders (customer_id, status);

-- Po dodaniu indexu
EXPLAIN ANALYZE
SELECT * FROM orders
WHERE customer_id = 123 AND status = 'active';
-- Output: Index Scan using idx_orders_customer_status (cost=0.42..8.44)  <- GOOD!

-- Index column order matters!
-- Most selective column first (customer_id przed status)
-- Index na (A, B) obsługuje queries na A lub (A, B), ale nie samo B

Eliminacja N+1 Queries

N+1 problem to klasyczna pułapka ORM. Zamiast 1 zapytania wykonujesz 101 - jedno dla listy, potem po jednym dla każdego elementu. Entity Framework, Hibernate, TypeORM bez eager loading robią to automatycznie. Rezultat? Aplikacja robi 100 razy więcej zapytań niż powinna.

// ❌ BAD: N+1 queries (1 + 100 = 101 queries)
const orders = await db.orders.findMany(); // 1 query
for (const order of orders) {
  const customer = await db.customers.findUnique({
    where: { id: order.customerId }
  }); // N queries (100x!)
  console.log(customer.name);
}

// ✅ GOOD: Eager loading (2 queries lub 1 JOIN query)
const orders = await db.orders.findMany({
  include: { customer: true } // Eager load relationship
});
orders.forEach(order => {
  console.log(order.customer.name);
});

// ✅ ALTERNATIVE: DataLoader pattern (batching + caching)
const customerLoader = new DataLoader(async (ids) => {
  return await db.customers.findMany({ where: { id: { in: ids } } });
});
const orders = await db.orders.findMany();
const customers = await Promise.all(
  orders.map(o => customerLoader.load(o.customerId))
);

Connection Pooling

Tworzenie nowego połączenia do bazy danych jest kosztowne. TCP handshake, uwierzytelnianie, alokacja pamięci - wszystko to zajmuje czas. Connection pool ponownie wykorzystuje połączenia zamiast tworzyć je i niszczyć przy każdym zapytaniu. PgBouncer dla PostgreSQL, HikariCP dla Java - to standard w środowiskach produkcyjnych.

// Node.js pg connection pool configuration
const { Pool } = require('pg');

const pool = new Pool({
  host: 'postgres.example.com',
  database: 'myapp',
  user: 'apiuser',
  password: process.env.DB_PASSWORD,
  max: 20,              // Max connections w pool
  min: 5,               // Min idle connections
  idleTimeoutMillis: 30000,    // Close idle connections po 30s
  connectionTimeoutMillis: 2000, // Timeout getting connection
  maxUses: 7500,        // Recycle connection po 7500 uses
});

// Używaj pool.query() zamiast client.connect()
app.get('/api/orders', async (req, res) => {
  const result = await pool.query('SELECT * FROM orders LIMIT 100');
  res.json(result.rows);
});

// PgBouncer config (external pooler przed PostgreSQL)
// pool_mode = transaction  (best for microservices)
// max_client_conn = 1000   (frontend connections)
// default_pool_size = 25   (backend connections per database)

Query Optimization & Denormalizacja

Czasami znormalizowany schemat bazy danych nie jest optymalny dla aplikacji z dużą liczbą odczytów. Denormalizacja, widoki zmaterializowane, repliki tylko do odczytu - wymieniasz spójność na wydajność aplikacji. To świadomy kompromis, który może przyspieszyć aplikację 10-100 razy.

• • Materialized Views - precomputed query results refreshed periodically
• • Denormalization - duplicate data to avoid JOINs (product.category_name zamiast JOIN categories)
• • Read Replicas - read queries na replicas, writes na primary (PostgreSQL streaming replication)
• • Partitioning - horizontal partition large tables by date/range (orders partitioned by month)
• • Computed Columns - store calculated values (total_price = quantity * unit_price)

Cache-Aside Pattern

Najpopularniejszy caching pattern: aplikacja sprawdza cache przed database query. Cache miss → query DB → zapisz do cache z TTL.

// Cache-aside implementation z Redis
async function getProduct(productId) {
  // 1. Try cache first
  const cacheKey = `product:${productId}`;
  const cached = await redis.get(cacheKey);

  if (cached) {
    console.log('Cache HIT');
    return JSON.parse(cached);
  }

  // 2. Cache miss - query database
  console.log('Cache MISS - querying DB');
  const product = await db.products.findUnique({
    where: { id: productId }
  });

  // 3. Set cache with TTL (5 minutes)
  await redis.setex(cacheKey, 300, JSON.stringify(product));

  return product;
}

// Cache invalidation on update
async function updateProduct(productId, data) {
  const product = await db.products.update({
    where: { id: productId },
    data: data
  });

  // Invalidate cache
  await redis.del(`product:${productId}`);

  return product;
}

CDN Caching - wydajność na brzegu sieci

CDN (Content Delivery Network) cachuje statyczne zasoby (obrazy, CSS, JS, fonty) w serwerowniach blisko użytkowników. Cloudflare, Azure CDN, AWS CloudFront redukują opóźnienie z 200ms do 20ms dla użytkowników na całym świecie. To jak mieć kopię Twojej witryny w każdym mieście.

• • Static assets - długi TTL (1 year), immutable files z hash w filename
• • API responses - krótki TTL (1-5 min), Cache-Control headers, purge on update
• • Image optimization - CDN automatic format conversion (WebP, AVIF), resizing, compression
• • Edge computing - Cloudflare Workers, AWS Lambda@Edge - compute at edge

Cache Invalidation Strategies

"There are only two hard things in Computer Science: cache invalidation and naming things" - Phil Karlton. Stale cache = wrong data shown to users.

• • TTL-based - cache expires after fixed time (300s). Simple, eventual consistency
• • Event-based - invalidate on data change (update/delete triggers cache delete)
• • Tag-based - associate cache entries with tags, invalidate all by tag (product:123 tagged with category:electronics)
• • Write-through - update cache synchronously during write (consistency guarantee, slower writes)

LCP - Largest Contentful Paint (target: <2.5s)

LCP measures loading performance - time until largest visible element renders. Zwykle hero image lub main content block. Slow LCP = users bounce.

• • Image optimization - WebP/AVIF format, srcset responsive images, lazy loading (loading="lazy")
• • Preload critical resources - <link rel="preload" as="image" href="hero.webp">
• • Server-side rendering - Next.js SSR delivers HTML fast, no client-side fetch wait
• • CDN delivery - serve images/fonts z edge locations near users
• • Remove render-blocking resources - async/defer scripts, inline critical CSS

INP - Interaction to Next Paint (target: <200ms)

INP (zastąpił FID w 2024) measures responsiveness - czas od user interaction do visual response. Long tasks (>50ms) blocking main thread = poor INP.

• • Code splitting - dynamic imports, load code on-demand (React.lazy, Next.js dynamic)
• • Minimize JavaScript - tree shaking, remove unused code, bundle size budget
• • Web Workers - offload heavy computation z main thread (data processing, image manipulation)
• • Debounce/throttle - limit high-frequency events (scroll, resize, input)
• • React optimization - useMemo, useCallback, React.memo, virtualization (react-window)

CLS - Cumulative Layout Shift (target: <0.1)

CLS measures visual stability - jak dużo content skacze podczas loading. Layout shifts frustrate users - clicking button → ad loads → button moves → wrong click.

• • Image dimensions - zawsze width/height attributes (reserve space before load)
• • Font loading - font-display: swap, preload fonts, system fonts fallback
• • Ad/embed containers - fixed height dla dynamic content (ads, embeds, iframes)
• • Avoid inserting content - no content injected above existing (banners, notifications)
• • CSS contain - contain: layout dla isolated components (prevents reflow propagation)