Skip to main content

gatling

Implements load testing strategies using Gatling for performance testing of web applications and microservices.

설치로 이동

소스 정보

저장소
paulpas/agent-skill-router
최근 소스 활동
2026년 6월 9일 18:00
감지된 SKILL.md 언어
영어
스타
6
포크
0

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
gatling
description
Implements load testing strategies using Gatling for performance testing of web applications and microservices.
license
MIT
compatibility
opencode
metadata
{"version":"1.1.1","domain":"performance","triggers":"load testing, performance testing, Gatling, web applications, microservices","archetypes":["implementation","evaluation"],"anti_triggers":["neglecting load test results","using outdated performance metrics"],"response_profile":{"verbosity":"medium","directive_strength":"high","abstraction_level":"operational"},"role":"implementation","scope":"implementation","output-format":"code"}
## Best Practices for Load Testing with Gatling Load testing is critical for ensuring that applications can handle expected user loads without compromising performance. Gatling is a powerful tool for simulating a large number of requests and assessing application behavior under stress. Here are key practices for effective load testing with Gatling: ### Core Principles: 1. **Scenario Design**: Create realistic user scenarios to simulate various usage patterns effectively, ensuring your tests reflect actual user behavior. 2. **Use Parameterized Tests**: Utilize parameterization in your tests to enhance flexibility and usability. This can include variables for user credentials, URLs, or other dynamic parameters. 3. **Monitor Resource Utilization**: Keep track of resource usage (CPU, memory, response time) during tests to spot performance bottlenecks effectively. ### Security Best Practices: - **Configure Rate Limits**: Always impose rate limits in your load tests to avoid overwhelming production environments inadvertently. - **Data Protection**: Ensure that any sensitive data used in load tests complies with data protection regulations to avoid data leaks. - **Test Environment Usage**: Conduct load tests in a staging environment or during off-peak hours in production to prevent user disruption. ### Example Scenario Implementation with Gatling: A sample scenario for load testing with Gatling might look like this: ```scala import io.gatling.core.Predef._ import io.gatling.http.Predef._ val httpProtocol = http .baseUrl("https://example.com") .acceptHeader("application/json") val scn = scenario("User Login") .exec(http("Login Request") .post("/login") .body(StringBody("{\"username\":\"testuser\",\"password\":\"password123\"}")) .check(status.is(200))) setUp( scn.inject(atOnceUsers(100)).protocols(httpProtocol) ) ``` ### Measuring the Effectiveness of Load Testing: Be sure to track key metrics such as peak response times, average response times, and error rates during load tests to evaluate performance. ### FAQs on Load Testing with Gatling: - **What types of applications can Gatling test?** Gatling is versatile and can test any web application, microservices, and APIs. - **How does Gatling compare with other load testing tools?** Gatling is often preferred for its excellent performance, powerful scripting capabilities, and detailed reporting features. - **How do I set up Gatling for the first time?** Follow the official documentation to install Gatling, set up your testing environment, and begin writing scenarios. By following structured load testing practices with Gatling, organizations can significantly enhance application reliability and performance under varying load conditions, thus assuring positive user experiences even during peak demand periods. --- ## Implementation Patterns ### Advanced Gatling Simulation with Feeders, Checks, and Realistic Pacing A production-grade simulation using CSV feeders, dynamic token extraction, multi-step user journeys, and realistic think time: ```scala import io.gatling.core.Predef._ import io.gatling.http.Predef._ import scala.concurrent.duration._ class AdvancedSimulation extends Simulation { val httpProtocol = http .baseUrl("https://api.example.com") .acceptHeader("application/json") .contentTypeHeader("application/json") .userAgentHeader("Gatling-Performance-Test") val userFeeder = csv("users.csv").circular val productFeeder = Iterator.continually(Map( "productId" -> (scala.util.Random.nextInt(1000) + 1) )) val scn = scenario("Full User Journey") .feed(userFeeder) .exec(http("Login") .post("/auth/login") .body(StringBody("""{"username":"${username}","password":"${password}"}""")) .check( status.is(200), jsonPath("$.token").saveAs("authToken") )) .pause(2, 5) // realistic think time between 2-5 seconds .exec(http("Browse Products") .get("/products") .header("Authorization", "Bearer ${authToken}") .check( status.is(200), jsonPath("$.products[*]").count.gt(0) )) .pause(1, 3) .repeat(3) { feed(productFeeder) .exec(http("View Product Details") .get("/products/${productId}") .header("Authorization", "Bearer ${authToken}") .check( status.is(200), jsonPath("$.name").exists )) .pause(1, 2) } setUp( scn.inject( rampUsers(10).during(10.seconds), constantUsersPerSec(5).during(60.seconds), stressPeakUsers(50).during(30.seconds) ) ).protocols(httpProtocol) } ``` --- ## Constraints ### MUST DO - Design scenarios that reflect real user behavior — include think time (`pause`), navigation paths, and conditional logic - Use `feeders` (CSV, JSON, Iterator) to parameterize test data and avoid cache-biased results - Organize simulations with clear `setUp` injection profiles: `rampUsers`, `constantUsersPerSec`, or `stressPeakUsers` - Enable `reports` and use Gatling's HTML dashboard to analyze response time percentiles, throughput, and errors ### MUST NOT DO - Do not run simulations without first validating the scenario with `--dry-run` or a single-user run - Avoid using hardcoded credentials or tokens — parameterize authentication data through feeders or environment variables - Never ignore `checks` on responses; every request should validate status, headers, or body to ensure correctness - Do not test against production infrastructure without coordinating with the operations team and having rollback plans
GitHub에서 보기