Server tuning==Improve Application Speed and Reduce Request Overhead with OPcache, Laravel Caching, and Better Log Settings

READ: https://www.debug.school/rakeshdevcotocus_468/laravel-microservices-performance-optimization-a-priority-wise-plan-to-speed-up-holidaylandmark-2o9l

OPcache sizing → config:cache + route:cache → log level

====================Expected Impact:================================================================
Poore application par benefit, kyunki har request ka overhead kam hota hai.
Speed Up Every Request with Better Server Settings
Improve Application Speed with OPcache and Laravel Caching
Reduce Request Overhead with Caching and Smarter Logging
Tune Server Settings for Faster Pages
Optimize OPcache, Deployment Caches, and Log Levels
=============prompt=================================
Act as a senior Laravel and PHP-FPM performance engineer. Audit only P1 server tuning in HolidayLandmark: OPcache sizing, Laravel configuration and route caching, deployment cache handling, and logging overhead.

Enter Plan Mode first. Do not modify code, configuration, deployment scripts, caches, or server processes until I review and explicitly approve your proposed approach. Perform read-only inspection first.

Read the project’s AGENTS.md and CLAUDE.md, especially “holiday-new deploys”. Verify the installed PHP and Laravel versions, active PHP-FPM configuration, service users, and deployment structure.

Inspect these four areas separately:

1. OPcache (R1):
   - Verify OPcache is enabled in the PHP-FPM runtime serving requests; do not assume CLI settings match FPM.
   - Inspect memory consumption, available memory, cached script count, hit rate, cache-full status, and restart counters where accessible.
   - Recommend memory_consumption, interned_strings_buffer, and max_accelerated_files based on actual usage and server capacity.
   - Preserve safe code-refresh behavior during deployment. Explain any required reload or restart and its impact.

2. Laravel caching (R2):
   - Inventory every HolidayLandmark Laravel service and inspect existing configuration and route caches.
   - Audit env() calls outside config/, including application code, routes, Blade, and custom bootstrap logic. Identify calls that could behave incorrectly after config:cache.
   - Check route-cache compatibility for each service using its installed Laravel version.
   - Inspect bootstrap/cache and storage ownership and permissions.
   - Propose exact config:cache and route:cache commands for each service, running as hl_platform after verifying that user’s access.
   - If application changes are required for compatibility, show them separately as proposed changes; do not apply them or silently expand scope.

3. Deployment scripts:
   - Inspect each holiday-new/*/pull.sh and its current deployment order.
   - Propose adding cache generation after chown and after dependencies and environment configuration are ready.
   - Ensure cache-generation failures are visible and stop unsafe deployment continuation.
   - Explain how configuration caches are refreshed after .env changes.
   - Provide rollback steps for failed cache generation, permissions problems, stale configuration, or HTTP 500 errors.

4. Logging:
   - Inspect LOG_CHANNEL, LOG_LEVEL, channel-specific settings, and cached configuration for every service.
   - Propose LOG_LEVEL=warning where appropriate while preserving required audit, security, payment, and business-event records.
   - Explain how to refresh cached configuration and long-running processes so changes take effect.

For every finding, show:

- Affected service and runtime.
- Exact configuration or script file path and current line numbers.
- Existing code or configuration snippet.
- Evidence of the issue and why it adds overhead.
- Whether the finding is confirmed or needs measurement.
- Clearly labelled proposed before/after configuration, scripts, or commands—do not apply them.
- Risks, prerequisites, focused validation, and rollback steps.

Capture a baseline and propose comparable before/after measurements for representative pages and actions: response time, Apache %D, PHP-FPM slow logs, CPU and memory usage, and OPcache statistics. Keep workload and test conditions consistent. Treat the claimed 40–70% improvement as an unverified estimate, not a guaranteed result.

Finish with a prioritized, service-by-service implementation plan. Explain the proposed settings and deployment changes clearly enough for me to review and recommend adjustments.

Stop and wait for my approval. After approval, implement only the agreed changes, preserve existing functionality, and report changed files, line numbers, executed commands, validation results, rollback readiness, and measured improvements. Avoid unrelated refactoring.