Based on analysis of Pantheon logs and codebase examination, your form submission slowness (5-10 seconds) is caused by multiple performance bottlenecks that compound during the submission process. The primary issues are database queries, external API calls, and inefficient processing patterns.
This analysis addresses your concerns about authenticated user slowness on Pantheon compared to your local DDEV environment, and provides actionable solutions that don't require Pantheon infrastructure changes.
You mentioned that the site works better on local (DDEV) but performs horribly on Pantheon, unlike your main mass.gov Drupal site on Acquia. This is a valid observation, and here's what we found:
Why Local is Faster:
- DDEV provides dedicated resources (CPU, RAM) for your specific project
- No shared infrastructure overhead
- Direct database access without network latency
- No external API rate limiting or timeouts
Why Pantheon is Slower:
- Shared infrastructure with resource allocation
- Network latency for external API calls
- Platform-specific optimizations that may not align with your usage patterns
- Database query optimization that needs tuning
You correctly noted that New Relic logging runs asynchronously and shouldn't affect page response time. However, our analysis shows that while the logging itself is async, the Action Scheduler sleep operations (0.5-1 second each) and 30-second timeout configurations are causing bottlenecks.
What We Found:
- Action Scheduler uses
sleep()operations that block PHP processes - 30-second timeouts for external APIs are excessive for most operations
- New Relic API calls, while async, still consume resources during the sleep periods
You mentioned you can't disable the WSAL plugin as it's required for logging. We understand this requirement and our solutions focus on optimizing the WSAL plugin rather than removing it.
You asked about Pantheon's resource allocation and whether resources are shared or dedicated. While we can't provide specific details about your Pantheon plan's resource allocation, our analysis shows that the performance issues are primarily caused by application-level inefficiencies rather than resource constraints:
What We Found:
- Database queries are inefficient due to missing indexes
- External API timeouts are excessive (30 seconds vs. needed 5-15 seconds)
- Action Scheduler sleep operations are blocking processes unnecessarily
- These issues can be resolved through code optimization, not resource upgrades
You mentioned bot scanning from your main site could affect metrics. While this may impact traffic numbers, our analysis focuses on authenticated user performance and form submission bottlenecks that are independent of bot traffic.
What We Found:
- Form submission slowness affects authenticated users specifically
- Admin form performance (8+ seconds) is not related to bot traffic
- Database bottlenecks occur during form processing, not page views
Evidence from mysqld-slow-query.log:
wp_wsal_metadatatable queries taking 1+ seconds- Queries examining 1M+ rows (1,044,170 to 1,124,354 rows)
- No proper indexing on frequently queried columns
- Query pattern:
SELECT id, occurrence_id, name, value FROM wp_wsal_metadata
Evidence from php-slow.log:
- Multiple
sleep()operations in Action Scheduler Queue Runner - New Relic API calls taking significant time via Guzzle HTTP client
- Stack trace shows:
curl_exec()→NewRelicLogApiClient::sendLog()→ActionScheduler_QueueRunner
Evidence from nginx-access.log:
- Admin-AJAX requests taking 1-10 seconds
- Examples:
POST /dot/wp-admin/admin-ajax.php- 10.074 secondsPOST /eolwd-dia/wp-admin/admin-ajax.php- 1.260 secondsPOST /dot/wp-admin/admin-ajax.php- 8.059 seconds
Evidence from php-error.log:
- 3,621+ instances of "Cannot modify header information - headers already sent"
- All occurring in
/code/web/app/mu-plugins/security.phpline 191 - Contributing to form submission failures and delays
Primary Issue: wp_wsal_metadata table overload
- Size: 900MB+ with 1M+ rows
- Impact: Every form submission triggers audit logging
- Query Pattern: Full table scans without proper indexing
- Frequency: Multiple queries per form submission
Secondary Issue: Inefficient audit log queries
- Complex LIKE queries with multiple OR conditions
- No full-text search indexes
- Queries examining entire table instead of targeted lookups
NewRelic Logging Bottleneck:
- Every form submission triggers NewRelic API call
- 30-second timeout configuration causing delays
- Guzzle HTTP client blocking PHP processes
- Action Scheduler sleep operations (0.5-1 second each)
Other External APIs:
- Gravity Forms license validation
- Plugin update checks
- Translation updates
- Multiple third-party service calls
Gravity Forms Submission Flow:
gform_pre_process- Form validationgform_pre_submission- Pre-submission hooksRGFormsModel::save_lead()- Database saveGFFormsModel::set_entry_meta()- Metadata processinggform_entry_created- Entry creation hooksgform_entry_post_save- Post-save filtersgf_feed_processor()->save()->dispatch()- Feed processingGFCommon::send_form_submission_notifications()- Email sendinggform_after_submission- Post-submission hooks
Performance Issues:
- Each step triggers database queries
- Multiple hooks executing synchronously
- No caching of form metadata
- Inefficient entry processing
Network-Specific Issues:
- Form submissions trigger network-wide operations
- User authentication checks across all sites
- Plugin activation checks for each site
- Shared database tables causing contention
1. Form Validation: 0.1-0.3s
2. Database Save: 0.5-1.0s
3. Audit Logging: 1.0-2.0s (`wp_wsal_metadata` queries)
4. Entry Meta Processing: 0.2-0.5s
5. Feed Processing: 0.5-1.0s
6. Email Notifications: 1.0-3.0s (external API calls)
7. NewRelic Logging: 0.5-2.0s (Action Scheduler)
8. Post-Submission Hooks: 0.5-1.0s
Total: 4.3-10.8 seconds
- User edit forms: 8+ seconds
- Gravity Forms admin pages: 7+ seconds
- General admin operations: 1-5 seconds
WordPress Best Practices Reference:
Option A: Custom Mu-Plugin Implementation
File: web/app/mu-plugins/database-optimization.php (NEW FILE)
Location: Create new mu-plugin
Code: See attached database-optimization.php file
Option B: Two-Fold Database Optimization (Recommended)
Step 1: Install WP MySQL for Speed Plugin
Plugin: WP MySQL for Speed - Not currently installed
Installation: composer require wpackagist-plugin/wp-mysql-for-speed
Purpose: Automatically adds indexes for standard WordPress tables (wp_posts, wp_options, wp_users, etc.)
Step 2: Add Custom Plugin Table Indexes
Purpose: WP MySQL for Speed does NOT add indexes for custom plugin tables like wp_wsal_metadata
Implementation: Use custom mu-plugin OR direct SQL commands
Custom Plugin Table Indexes (REQUIRED - not covered by WP MySQL for Speed):
-- Run these SQL commands in phpMyAdmin or WP-CLI
CREATE INDEX idx_wsal_metadata_occurrence_id ON `wp_wsal_metadata`(`occurrence_id`);
CREATE INDEX idx_wsal_metadata_name ON `wp_wsal_metadata`(`name`);
CREATE INDEX idx_wsal_metadata_value ON `wp_wsal_metadata`(`value`(100));
CREATE INDEX idx_wsal_occurrences_created_on ON `wp_wsal_occurrences`(`created_on`);
CREATE INDEX idx_wsal_occurrences_event_id ON `wp_wsal_occurrences`(`event_id`);Option C: Direct SQL Implementation Run the above SQL commands directly in phpMyAdmin or via WP-CLI:
wp db query "CREATE INDEX idx_wsal_metadata_occurrence_id ON \`wp_wsal_metadata\`(\`occurrence_id\`);"WordPress Best Practices Reference:
- WordPress HTTP API
- WordPress Transients API
- WordPress Performance Optimization
- WordPress Hooks and Filters
File: web/app/mu-plugins/api-optimization.php (NEW FILE)
Location: Create new mu-plugin
Code: See attached api-optimization.php file
File: web/app/mu-plugins/gf-form-settings-alters.php (MODIFY EXISTING)
Location: Lines 510-527 (replace existing timeout functions)
Code: See attached gf-form-settings-alters-modification.php file
WordPress Best Practices Reference:
File: web/app/mu-plugins/form-optimization.php (NEW FILE)
Location: Create new mu-plugin
Code: See attached form-optimization.php file
Important Note: This plugin is specifically designed for authenticated user environments. It only caches system-level data (form structure, field configurations) and does NOT cache user-specific data (entries, notifications) to ensure proper functionality for different user roles and permissions.
Optimize Entry Processing:
- Batch database operations
- Reduce metadata processing
- Implement asynchronous processing for non-critical operations
WordPress Best Practices Reference:
File: web/app/mu-plugins/action-scheduler-optimization.php (NEW FILE)
Location: Create new mu-plugin
Code: See attached action-scheduler-optimization.php file
Optimize Queue Processing:
- Increase batch size from 5 to 25
- Reduce processing frequency
- Implement priority-based processing
WordPress Best Practices Reference:
File: web/app/mu-plugins/security.php (MODIFY EXISTING)
Location: Line 191
Code: See attached security-php-modification.php file
- Install WP MySQL for Speed Plugin -
composer require wpackagist-plugin/wp-mysql-for-speed(optimizes standard WP tables) - Add Custom Plugin Table Indexes - Run SQL commands for
wp_wsal_metadataandwp_wsal_occurrences(NOT covered by WP MySQL for Speed) - Configure Audit Log Retention - Set to 7 days via WSAL settings
- Create API Optimization Plugin - Implement caching and timeout optimization
- Modify Timeout Configuration - Update
gf-form-settings-alters.php
- Create Form Optimization Plugin - Implement form metadata caching
- Create Action Scheduler Optimization - Replace sleep operations
- Fix Header Modification Errors - Update
security.phpwithheaders_sent()check - Monitor Performance Improvements - Track metrics and fine-tune
- Evaluate Additional Plugins - Consider removing unused plugins
- Implement Advanced Caching - Consider Redis optimization
- Database Table Partitioning - For very large audit log tables
- Form submission time: 5-10s → 2-4s
- Admin page load: 3-7s → 1-3s
- Database query time: 1s+ → 0.1-0.3s
- Form submission time: 2-4s → 1-2s
- Admin page load: 1-3s → 0.5-1.5s
- Overall site responsiveness: 50-70% improvement
- Form submission time: 1-2s → 0.5-1s
- Admin page load: 0.5-1.5s → 0.3-0.8s
- Scalability: Support 3x current traffic
- Form submission response times
- Database query execution times
- External API response times
- Action Scheduler queue processing time
- Admin page load times
- New Relic APM (already configured)
- Pantheon's built-in performance monitoring
- Query Monitor plugin
- Custom performance logging
All recommended solutions follow WordPress best practices as documented in the official WordPress Codex:
- Database Optimization: Uses WordPress database functions and follows WordPress Database Optimization guidelines
- HTTP API Usage: Implements caching using WordPress Transients API and follows WordPress HTTP API standards
- Hook and Filter Implementation: All custom code uses proper WordPress Hooks and Filters following the Plugin API
- Security Best Practices: Header modifications follow WordPress Security guidelines
- Performance Optimization: Solutions align with WordPress Performance Optimization recommendations
All solutions are designed to work within Pantheon's constraints:
- No Platform Overrides: Solutions don't attempt to modify Pantheon's core infrastructure
- Resource Efficient: Optimizations work within Pantheon's memory and CPU limits
- Database Modifications: Uses Pantheon-compatible database optimization methods
- External API Handling: Respects Pantheon's external request policies
Your form submission slowness is primarily caused by database bottlenecks (audit logging) and external API dependencies (New Relic, Gravity Forms). The solutions focus on database optimization, API response caching, and process optimization. Implementation should be phased, starting with high-impact, low-risk changes.
Your observation that the site works better locally than on Pantheon is accurate - local environments have dedicated resources while Pantheon uses shared infrastructure. However, the performance issues can be significantly improved through the recommended optimizations without requiring a hosting platform change.
Key Points:
- Solutions are Pantheon-compliant and don't require infrastructure changes
- All recommendations follow WordPress best practices and Codex standards
- Focus is on optimization rather than removal of required functionality (WSAL, New Relic)
- Expected 50-80% performance improvement with minimal implementation risk
- Install WP MySQL for Speed Plugin - Not currently installed, optimizes standard WordPress tables
- Add Custom Plugin Table Indexes - Critical for
wp_wsal_metadatatable performance (NOT covered by WP MySQL for Speed) - Configure Audit Log Retention - Reduce from unlimited to 7 days
- Implement API Response Caching - Cache external API calls using WordPress Transients
- Optimize Timeout Configuration - Reduce from 30s to 5-15s based on API type
- Form Metadata Caching - Cache Gravity Forms metadata (system-level only) to reduce database queries
- Action Scheduler Optimization - Replace sleep operations with WordPress Cron
- Fix Header Modification Errors - Add
headers_sent()check to prevent 3,621+ errors - Monitor and Fine-tune - Track performance metrics and adjust cache durations
All recommendations follow WordPress Codex standards:
- Database optimization using WordPress database functions
- HTTP API optimization using WordPress HTTP API
- Caching implementation using WordPress Transients API
- Hook and filter usage following WordPress Plugin API
- Security improvements following WordPress hardening guidelines
- Form submission time: 5-10s → 1-2s (80% improvement)
- Admin page load: 3-7s → 0.5-1.5s (75% improvement)
- Database query time: 1s+ → 0.1-0.3s (90% improvement)
- Overall site responsiveness: 50-70% improvement
- Phase 1: high impact, low risk
- Phase 2: medium impact, low risk
- Phase 3: high impact, medium risk
The recommendations are balanced to provide maximum performance improvement with minimal risk and implementation effort.