Skip to main content
Version: 0.0.36

Analytics Frontend Service Scaling

The Analytics Frontend Service is responsible for rendering individual reports and managing the user interface components of the analytical environment. This service directly impacts the user experience when viewing and interacting with reports, dashboards, and analytical visualizations.

Service Overview​

The Analytics Frontend Service handles the presentation layer of analytical content, including report rendering, dashboard displays, and user interface interactions. Proper scaling ensures smooth report loading times and responsive user interactions during peak usage periods.

Service Architecture​

The Analytics Frontend Service consists of two main components:

Node Component​

Handles the primary frontend processing and user interface rendering

Worker Component​

Manages background processing tasks and report generation workloads

Serial Beat Service​

Optional coordination service (disabled by default)

Prerequisites​

  • Administrator Access: Only administrators can perform scaling operations
  • Low Usage Period: Plan scaling during times with fewer active users
  • Resource Assessment: Verify Kubernetes cluster resources and available nodes
  • Incremental Approach: Prepare for step-by-step scaling implementation

Accessing Scaling Configuration​

To configure Analytics Frontend Service scaling:

  1. Access Admin Workspace

    • Navigate to the Lakehousecat admin interface
    • Ensure administrator privileges are active

  2. Navigate to Settings

    • Click on Admin Workspace in the main navigation
    • Select Settings from the workspace options

  3. Enter Service Configuration

    • Go to the Services section within Settings
    • Locate and select Analytics Frontend Service

  4. Edit Service Configuration

    • Click the Edit Service button to access scaling parameters

Configuration Parameters​

Node Component Settings​

The Node component handles primary frontend operations:

Replica Configuration​

  • Replica Count: Default 1

    • Number of Node component instances
    • Increase for higher concurrent user loads

  • Autoscaling: Disabled by default

    • Can be enabled for automatic scaling based on resource usage
    • Consider enabling for variable user loads

Resource Allocation​

  • CPU Request: Default 125M (125 millicores)

    • Guaranteed CPU resources for each Node replica
    • Suitable for standard UI rendering tasks

  • Memory Request: Default 1 GB

    • Guaranteed memory allocation per Node replica
    • Sufficient for typical frontend operations

  • CPU Limit: Default 250M (250 millicores)

    • Maximum CPU resources available to each Node replica
    • Allows for processing spikes during report rendering

  • Memory Limit: Default 2 GB

    • Maximum memory allocation per Node replica
    • Provides headroom for complex report visualizations

Worker Component Settings​

The Worker component manages background processing and report generation:

Replica Configuration​

  • Replica Count: Default 1

    • Number of Worker component instances
    • Scale based on report generation demands

  • Autoscaling: Disabled by default

    • Enable for dynamic scaling based on report processing queue

Resource Allocation​

  • CPU Request: Default 250M (250 millicores)

    • Guaranteed CPU for background processing tasks
    • Higher than Node component due to processing requirements

  • Memory Request: Default 1 GB

    • Base memory allocation for Worker processes
    • Handles standard report generation workloads

  • CPU Limit: Default 500M (500 millicores)

    • Maximum CPU available for intensive report processing
    • Double the request value for burst capacity

  • Memory Limit: Default 200 GB

    • Extensive memory allocation for large dataset processing
    • Supports complex analytical report generation

Serial Beat Service​

  • Status: Disabled by default
  • Purpose: Provides coordination and scheduling capabilities
  • Recommendation: Enable only when specific coordination requirements exist

Scaling Strategies​

Node Component Scaling​

Horizontal Scaling:

  • Increase Replica Count for more concurrent user support
  • Suitable when multiple users access reports simultaneously
  • Improves overall system responsiveness

Vertical Scaling:

  • Increase CPU and Memory limits for complex report rendering
  • Useful for reports with heavy visualizations or large datasets
  • Enhances individual user experience

Configuration Example:

Replica Count: 3
CPU Request: 200M
Memory Request: 1.5 GB
CPU Limit: 400M
Memory Limit: 3 GB

Worker Component Scaling​

Horizontal Scaling:

  • Increase Worker replicas for parallel report generation
  • Reduces report processing queue times
  • Handles multiple simultaneous report requests

Vertical Scaling:

  • Increase memory allocation for large dataset processing
  • Enhance CPU limits for faster report generation
  • Improves processing speed for individual reports

Configuration Example:

Replica Count: 2
CPU Request: 500M
Memory Request: 2 GB
CPU Limit: 1000M
Memory Limit: 300 GB

Scaling Considerations​

User Experience Impact​

  • Report Rendering: Service briefly unavailable during deployment
  • Active Sessions: Users may experience temporary interruptions
  • UI Responsiveness: Potential delays during scaling operations
  • Session Management: Active report views may need refreshing

Resource Dependencies​

  • Kubernetes Cluster: Sufficient cluster resources required
  • Node Availability: Adequate worker nodes for horizontal scaling
  • Network Capacity: Consider network bandwidth for additional replicas
  • Storage Resources: Persistent storage requirements for scaled components

Incremental Scaling Approach​

  1. Start Small: Increase resources or replicas by small increments
  2. Monitor Impact: Observe system behavior after each change
  3. User Feedback: Gather user experience feedback post-scaling
  4. Iterative Adjustment: Make further adjustments based on performance data

Deployment Process​

Configuration Phase​

  1. Adjust Parameters

    • Modify Node and Worker component settings as needed
    • Consider enabling autoscaling if appropriate
    • Review resource allocation against cluster capacity

  2. Save Configuration

    • Click Save to store configuration changes
    • Configuration is preserved but not yet active

Deployment Phase​

  1. Initiate Deployment

    • Click the Deploy button to apply changes
    • Deployment job executes in the Operations context background

  2. Monitor Deployment Progress

    • Track deployment status through the admin interface
    • Observe system logs for deployment activities

Verification Phase​

  1. Check Service Status

    • Return to Admin Workspace → Settings → Services
    • Verify Analytics Frontend Service shows successful deployment status

  2. Validate Functionality

    • Test report rendering and user interface responsiveness
    • Confirm all components are operational

Post-Deployment Monitoring​

Key Metrics​

  • Report Loading Times: Monitor report rendering performance
  • User Session Metrics: Track concurrent user capacity
  • Resource Utilization: CPU and memory usage across components
  • Error Rates: Frontend errors and rendering failures
  • System Responsiveness: UI interaction response times

Performance Validation​

  1. Load Testing: Test with typical user loads
  2. Report Complexity: Verify performance with various report types
  3. Concurrent Users: Validate multi-user scenarios
  4. Resource Efficiency: Confirm optimal resource utilization

Troubleshooting​

Common Issues​

Deployment Failures

  • Check Kubernetes cluster resource availability
  • Verify node capacity for requested resources
  • Review Operations context logs for error details

Performance Degradation

  • Monitor resource bottlenecks in scaled components
  • Check network connectivity between Node and Worker components
  • Verify database connectivity for report data access

User Experience Issues

  • Test report rendering across different browsers
  • Validate session management and user authentication
  • Check for frontend JavaScript errors or console warnings

Rollback Procedures​

If scaling causes problems:

  1. Access Service Configuration

    • Navigate back to Analytics Frontend Service settings
    • Enter edit mode for the service

  2. Restore Previous Values

    • Reset Replica Counts to original values
    • Restore CPU and Memory settings to defaults
    • Disable autoscaling if it was enabled

  3. Redeploy Original Configuration

    • Save the restored configuration
    • Click Deploy to apply rollback changes

  4. Verify Rollback Success

    • Check service status for successful deployment
    • Test basic functionality and user experience

  5. Contact Support

    • Document the scaling attempt and issues encountered
    • Provide system logs and error messages to support team
    • Request assistance for complex scaling scenarios

Best Practices​

Planning​

  • Usage Analysis: Review user activity patterns before scaling
  • Resource Assessment: Ensure adequate cluster resources
  • Timing Consideration: Scale during low-usage periods
  • Backup Strategy: Document current working configuration

Implementation​

  • Incremental Changes: Make small, measurable adjustments
  • Component Balance: Scale Node and Worker components proportionally
  • Monitoring Setup: Ensure comprehensive monitoring is active
  • Testing Protocol: Validate each scaling step thoroughly

Maintenance​

  • Regular Reviews: Periodically assess scaling effectiveness
  • Performance Trends: Track long-term performance patterns
  • User Feedback: Collect and analyze user experience reports
  • Capacity Planning: Plan future scaling based on growth projections

Autoscaling Considerations​

When enabling autoscaling for either component:

Configuration Parameters​

  • Target CPU Utilization: Recommended 70-80%
  • Target Memory Utilization: Recommended 75-85%
  • Minimum Replicas: Start with current replica count
  • Maximum Replicas: Set based on cluster capacity
  • Scale Up/Down Policies: Configure appropriate thresholds

Monitoring Autoscaling​

  • Scaling Events: Monitor automatic scaling activities
  • Resource Metrics: Track utilization patterns
  • Performance Impact: Measure user experience during auto-scaling
  • Cost Implications: Monitor resource costs with dynamic scaling

Next Steps​

After successful Analytics Frontend Service scaling:

  1. Performance Monitoring: Establish ongoing performance tracking
  2. User Training: Inform users about improved capabilities
  3. Documentation Updates: Record scaling decisions and outcomes
  4. Capacity Planning: Plan future scaling based on usage growth
  5. Related Services: Consider scaling dependencies like Analytics Backend Service

The Analytics Frontend Service scaling directly impacts user experience, making careful planning and monitoring essential for successful implementation.