[Performance] ProjectsController#index - Slow response time (2193332.93 s)

[IMhide]

---

repository: IMhide/Blast

Performance Issue: ProjectsController#index

Repository: IMhide/Blast
Incident Number: #4
AppSignal ID: 64df5b97d2a5e475308da322
App ID: 64cb678083eb67f665b627b0

Status: CLOSED
Severity: UNTRIAGED

Description

No description provided

---

Critical Information

Metric	Value
Average Duration	2193332.93 s
Affected Actions	ProjectsController#index
State	CLOSED
Severity	UNTRIAGED

Performance Metrics

Based on 10 sample(s):

Statistic	Duration
Minimum	771.55 ms
Maximum	1.53 s
Average	995.20 ms
Median	930.87 ms

Sample Analysis

Analyzed 10 sample(s) from recent occurrences.

Sample 1

• Time: 2025-12-15 08:44:08 UTC
• Duration: 771.55 ms
• Action: ProjectsController#index
• Queue Duration: 0.00 μs

Time Breakdown

Component	Duration	Percentage
active_record	592.35 ms	77.5%
action_view	162.65 ms	21.3%
action_controller	6.22 ms	0.8%
active_support	2.64 ms	0.3%
redis	197.66 μs	0.0%

Memory Allocation

Component	Allocation
action_view	84.86 KB
active_record	2.72 KB
action_controller	2.56 KB
active_support	75.00 B
redis	22.00 B

---

Sample 2

• Time: 2025-12-15 08:43:02 UTC
• Duration: 1.04 s
• Action: ProjectsController#index
• Queue Duration: 0.00 μs

Time Breakdown

Component	Duration	Percentage
active_record	720.64 ms	70.1%
action_view	278.62 ms	27.1%
active_support	14.85 ms	1.4%
action_controller	13.41 ms	1.3%
redis	256.69 μs	0.0%

Memory Allocation

Component	Allocation
action_view	85.41 KB
action_controller	4.22 KB
active_record	2.79 KB
active_support	74.00 B
redis	22.00 B

---

Sample 3

• Time: 2025-12-15 08:42:40 UTC
• Duration: 1.12 s
• Action: ProjectsController#index
• Queue Duration: 0.00 μs

Time Breakdown

Component	Duration	Percentage
active_record	856.72 ms	77.1%
action_view	195.87 ms	17.6%
active_support	39.93 ms	3.6%
action_controller	18.96 ms	1.7%
redis	286.86 μs	0.0%

Memory Allocation

Component	Allocation
action_view	83.00 KB
action_controller	3.52 KB
active_record	2.82 KB
active_support	74.00 B
redis	22.00 B

---

Sample 4

• Time: 2025-12-15 08:41:22 UTC
• Duration: 1.53 s
• Action: ProjectsController#index
• Queue Duration: 0.00 μs

Time Breakdown

Component	Duration	Percentage
active_record	1.10 s	75.1%
action_view	333.44 ms	22.7%
action_controller	18.60 ms	1.3%
active_support	12.62 ms	0.9%
redis	262.91 μs	0.0%

Memory Allocation

Component	Allocation
action_view	85.05 KB
active_record	2.75 KB
action_controller	2.58 KB
active_support	74.00 B
redis	22.00 B

---

Sample 5

• Time: 2025-12-15 08:40:07 UTC
• Duration: 920.48 ms
• Action: ProjectsController#index
• Queue Duration: 0.00 μs

Time Breakdown

Component	Duration	Percentage
active_record	691.87 ms	75.9%
action_view	183.76 ms	20.2%
active_support	19.99 ms	2.2%
action_controller	15.91 ms	1.7%
redis	246.53 μs	0.0%

Memory Allocation

Component	Allocation
action_view	85.05 KB
action_controller	3.40 KB
active_record	2.78 KB
active_support	74.00 B
redis	22.00 B

---

Sample 6

• Time: 2025-12-15 08:39:00 UTC
• Duration: 925.67 ms
• Action: ProjectsController#index
• Queue Duration: 0.00 μs

Time Breakdown

Component	Duration	Percentage
active_record	574.98 ms	62.4%
action_view	239.39 ms	26.0%
active_support	94.13 ms	10.2%
action_controller	13.06 ms	1.4%
redis	256.11 μs	0.0%

Memory Allocation

Component	Allocation
action_view	93.61 KB
active_record	5.72 KB
action_controller	4.47 KB
active_support	74.00 B
redis	22.00 B

---

Sample 7

• Time: 2025-12-15 08:38:31 UTC
• Duration: 947.60 ms
• Action: ProjectsController#index
• Queue Duration: 0.00 μs

Time Breakdown

Component	Duration	Percentage
active_record	674.60 ms	71.8%
action_view	245.08 ms	26.1%
active_support	13.10 ms	1.4%
action_controller	7.20 ms	0.8%
redis	210.19 μs	0.0%

Memory Allocation

Component	Allocation
action_view	85.74 KB
active_record	2.86 KB
action_controller	2.55 KB
active_support	74.00 B
redis	22.00 B

---

Sample 8

• Time: 2025-12-15 08:37:38 UTC
• Duration: 918.36 ms
• Action: ProjectsController#index
• Queue Duration: 0.00 μs

Time Breakdown

Component	Duration	Percentage
active_record	695.40 ms	76.0%
action_view	185.66 ms	20.3%
active_support	20.56 ms	2.2%
action_controller	12.77 ms	1.4%
redis	198.66 μs	0.0%

Memory Allocation

Component	Allocation
action_view	85.11 KB
action_controller	3.70 KB
active_record	2.78 KB
active_support	75.00 B
redis	22.00 B

---

Sample 9

• Time: 2025-12-15 08:36:31 UTC
• Duration: 852.60 ms
• Action: ProjectsController#index
• Queue Duration: 0.00 μs

Time Breakdown

Component	Duration	Percentage
active_record	602.51 ms	76.8%
action_view	160.94 ms	20.5%
active_support	12.94 ms	1.6%
action_controller	7.47 ms	1.0%
redis	164.68 μs	0.0%

Memory Allocation

Component	Allocation
action_view	84.84 KB
active_record	2.72 KB
action_controller	2.55 KB
active_support	74.00 B
redis	22.00 B

---

Sample 10

• Time: 2025-12-15 08:35:11 UTC
• Duration: 936.06 ms
• Action: ProjectsController#index
• Queue Duration: 0.00 μs

Time Breakdown

Component	Duration	Percentage
active_record	712.39 ms	76.7%
action_view	186.13 ms	20.0%
action_controller	23.23 ms	2.5%
active_support	6.97 ms	0.7%
redis	152.97 μs	0.0%

Memory Allocation

Component	Allocation
action_view	86.54 KB
action_controller	3.75 KB
active_record	2.77 KB
active_support	74.00 B
redis	22.00 B

---

N+1 Query Detection

⚠️ N+1 query pattern detected in 10 out of 10 samples!

Affected Samples:

• Sample Add Claude Code GitHub Workflow #1 at 2025-12-15 08:44:08 UTC (771.55 ms)
• Sample [Performance] Mailchimp::SyncUserWorker#perform - Slow response time (5171797.61 s) #2 at 2025-12-15 08:43:02 UTC (1.04 s)
• Sample [Performance] Brevo::SyncContactWorker#perform - Slow response time (218884.54 s) #3 at 2025-12-15 08:42:40 UTC (1.12 s)
• Sample [Performance] Brevo::SyncContactWorker#perform - Slow response time (218884.54 s) #4 at 2025-12-15 08:41:22 UTC (1.53 s)
• Sample [Performance] Brevo::SyncContactWorker#perform - Slow response time (218884.54 s) #5 at 2025-12-15 08:40:07 UTC (920.48 ms)
• Sample [Performance] Brevo::SyncContactWorker#perform - Slow response time (218892.29 s) #6 at 2025-12-15 08:39:00 UTC (925.67 ms)
• Sample [Performance] Brevo::SyncContactWorker#perform - Slow response time (218892.29 s) #7 at 2025-12-15 08:38:31 UTC (947.60 ms)
• Sample [Performance] ProjectsController#index - Slow response time (2181109.41 s) #8 at 2025-12-15 08:37:38 UTC (918.36 ms)
• Sample [Performance] ProjectsController#index - Slow response time (2181235.30 s) #9 at 2025-12-15 08:36:31 UTC (852.60 ms)
• Sample [Performance] ProjectsController#index - Slow response time (2181301.64 s) #10 at 2025-12-15 08:35:11 UTC (936.06 ms)

Resource Allocation Analysis

Average memory allocation by category:

Category	Average Allocation	Samples
action_view	85.92 KB	10
action_controller	3.33 KB	10
active_record	3.07 KB	10
active_support	74.20 B	10
redis	22.00 B	10

[github-actions]

🔍 Performance Analysis Results

Analysis completed for repository IMhide/Blast

---

Rails Performance Analysis - GitHub Issue #15

Executive Summary

Issue: Rails ProjectsController#index action experiencing severe performance degradation with average response times of ~995ms and persistent N+1 query patterns detected in 100% of samples.

Root Cause: Missing eager loading of the project_owner association in the Projects::IndexQuerySet, causing N+1 queries when the ProjectDecorator accesses project owner data.

Impact:

• Average response time: 995.20ms (Min: 771.55ms, Max: 1.53s)
• ActiveRecord consuming 62-77% of execution time
• N+1 query pattern detected in 10/10 samples
• Poor user experience with slow page loads

---

Technical Analysis

1. Performance Metrics from Issue #15

Metric	Value
Average Duration	995.20 ms
Minimum Duration	771.55 ms
Maximum Duration	1.53 s
ActiveRecord Time	62-77% of total execution
Action View Time	17-27% of total execution
N+1 Query Rate	100% (10/10 samples)

2. Root Cause Analysis

Primary Issue: Missing project_owner Includes

Location: app/query_sets/projects/index_query_set.rb:40-61

The QuerySet methods fetch_published_projects and fetch_financed_projects are missing the critical includes(:project_owner) statement:

# Current Implementation (PROBLEMATIC)
def fetch_published_projects
  projects = Project
    .with_tags
    .includes(:text_translations)  # ✅ Included
    .published.where(intentions_ends_at: Time.current..)
    .order(position: :asc)
    # ❌ Missing .includes(:project_owner)
end

def fetch_financed_projects
  projects = Project
    .with_tags
    .includes(:text_translations)  # ✅ Included
    .published_or_succeeded
    .where(intentions_ends_at: ..Time.current)
    .order(position: :asc)
    # ❌ Missing .includes(:project_owner)
end

Secondary Issue: Decorator Association Access

Location: app/decorators/project_decorator.rb:2,8

The ProjectDecorator decorates the project_owner association and delegates methods to it:

decorates_association :project_owner              # Line 2
delegate :name_with_civility, :nationality_text, to: :project_owner  # Line 8

When the decorator is applied via .decorate in the QuerySet (lines 14, 18), each project instance will trigger a separate database query to fetch its project_owner if not eager loaded.

Tertiary Issue: Additional Potential N+1 Sources

The decorator also decorates other associations that may be accessed:

decorates_association :subscriptions              # Line 3
decorates_association :team_members               # Line 4
decorates_association :signed_contracts_export    # Line 5
decorates_association :general_assemblies         # Line 6

Some decorator methods access subscriptions:

• collected_amount (line 38): object.subscriptions.countable_in_gauge.sum(:amount)
• subscribers_count (line 50): object.subscriptions.countable_in_gauge.pluck(:users_profile_id).uniq.size
• completed_subscriptions_count (line 152): object.subscriptions.completed.size

3. Impact Assessment

Database Query Pattern

Without proper eager loading, each page load of 30 projects generates:

• 1 query for projects
• 30 queries for project_owner associations (N+1)
• Potentially 90+ more queries if subscription decorators are accessed
• Total: 31-121+ database queries per page instead of 1-2

Performance Impact

• ActiveRecord consuming 62-77% of execution time indicates database bottleneck
• Average 995ms response time is unacceptable for user experience
• Memory allocation in Action View (85.92KB) suggests template rendering delays due to database waits

---

Actionable Recommendations

🔴 Critical Priority (Immediate Fix Required)

1. Add Missing Eager Loading in QuerySet

File: app/query_sets/projects/index_query_set.rb

Lines to modify: 40-61

Fix:

def fetch_published_projects
  projects = Project
    .with_tags
    .includes(:text_translations, :project_owner)  # ✅ Add project_owner
    .published.where(intentions_ends_at: Time.current..)
    .order(position: :asc)
end

def fetch_financed_projects
  projects = Project
    .with_tags
    .includes(:text_translations, :project_owner)  # ✅ Add project_owner
    .published_or_succeeded
    .where(intentions_ends_at: ..Time.current)
    .order(position: :asc)
end

Expected Impact: Eliminates primary N+1 queries, should reduce response time by 60-70%

2. Fix Featured Projects Query

File: app/query_sets/projects/index_query_set.rb

Line to modify: 28

Current:

Cms::Configuration.instance.projects.with_tags.decorate

Fix:

Cms::Configuration.instance.projects.with_tags.includes(:project_owner).decorate

🟡 High Priority (Next Sprint)

3. Add Subscription Eager Loading (Conditional)

Analysis Required: Determine if subscription decorator methods are accessed in views.

If collected_amount, subscribers_count, or completed_subscriptions_count are used in the project cards:

.includes(:text_translations, :project_owner, :subscriptions)

Performance Test: Monitor if this improves or degrades performance due to subscription data volume.

4. Optimize with Custom Scope

Create optimized scope in Project model:

# In app/models/project.rb
scope :for_index_page, -> do
  with_tags
  .includes(:text_translations, :project_owner)
  .select('projects.*, project_owners.name AS owner_name')  # Only fetch needed columns
end

Then update QuerySet:

def fetch_published_projects
  projects = Project
    .for_index_page
    .published.where(intentions_ends_at: Time.current..)
    .order(position: :asc)
end

🟢 Medium Priority (Technical Debt)

5. Add Query Monitoring

Install query monitoring to prevent future N+1 issues:

# In config/environments/development.rb and staging.rb
config.after_initialize do
  Bullet.enable = true
  Bullet.bullet_logger = true
  Bullet.rails_logger = true
end

6. Decorator Performance Review

Review decorator usage:

• Audit which decorator methods are actually used in views
• Remove unused decorates_association statements
• Consider caching expensive calculations in decorator methods

7. Database Indexing

Verify indexes for common queries:

-- Ensure these indexes exist
CREATE INDEX idx_projects_status_intentions_ends_at ON projects(status, intentions_ends_at);
CREATE INDEX idx_projects_visibility ON projects(visibility);

🔵 Long-term Improvements

8. Query Optimization Strategy

• Implement GraphQL or JSON:API for precise field fetching
• Add database views for complex project aggregations
• Consider caching frequently accessed project data
• Implement fragment caching for project cards

9. Performance Testing

• Add automated performance tests for critical pages
• Set SLA for ProjectsController#index (target: <200ms)
• Monitor production performance with APM tools

---

Implementation Plan

Phase 1: Emergency Fix (1-2 hours)

1. ✅ Add .includes(:project_owner) to both fetch methods in IndexQuerySet
2. ✅ Add .includes(:project_owner) to featured_non_member_projects query
3. ✅ Deploy to staging and verify performance improvement
4. ✅ Deploy to production

Phase 2: Validation (1 day)

1. Monitor production performance metrics
2. Verify N+1 queries are eliminated using Bullet gem or query logs
3. Measure actual performance improvement
4. Update monitoring dashboards

Phase 3: Optimization (1 week)

1. Analyze if subscription eager loading is needed
2. Implement custom scope for better query organization
3. Add comprehensive query monitoring
4. Review and optimize other decorator associations

Phase 4: Long-term (1 month)

1. Implement automated performance testing
2. Add fragment caching for project cards
3. Optimize database indexes
4. Consider architectural improvements

---

Expected Results

Performance Improvements

• Response Time: 995ms → ~200-300ms (70% improvement)
• Database Queries: 31+ → 2-3 queries per page (90% reduction)
• ActiveRecord Time: 62-77% → 15-25% of execution time
• User Experience: Significant improvement in page load times

Monitoring Metrics

• N+1 query detection: 100% → 0%
• Average page load time: <300ms
• Database query count: <5 per page load
• Memory usage: Stable or reduced

---

Risk Assessment

Low Risk Changes

• ✅ Adding .includes(:project_owner) - Standard Rails optimization
• ✅ No code logic changes required
• ✅ Backwards compatible
• ✅ Easy to rollback if issues arise

Potential Concerns

• Memory usage: Eager loading may increase memory consumption slightly
• Query complexity: More complex joins, but database should handle well
• Testing: Ensure all project card functionality still works correctly

---

Testing Checklist

Before Deployment

• Verify project index page loads correctly
• Confirm project cards display all information
• Test both published and financed project sections
• Validate pagination functionality
• Check featured projects for non-members
• Confirm JSON API responses for infinite scroll

After Deployment

• Monitor application logs for errors
• Track response time metrics
• Verify database query count reduction
• Test under production traffic load
• Confirm user experience improvements

---

Technical Context

Application Details

• Framework: Ruby on Rails with PostgreSQL
• Architecture: Crowd equity platform (Blast)
• Pattern: QuerySet for data layer abstraction
• Decorators: Draper gem for presentation logic
• Pagination: Pagy gem (30 items per page)
• Associations: Complex project model with 15+ related entities

Database Schema

• Projects table with 100+ columns
• Complex associations to project_owner, subscriptions, tags, documents
• HABTM relationship for project tags
• Advanced PostgreSQL features in use

This analysis provides a complete roadmap for resolving the performance issues while maintaining code quality and application stability.

_{🤖 Analyzed by Claude Code (Optimized) • Triggered by issue creation • Workflow Run}

[IMhide]

I would like to focus on critical and high priority

[github-actions]

📋 Implementation Plan

Implementation plan created for repository IMhide/Blast

Issue: #15
Comments analyzed: 2

---

Implementation Plan: GitHub Issue #15 - ProjectsController#index Performance Fix

Executive Summary

Issue: Rails ProjectsController#index experiencing severe N+1 query performance issues with response times averaging 995ms due to missing eager loading of associations.

Root Cause: The Projects::IndexQuerySet is not eagerly loading the project_owner association, causing separate database queries for each project when the ProjectDecorator accesses owner data during view rendering.

Solution: Add proper eager loading to eliminate N+1 queries and reduce response time by an estimated 60-70%.

Priority: Critical (as requested by @IMhide to focus on critical and high priority items)

---

Issue Analysis Summary

Performance Metrics

• Average Response Time: 995.20ms (Min: 771.55ms, Max: 1.53s)
• ActiveRecord Time: 62-77% of total execution
• N+1 Query Rate: 100% (10/10 samples)
• Expected Improvement: Response time reduction to ~200-300ms (70% improvement)

Root Cause Analysis

Primary Issue: Missing project_owner eager loading in app/query_sets/projects/index_query_set.rb:44,55

Current Problematic Code:

def fetch_published_projects
  projects = Project
    .with_tags
    .includes(:text_translations)  # ✅ Included
    .published.where(intentions_ends_at: Time.current..)
    .order(position: :asc)
    # ❌ Missing .includes(:project_owner)
end

def fetch_financed_projects
  projects = Project
    .with_tags
    .includes(:text_translations)  # ✅ Included
    .published_or_succeeded
    .where(intentions_ends_at: ..Time.current)
    .order(position: :asc)
    # ❌ Missing .includes(:project_owner)
end

Secondary Issue: The featured_non_member_projects method at line 28 also lacks eager loading.

---

Files Analysis

1. Primary File: app/query_sets/projects/index_query_set.rb

• Status: ❌ Missing eager loading for project_owner
• Lines to modify: 44, 55, 28
• Current pattern: Uses .includes(:text_translations) but missing :project_owner
• Impact: Critical - eliminates primary N+1 queries

2. Decorator: app/decorators/project_decorator.rb

• Status: ⚠️ Decorates associations but causes N+1 queries
• Problem methods:
  • name_with_civility, nationality_text (delegated to :project_owner)
  • Subscription-related methods that may also cause N+1 queries
• Current view usage: Project cards primarily use basic attributes, not subscription methods

3. View: app/views/projects/_project_card.html.erb

• Status: ✅ Uses mostly safe attributes
• Current usage: project.name, project.short_description, project.tag_names, status predicates
• Risk: Low - doesn't appear to trigger subscription N+1 queries in current implementation

4. Controller: app/controllers/projects_controller.rb

• Status: ✅ No changes needed
• Pattern: Uses QuerySet appropriately, delegates data fetching to Projects::IndexQuerySet

5. Test: spec/query_sets/projects/index_query_set_spec.rb

• Status: ⚠️ Needs performance validation tests
• Current coverage: Good functional coverage, missing performance assertions
• Enhancement needed: Add N+1 query detection tests

---

Implementation Plan

Phase 1: Emergency Fix (Critical Priority - 1-2 hours)

1.1 Fix Primary N+1 Queries

File: app/query_sets/projects/index_query_set.rb

Changes required:

# Line 44: Update fetch_published_projects
def fetch_published_projects
  projects = Project
    .with_tags
    .includes(:text_translations, :project_owner)  # ✅ Add :project_owner
    .published.where(intentions_ends_at: Time.current..)
    .order(position: :asc)

  filter_by_visibility(projects)
end

# Line 55: Update fetch_financed_projects
def fetch_financed_projects
  projects = Project
    .with_tags
    .includes(:text_translations, :project_owner)  # ✅ Add :project_owner
    .published_or_succeeded
    .where(intentions_ends_at: ..Time.current)
    .order(position: :asc)

  filter_by_visibility(projects)
end

# Line 28: Update featured_non_member_projects
def featured_non_member_projects
  return if user.active_membership.present?

  Cms::Configuration.instance.projects.with_tags.includes(:project_owner).decorate
end

Risk Assessment: ✅ Low risk

• Standard Rails optimization technique
• No logic changes, only performance improvement
• Backward compatible
• Easy to rollback if issues arise

1.2 Testing Strategy

Immediate validation:

# Add to existing test file
# spec/query_sets/projects/index_query_set_spec.rb

describe "performance optimization" do
  it "eager loads project_owner to prevent N+1 queries" do
    expect { query_set.published_projects }.to generate_queries(count: 1)
  end

  it "eager loads project_owner for financed projects" do
    expect { query_set.financed_projects }.to generate_queries(count: 1)
  end
end

Phase 2: Validation & Monitoring (High Priority - 1-2 days)

2.1 Performance Validation

• Deploy changes to staging environment
• Run load testing with 30 projects per page
• Verify query count reduction from 31+ to 2-3 queries
• Confirm response time improvement to <300ms
• Monitor memory usage impact

2.2 Production Monitoring Setup

• Add query monitoring using Bullet gem (if not already present)
• Set up performance alerts for response times >300ms
• Monitor database connection pool usage
• Track N+1 query detection rate

2.3 Enhanced Testing

File: spec/query_sets/projects/index_query_set_spec.rb

Add comprehensive performance tests:

describe "N+1 query prevention" do
  let!(:projects_with_owners) do
    create_list(:project, 5, :published, intentions_ends_at: 1.day.from_now)
  end

  it "prevents N+1 queries when accessing project owners in view" do
    expect do
      projects = query_set.published_projects
      projects.each { |project| project.name_with_civility }
    end.to generate_queries(count: 1)
  end

  it "includes project_owner association in published projects query" do
    projects = query_set.published_projects
    expect(projects.first.association(:project_owner)).to be_loaded
  end
end

Phase 3: Optimization Enhancements (Medium Priority - 1 week)

3.1 Subscription Data Analysis

Investigation needed: Determine if subscription-related decorator methods are used in views:

• collected_amount (app/decorators/project_decorator.rb:38)
• subscribers_count (app/decorators/project_decorator.rb:50)
• human_paid_fees, human_unpaid_fees

Conditional enhancement:
If subscription data is needed in project cards:

# Add to includes if subscription methods are used in views
.includes(:text_translations, :project_owner, :subscriptions)

Performance consideration: Monitor if adding :subscriptions improves or degrades performance due to data volume.

3.2 Custom Scope Creation

File: app/models/project.rb

Create optimized scope for index page:

scope :for_index_page, -> do
  with_tags
  .includes(:text_translations, :project_owner)
  .select(
    'projects.*',
    'project_owners.name AS owner_name',
    'project_owners.civility AS owner_civility'
  )
end

Update QuerySet:

def fetch_published_projects
  projects = Project
    .for_index_page
    .published.where(intentions_ends_at: Time.current..)
    .order(position: :asc)

  filter_by_visibility(projects)
end

3.3 Database Index Optimization

Verify indexes exist:

-- Ensure these indexes exist for query optimization
CREATE INDEX idx_projects_status_intentions_ends_at
  ON projects(status, intentions_ends_at);
CREATE INDEX idx_projects_visibility
  ON projects(visibility);
CREATE INDEX idx_projects_position
  ON projects(position);

Phase 4: Long-term Improvements (1 month)

4.1 Automated Performance Testing

• Add performance regression tests to CI pipeline
• Set SLA targets: ProjectsController#index <200ms
• Implement automated N+1 query detection in test suite

4.2 Fragment Caching

Implement view caching for project cards:

<% cache ["project_card", project] do %>
  <%= render "projects/project_card", project: project %>
<% end %>

4.3 Database Optimization

• Implement database views for complex project aggregations
• Consider materialized views for frequently accessed data
• Add automated EXPLAIN ANALYZE logging for slow queries

---

Risk Assessment & Mitigation

Low Risk Changes ✅

• Adding .includes(:project_owner): Standard Rails optimization
• No business logic changes: Pure performance improvement
• Backward compatible: No API or interface changes
• Easy rollback: Can be reverted quickly if issues arise

Potential Concerns ⚠️

1. Memory Usage: Eager loading may slightly increase memory consumption

   • Mitigation: Monitor memory usage during testing

2. Query Complexity: More complex joins in database

   • Mitigation: Database should handle well; monitor query execution plans

3. Existing Dependencies: Ensure all project card functionality works

   • Mitigation: Comprehensive testing before deployment

---

Testing Checklist

Pre-Deployment ✅

• Verify project index page loads correctly
• Confirm project cards display all information properly
• Test both published and financed project sections
• Validate pagination functionality (30 items per page)
• Check featured projects for non-members
• Confirm JSON API responses for infinite scroll
• Run existing test suite to ensure no regressions

Post-Deployment ✅

• Monitor application logs for errors
• Track response time metrics (<300ms target)
• Verify database query count reduction (31+ → 2-3 queries)
• Test under production traffic load
• Confirm user experience improvements
• Monitor memory usage stability

---

Expected Results

Performance Improvements

• Response Time: 995ms → ~200-300ms (70% improvement)
• Database Queries: 31+ → 2-3 queries per page (90% reduction)
• ActiveRecord Time: 62-77% → 15-25% of execution time
• User Experience: Significant improvement in page load times

Monitoring Metrics

• N+1 query detection: 100% → 0%
• Average page load time: <300ms target
• Database query count: <5 per page load
• Memory usage: Stable or slightly increased but acceptable

---

Implementation Timeline

Immediate (Today)

1. Phase 1: Apply critical eager loading fixes
2. Testing: Run performance validation on staging
3. Deployment: Deploy to production with monitoring

This Week

1. Phase 2: Add comprehensive performance tests
2. Monitoring: Set up automated performance tracking
3. Validation: Confirm production improvements

Next Sprint (1-2 weeks)

1. Phase 3: Implement subscription data analysis and optimization
2. Enhancement: Create custom scopes and database optimizations
3. Documentation: Update performance guidelines

Long-term (1 month)

1. Phase 4: Implement automated performance testing
2. Caching: Add fragment caching for project cards
3. Optimization: Database views and advanced optimizations

---

Architecture Patterns Followed

This implementation plan follows the existing codebase patterns:

1. QuerySet Pattern: Maintains the established data layer abstraction
2. Decorator Pattern: Works with existing Draper decorators
3. Performance Optimization: Follows patterns seen in Projects::ShowQuerySet
4. Testing Strategy: Extends existing RSpec test structure
5. Rails Best Practices: Uses standard ActiveRecord optimization techniques

The solution is minimal, focused, and maintains code consistency with the existing Blast platform architecture.

_{🤖 Generated by Claude Code • Triggered by ready-to-plan label • Workflow Run}

[github-actions]

✅ Implementation Complete

The feature has been implemented and a pull request has been created!

Pull Request: https://github.com/IMhide/Blast/pull/1
Branch: performance/issue-15
Repository: IMhide/Blast

Next Steps

1. Review the pull request for correctness
2. Run any additional tests or validation
3. Merge the PR when ready

---

_{🤖 Implemented by Claude Code • Triggered by ready-for-pr label • Workflow Run}