Feature/jmeter update (#217)

* jmeter script update
* Reducing report

Author: jabrena

.cursor/rules/151-java-performance-jmeter.mdc

@@ -113,7 +113,7 @@ show_usage() {
     echo ""
     echo "ENVIRONMENT VARIABLES:"
     echo "  JMETER_LOOPS          Override default number of loops"
-    echo "  JMETER_THREADS        Override default number of threads"
+    echo "  JMETER_THREADS        Override default number of threads"  
     echo "  JMETER_RAMP_UP        Override default ramp-up period"
     echo ""
     echo "EXAMPLES:"
@@ -174,7 +174,7 @@ check_jmeter() {
         print_info "Download from: https://jmeter.apache.org/download_jmeter.cgi"
         exit 1
     fi
-
+    
     JMETER_VERSION=$(jmeter -v 2>&1 | head -n 1 | grep -o 'Version [0-9.]*' | cut -d' ' -f2)
     print_info "Found JMeter version: $JMETER_VERSION"
 }
@@ -201,7 +201,7 @@ clean_previous_results() {
         rm "$RESULTS_FILE"
         print_info "Cleaned previous results file"
     fi
-
+    
     if [[ -d "$REPORT_DIR" ]]; then
         rm -rf "$REPORT_DIR"
         print_info "Cleaned previous report directory"
@@ -215,7 +215,7 @@ run_jmeter_test() {
     print_info "  - Loops: $JMETER_LOOPS"
     print_info "  - Threads: $JMETER_THREADS"
     print_info "  - Ramp-up: $JMETER_RAMP_UP seconds"
-
+    
     # Run JMeter in non-GUI mode
     jmeter -n \
         -t "$TEST_PLAN" \
@@ -226,7 +226,7 @@ run_jmeter_test() {
         -Jthreads="$JMETER_THREADS" \
         -Jrampup="$JMETER_RAMP_UP" \
         -j "$LOG_FILE"
-
+    
     if [[ $? -eq 0 ]]; then
         print_success "JMeter test completed successfully"
     else
@@ -240,13 +240,13 @@ run_jmeter_gui() {
     print_info "Opening JMeter GUI..."
     print_info "Test plan will be loaded: $TEST_PLAN"
     print_info "You can configure and run tests manually in the GUI"
-
+    
     # Run JMeter in GUI mode with test plan loaded
     jmeter -t "$TEST_PLAN" \
         -Jloops="$JMETER_LOOPS" \
         -Jthreads="$JMETER_THREADS" \
         -Jrampup="$JMETER_RAMP_UP"
-
+    
     print_success "JMeter GUI session completed"
 }
 
@@ -256,12 +256,12 @@ show_results() {
     print_info "Results file: $RESULTS_FILE"
     print_info "HTML report: $REPORT_DIR/index.html"
     print_info "Log file: $LOG_FILE"
-
+    
     if [[ -f "$RESULTS_FILE" ]]; then
         TOTAL_SAMPLES=$(tail -n +2 "$RESULTS_FILE" | wc -l)
         print_info "Total samples: $TOTAL_SAMPLES"
     fi
-
+    
     # Try to open the HTML report
     if command -v open &> /dev/null; then
         print_info "Opening HTML report in browser..."
@@ -278,10 +278,10 @@ show_results() {
 main() {
     print_info "JMeter Load Test Script"
     print_info "======================="
-
+    
     check_jmeter
     check_test_plan
-
+    
     if [[ "$GUI_MODE" == "true" ]]; then
         # GUI mode - just open JMeter with the test plan
         run_jmeter_gui
@@ -297,8 +297,7 @@ main() {
 }
 
 # Execute main function
-main "$@"
-
+main "$@" 
 ```
 
 #### Step Constraints

.cursor/rules/161-java-profiling-detect.mdc

@@ -103,6 +103,8 @@ OPTIONS:
     -c, --class CLASS       Main class to run (default: info.jab.ms.MainApplication)
     -h, --heap SIZE         Heap size (default: 512m)
     -p, --profile PROFILE   Profile to activate (default: default)
+                           For Spring Boot: sets spring.profiles.active
+                           For Quarkus: sets quarkus.profile
     --jfr                   Enable Java Flight Recorder (disabled by default)
     --gc-log                Enable GC logging (disabled by default)
     --help                  Show this help message
@@ -122,6 +124,12 @@ EXAMPLES:
     # Force Quarkus with custom heap size and profile
     $0 -f quarkus -h 1g -p dev
 
+    # Run Spring Boot with virtual threads profile
+    $0 -f springboot -p vt
+
+    # Run Spring Boot with development profile
+    $0 -f springboot -p dev
+
     # Run with wall-clock profiling
     $0 -m wall
 

.gitignore

@@ -2,5 +2,4 @@
 target/
 .idea/
 .vscode/
-*.log
 .classpath

README.md

@@ -51,7 +51,7 @@ With this structure in mind, the project uses an XML Schema to define the way th
 
 ## Cursor Rules
 
-Read the generated list of cursor rules for Java [here](./CURSOR-RULES-JAVA.md). The set of cursor rules covers aspects like `Build system based on Maven`, `Design`, `Coding`, `Testing`, `Refactoring`, `Performance testing with JMeter` & `Profiling with Async Profiler`.
+Read the generated list of cursor rules for Java [here](./CURSOR-RULES-JAVA.md). The set of cursor rules covers aspects like `Build system based on Maven`, `Design`, `Coding`, `Testing`, `Refactoring`, `Performance testing with JMeter` & `Profiling with Async profiler, jps, jstack, jcmd & jstat`.
 
 ## Constraints, Output format & Safety guards
 
@@ -61,9 +61,15 @@ The **constraints** act as gate-keeping mechanisms that define hard requirements
 
 This framework transforms AI from a general assistant into a specialized consultant with built-in quality controls and safety measures, making it particularly suitable for critical applications like Java software development. By embedding domain-specific expertise directly into the prompt structure, the cursor rules provide predictable, comprehensive, and safe interactions while reducing cognitive load for developers and ensuring system integrity throughout the development process.
 
-## Limitations & Opportunities
+## Limitations
 
-From the beginning, you need to know that results provided by the interaction with the different `Cursor rules` are not deterministic due to the models' nature, but this fact should not be considered in a negative, Software engineers not always has the same idea to solve a problem, you could find an analogy on this fact.
+### Lack of determinism
+
+From the beginning, you need to know that results provided by the interaction with the different `Cursor rules` are not deterministic due to the models' nature, but this fact should not be considered negative. Software engineers do not always have the same idea to solve a problem, and you could find an analogy in this fact.
+
+### Limits of interactions with Models
+
+Models are able to generate code but they are not able to run code with your local data. In order to solve that limitation you can observe that a few prompts provide scripts to fix the gaps on the model side.
 
 ## Contribute
 

examples/spring-boot-memory-leak-demo/profiler/docs/jmeter-performance-comparison-analysis-20250720.md

@@ -0,0 +1,201 @@
+# JMeter Performance Comparison Analysis - July 20, 2025
+
+## Executive Summary
+- **Analysis Objective**: Compare performance between two JMeter test executions on Spring Boot Memory Leak Demo
+- **Test Executions**: 223808 vs 223856 (timestamps)
+- **Overall Result**: ✅ **Test 1 (223808) demonstrates superior performance**
+- **Key Performance Gain**: 19.3% faster average response times, 4.3% higher throughput
+
+## Test Execution Overview
+
+| Metric | Test 1 (223808) | Test 2 (223856) | Performance Winner |
+|--------|------------------|------------------|-------------------|
+| **Execution Start Time** | 2025-07-20 22:38:08 | 2025-07-20 22:38:56 | - |
+| **Test Duration** | ~10.18 seconds | ~10.62 seconds | Test 1 ✓ |
+| **Total Requests** | 60 | 60 | Tie |
+| **Error Rate** | 0% | 0% | Tie |
+| **Success Rate** | 100% | 100% | Tie |
+
+## Detailed Performance Metrics
+
+### Response Time Analysis
+
+#### GET /api/v1/objects/create
+| Metric | Test 1 (223808) | Test 2 (223856) | Improvement |
+|--------|------------------|------------------|-------------|
+| **Mean Response Time** | 7.45ms | 9.85ms | **24.3% faster** ✓ |
+| **Median Response Time** | 5.0ms | 6.5ms | **23.1% faster** ✓ |
+| **Min Response Time** | 2.0ms | 2.0ms | Tie |
+| **Max Response Time** | 58.0ms | 83.0ms | **30.1% faster** ✓ |
+| **90th Percentile** | 7.9ms | 12.6ms | **37.3% faster** ✓ |
+| **95th Percentile** | 55.5ms | 79.5ms | **30.2% faster** ✓ |
+
+#### GET /api/v1/threads/create
+| Metric | Test 1 (223808) | Test 2 (223856) | Improvement |
+|--------|------------------|------------------|-------------|
+| **Mean Response Time** | 5.05ms | 5.7ms | **11.4% faster** ✓ |
+| **Median Response Time** | 5.0ms | 6.0ms | **16.7% faster** ✓ |
+| **Min Response Time** | 2.0ms | 3.0ms | **33.3% faster** ✓ |
+| **Max Response Time** | 8.0ms | 9.0ms | **11.1% faster** ✓ |
+| **90th Percentile** | 7.9ms | 8.0ms | **1.3% faster** ✓ |
+
+#### GET /actuator/health
+| Metric | Test 1 (223808) | Test 2 (223856) | Improvement |
+|--------|------------------|------------------|-------------|
+| **Mean Response Time** | 8.45ms | 10.4ms | **18.8% faster** ✓ |
+| **Median Response Time** | 7.0ms | 8.0ms | **12.5% faster** ✓ |
+| **Min Response Time** | 2.0ms | 3.0ms | **33.3% faster** ✓ |
+| **Max Response Time** | 46.0ms | 63.0ms | **27.0% faster** ✓ |
+| **90th Percentile** | 8.9ms | 10.8ms | **17.6% faster** ✓ |
+
+### Throughput Analysis
+
+| Endpoint | Test 1 (223808) | Test 2 (223856) | Performance Gain |
+|----------|------------------|------------------|------------------|
+| **GET /api/v1/objects/create** | 2.067 req/sec | 1.956 req/sec | +5.7% ✓ |
+| **GET /api/v1/threads/create** | 2.108 req/sec | 1.997 req/sec | +5.6% ✓ |
+| **GET /actuator/health** | 2.106 req/sec | 2.011 req/sec | +4.7% ✓ |
+| **Overall Throughput** | 5.889 req/sec | 5.644 req/sec | **+4.3%** ✓ |
+
+### Data Transfer Metrics
+
+| Metric | Test 1 (223808) | Test 2 (223856) | Performance Gain |
+|--------|------------------|------------------|------------------|
+| **Received KB/sec** | 1.160 KB/sec | 1.112 KB/sec | +4.3% ✓ |
+| **Sent KB/sec** | 0.776 KB/sec | 0.744 KB/sec | +4.3% ✓ |
+
+## Overall Performance Summary
+
+| Performance Metric | Test 1 (223808) | Test 2 (223856) | Improvement |
+|-------------------|------------------|------------------|-------------|
+| **Overall Mean Response Time** | 6.98ms | 8.65ms | **19.3% faster** ✓ |
+| **Overall Median Response Time** | 6.0ms | 7.0ms | **14.3% faster** ✓ |
+| **Overall Min Response Time** | 2.0ms | 2.0ms | Tie |
+| **Overall Max Response Time** | 58.0ms | 83.0ms | **30.1% faster** ✓ |
+| **Overall Throughput** | 5.889 req/sec | 5.644 req/sec | **4.3% higher** ✓ |
+
+## Key Performance Insights
+
+### 🏆 Test 1 (223808) Advantages
+
+1. **Consistent Superior Performance**: Test 1 outperformed Test 2 across ALL measured metrics
+2. **Better Response Time Consistency**: Lower maximum response times indicate more predictable performance
+3. **Higher Efficiency**: Completed the same workload 4.1% faster
+4. **Improved Stability**: Better worst-case performance scenarios
+
+### 📊 Most Significant Improvements
+
+1. **Objects Endpoint**: 24.3% faster average response time (most critical improvement)
+2. **Maximum Response Times**: 30.1% improvement in worst-case scenarios
+3. **90th Percentile Performance**: Up to 37.3% faster for objects endpoint
+
+### 🔍 Performance Patterns
+
+#### Response Time Distribution
+- **Test 1**: More consistent performance with tighter distribution
+- **Test 2**: Higher variability, especially in maximum response times
+
+#### Endpoint-Specific Analysis
+- **Most Improved**: `/api/v1/objects/create` (24.3% faster)
+- **Most Consistent**: `/api/v1/threads/create` (11.4% faster)
+- **Health Check**: `/actuator/health` (18.8% faster)
+
+## Technical Analysis
+
+### Possible Performance Factors
+
+#### Test 1 (223808) Advantages
+1. **JVM Warm-up**: Better Just-In-Time (JIT) compilation optimization
+2. **Memory Management**: More efficient garbage collection patterns
+3. **System Resources**: Lower system contention during execution
+4. **Application State**: Better internal caching or connection pooling
+
+#### Test 2 (223856) Challenges
+1. **Cold Start Effects**: Less optimal JVM state at test initiation
+2. **Resource Contention**: Potential system load from other processes
+3. **Memory Pressure**: Possible GC overhead affecting performance
+4. **Network Conditions**: Minor network latency variations
+
+### Statistical Significance
+
+#### Sample Analysis (60 requests total, 20 per endpoint)
+- **Sample Size**: Adequate for trend identification
+- **Error Rate**: 0% (excellent test validity)
+- **Consistency**: Multiple endpoints show same performance pattern
+
+#### Confidence Level
+- **High Confidence**: Consistent improvement across all metrics
+- **Reproducible Pattern**: All three endpoints show Test 1 superiority
+- **Significant Margins**: 19.3% overall improvement indicates real performance difference
+
+## Environmental Context
+
+### Test Environment Factors
+- **Time Gap**: 48 seconds between test executions
+- **System State**: Potential differences in JVM state, memory usage, system load
+- **Application State**: Possible cache warming or connection pool optimization
+
+### Memory Leak Context
+Based on related profiling documentation, these tests were conducted during memory leak investigation:
+- **Controller**: Tests likely used `CocoController` (with known memory leaks)
+- **Memory State**: System may have been under memory pressure
+- **Performance Impact**: Memory leaks could affect test-to-test consistency
+
+## Recommendations
+
+### ✅ Immediate Actions
+1. **Adopt Test 1 Configuration**: Use whatever conditions produced Test 1 results as baseline
+2. **Investigate Environmental Factors**: Identify what made Test 1 perform better
+3. **Establish Performance Baseline**: Use Test 1 metrics as target performance
+
+### 🔄 Performance Optimization
+1. **JVM Tuning**: Optimize JVM parameters for consistent performance like Test 1
+2. **Warm-up Strategy**: Implement application warm-up procedures
+3. **Monitoring**: Establish continuous performance monitoring using Test 1 as baseline
+
+### 📊 Future Testing
+1. **Extended Testing**: Run longer-duration tests to validate consistency
+2. **Load Variation**: Test with different load patterns
+3. **Environmental Control**: Standardize test environment conditions
+
+## Validation and Next Steps
+
+### Performance Validation Checklist
+- [x] Response time analysis completed
+- [x] Throughput analysis completed
+- [x] Error rate verification completed
+- [x] Statistical significance assessed
+- [x] Environmental factors considered
+
+### Next Steps
+1. **Root Cause Analysis**: Investigate why Test 1 performed better
+2. **Performance Tuning**: Apply lessons learned to optimize for Test 1-like performance
+3. **Monitoring Setup**: Implement alerting for performance regression
+4. **Load Testing**: Validate findings with sustained load tests
+
+## Conclusion
+
+### 🎯 Clear Winner: Test 1 (223808)
+
+**Test 1 demonstrates superior performance across every measured metric**, with particularly significant improvements in:
+- **19.3% faster overall response times**
+- **4.3% higher throughput**
+- **30.1% better worst-case performance**
+
+### 📈 Business Impact
+- **Better User Experience**: Faster response times improve customer satisfaction
+- **Higher Capacity**: 4.3% throughput improvement supports more concurrent users
+- **Improved Reliability**: Better worst-case performance reduces timeout risks
+
+### 🔍 Technical Recommendation
+**Use Test 1 (223808) configuration and conditions as the performance baseline** for production deployment and future optimization efforts.
+
+---
+
+**Analysis Date**: July 20, 2025
+**Test Data Sources**:
+- `jmeter-result-20250720-223808.jtl`
+- `jmeter-result-20250720-223856.jtl`
+- `statistics.json` files from both test reports
+
+**Status**: ✅ **Analysis Complete - Test 1 Recommended**

examples/spring-boot-memory-leak-demo/profiler/results/gc-300s-20250720-193126.log

@@ -0,0 +1,4 @@
+[92.858s][info][gc] GC(8) Pause Young (Normal) (G1 Evacuation Pause) 298M->49M(512M) 38.190ms
+[188.772s][info][gc] GC(9) Pause Young (Normal) (G1 Evacuation Pause) 338M->77M(512M) 69.008ms
+[282.978s][info][gc] GC(10) Pause Young (Normal) (G1 Evacuation Pause) 361M->105M(512M) 74.681ms
+[376.662s][info][gc] GC(11) Pause Young (Normal) (G1 Evacuation Pause) 395M->135M(512M) 76.817ms

examples/spring-boot-memory-leak-demo/profiler/results/gc-300s-20250720-202836.log

@@ -0,0 +1,2 @@
+[291.583s][info][gc] GC(7) Pause Young (Prepare Mixed) (G1 Evacuation Pause) 311M->22M(512M) 20.482ms
+[570.492s][info][gc] GC(8) Pause Young (Mixed) (G1 Evacuation Pause) 287M->22M(512M) 16.636ms