Performance / Charge : marché

Offre

une offre ouverte ayant passé le contrôle qualité et citant au moins deux technologies

Candidat observé

un candidat dont la stack contient cette technologie ; un agrégat — aucune fiche individuelle ne sort du périmètre

Candidat correspondant

pas encore compté

Fenêtre

offres ouvertes au moment de la création de l'instantané

Top-5: ci/cd, cloud, jmeter, grafana, git. Load generation tools: k6 (from Grafana Labs, scenarios in JavaScript — modern dominant 2024–2026, fits great in CI/CD), JMeter (Apache — classic, GUI + large plugin set, still massively used), Gatling (on Scala / Java — high performance, code-as-test), Locust (on Python — convenient for Python teams), Yandex.Tank (relevant in CIS), Artillery (Node.js), enterprise — BlazeMeter / LoadRunner / NeoLoad. Observability / APM (analysis — half the work of performance engineer): Grafana + Prometheus, Datadog, New Relic, Dynatrace, Elastic / OpenTelemetry. Adjacent: HTTP and protocol understanding, basic SQL and slow query analysis, profilers (for JVM / Go / Python), Docker + Kubernetes, CI/CD (running load tests in pipeline), Git. Key skill — not "press a button" but design a realistic load scenario and correctly interpret metrics (latency percentiles, error rate, resource utilization).

k6 — modern default choice 2024–2026: scenarios written in code on JavaScript, integrates well into CI/CD, native Grafana integration, lightweight and fast. Minus — for very complex protocols plugin ecosystem smaller than JMeter. JMeter — veteran (Apache): GUI for scenario assembly (low entry threshold), huge plugin set, support for many protocols; still massively used and often mentioned in vacancies. Minuses — heavyweight, GUI scenarios version worse in Git. Gatling — high performance of one machine, scenarios in code (Scala / Java / Kotlin DSL), beautiful reports; slightly higher entry threshold. Locust — scenarios in pure Python, convenient if team is already Python-oriented, easily extended. Strategy 2026: learn k6 as main (trend + CI/CD-friendliness), know JMeter (still a lot of it in vacancies and legacy projects). Gatling / Locust — by team context. Main thing — tool is secondary; primary is ability to model load and analyze bottlenecks.

Load test — system under expected normal and peak load: checking if SLA holds for latency and errors. Stress test — load beyond rated: looking for the point where system breaks, and if it breaks "gracefully" (graceful degradation) or catastrophically. Soak / endurance test — moderate load for many hours or days: catching memory leaks, log growth, connection pool exhaustion, degradation over time. Spike test — sharp load surge (sale, mailing, viral traffic): how system reacts to sudden surge and recovers. Scalability test — how performance changes when adding resources (horizontal / vertical scaling), linearly or not. Volume test — behavior with large data volumes in DB. Capacity planning — based on results, determining how many resources are needed for planned growth. Senior performance engineer picks test types by risks of specific system, not "runs everything in a row".

Roles are adjacent and overlap. Performance QA / Load Testing Engineer — focus on testing: designs load scenarios, runs tests before release, records if system holds SLA, logs performance defects. Works in QA process. Performance Engineer — broader: not only finds problem, but optimizes — gets into code, DB, configuration, profiles, does capacity planning; closer to development. SRE (Site Reliability Engineer) — responsible for reliability and performance of system in production: monitoring, SLO / error budget, incident management, load as part of operations (see /research/devops/sre). Boundary: Performance QA checks performance before release in test environment; SRE follows it in production; Performance Engineer connects testing with optimization. Career flow often goes Performance QA → Performance Engineer → SRE (with growth of salary and responsibility). Many vacancies mix these roles — look at responsibilities, not title.

Yes, 21% of Performance vacancies — remote or hybrid. Load testing well suits remote: load generated from cloud, analysis runs on APM dashboards, access to test stands — by VPN. Russian high-load employers (banks, telecom, e-commerce) offer both office and hybrid and remote. English — needed for international market and for reading tool / APM documentation. Performance — narrow specialization, so geography of vacancies is wider than seems: specialist shortage works in engineer's favor.

Performance — rarely first role; more often come from functional / automated QA, backend or DevOps. Roadmap: 1) Base — how web application is structured: HTTP, client-server, DB, queues, cache, load balancers; what is latency, throughput, percentiles. 2) Load tool — start with k6 (great documentation, JavaScript) or JMeter (GUI, low threshold); learn to write realistic scenarios (not just "hit one endpoint"). 3) Load modeling — load profiles, ramp-up, think time, data correlation, parameterization. 4) Observability — Grafana + Prometheus: learn to read dashboards, understand what application and infrastructure metrics show. 5) Bottleneck analysis — where the "chokes" are: DB (slow queries, blocks, connection pool), CPU, memory and GC, network, external integrations. 6) SQL and basic DB understanding — mandatory (DB — most common bottleneck). 7) CI/CD — running load tests in pipeline. 8) Pet project: take an open application, write a load scenario on k6, raise Grafana + Prometheus, find a bottleneck, describe conclusions. Resources: k6 and JMeter documentation, book «The Art of Application Performance Testing» (Ian Molyneaux), Brendan Gregg materials on performance, load testing courses (Otus, Stratoplan, testing schools). Main thing in Performance engineer's resume — cases of found and explained bottlenecks, not list of tools.

28 active open jobs on performance / load testing in Zorky sample — narrow specialization with targeted but stable demand. Geography: the US, India, Poland. Demand concentrates in industries with real high-load (fintech, telecom, e-commerce, gaming, government sector), so vacancies are few in number, but they're well paid. Time to fill — 6-10 weeks (shortage of specialists on both sides). Shortage works in engineer's favor — stably high pay.

Senior Performance engineer — engineer understanding the system as a whole, not "operator of load tool". Load tools: expert command of k6 / JMeter / Gatling, design of complex realistic scenarios (correlation, parameterization, load profiles). Architecture: understanding of distributed systems structure — DB, caches, queues, balancers, microservices, external integrations; ability to build hypotheses where bottleneck will be. Bottleneck analysis — main skill: problem diagnosis in DB (slow queries, blocks, connection pools, indexes), CPU, memory and GC (for JVM / Go / .NET), network, concurrency. Observability: free work with APM (Grafana / Prometheus / Datadog / Dynatrace), building dashboards, correlating load test metrics with system metrics. SQL and DB: advanced level — DB most often is the bottleneck. Profiling: profilers for project stack, flame graphs. Capacity planning: based on results, forecasting resource needs for growth. CI/CD: automation of load tests in pipeline, performance gates. Coding: confident scripting (JavaScript / Python / Java — depends on tool). Communication: ability to explain to development and management the essence of the problem and justify recommendations with numbers. English — for international market and documentation. The main value of Senior — not a report «system held N RPS», but a specific bottleneck diagnosis and justified recommendation.