Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

qwertynik's avatar

Configuring server for high performance laravel app

Attempting to change the server config to support a larger number of concurrent users in the laravel app. Despite making a variety of changes found that the response time does not improve. Note: jMeter is used to load test the app's APIs.

Test Results

Use case 1:

2 Users sending requests for 20 seconds. API Response time: 200ms

Use case 2:

20 Users sending requests for 20 seconds. API Response time: 6.5s

Server Config:

CentOS, 4GB Ram, 2 CPU cores (t3.medium)

  • Web Server: Apache/2.4.6
  • PHP Version: 7.4.6, Laravel Version: 7.27.0, Laravel Debugging: Enabled
  • Database: MariaDB Ver 15.1

Note: APIs being load tested are not using DB. This is mainly to keep the database out of the equation - suggestions for optimal DB settings are welcome. The API primarily is linked with a controller that returns a hardcoded array.

Had increased the server config to xlarge, 2xlarge, and 4xlarge.. Despite that, no significant improvements had been noticed. Strangely the error rates shot up.

The following optimizations/changes have been done:

  • PHP - Use opcache.
  • PHP-FPM: Run multiple threads, servers, etc
  • Apache: Run in event working mode.

What changes should be made to the server config to serve the requests faster? Would choosing nginx and making the necessary optimizations help serve the requests faster?

0 likes
11 replies
automica's avatar

Are your requests doing a lot of activity on your database?

Have you got all your indexes in place?

qwertynik's avatar

@automica Thanks for your response and for asking. To keep the databases out of question, the endpoints being tested do not access the database. However, the databases have relevant indexes in place.

Note: Editing the question to ensure anyone else reading the question has more context.

rodrigo.pedra's avatar

1 - Disable debugging and use production environment

On your server's .env file:

APP_ENV=production
APP_DEBUG=false

2 - Run optimize command after each deploy

On your server's CLI at the project's root directory

php artisan optimize

The optimize command will cache your project's config and routes.

Be sure to add the optimize command to your deploy pipeline (run it on each deployment), so you don't get old config/routes.

Reference: https://github.com/laravel/framework/blob/d1a52d4809105716c668a20260bed722bf386062/src/Illuminate/Foundation/Console/OptimizeCommand.php#L28-L34

3 - OPCache and PHP-FPM

As you have OPCache enabled (which is a good thing in production), also be sure to restart the PHP-FPM process on each deploy. So your app is seeing updated PHP files.

4 - Apache vs nginx

I used to go only for nginx as I perceived it outperforming Apache. But on a recent project, the client insisted on using Apache and for more surprise there were no noticeable differences in performance.

For reference this project used centOS 7, and htaccess module was disabled (most Laravel's pretty URL configuration needed to be moved to the htdocs configuration file).

Only feature were nginx still outperforms Apache (in my experience) is for video streaming.

On the other hand

5 - OS config

There are some other configurations the help increase performance. Search for your php-fpm www.conf file and check the number of child processes allowed, memory usage, etc.

Also check your php.ini's max memory, max execution time, and other configuration.

And lastly see how many open files your Linux installation is configured to handle.

Sorry for not providing detailed instructions here, but I usually use Forge+Ubuntu as I am not a server configuration oriented guy. I had to tweak those configs once for that project where client wanted to use centOS+Apache on a on-premise server, as it was some time ago, I am bringing those tweaks from memory, but should be easy to Google about it.

Hope it helps.

2 likes
qwertynik's avatar

@rodrigo.pedra

Thanks for your time and response.

  • On the server the commands, route:cache and config:cache are being run post deployments
  • To bust the opcache, this package is being used.

Have implemented multiple suggestions that I have come across from my Google search, however no significant benefits yet. Will implement the other suggestions and post the results here.

rodrigo.pedra's avatar

Didn’t know about this package, was doing a similar thing manually.

Thanks for the tip!

Snapey's avatar

in your testing, do you just return ok?

what are you doing in service providers etc?

what is different about use case 2?

Are you trying to measure the response times of the framework or your code?

qwertynik's avatar

@snapey

Thanks for your questions.

  • In the testing, a hardcoded array is being returned from the Controller
  • Neither the existing service providers are added, nor, new ones are added.
  • In terms of 'what' is being tested, nothing is different between use-case 1 and use-case 2.
  • Want to measure the response time of the API. So this includes both the framework and code

Hope this helps.

qwertynik's avatar

@rodrigo.pedra Cool! From what I understand this does not require an FPM restart. Making it all the more useful.

martinbean's avatar

@qwertynik You’re asking us to diagnose performance without knowing anything about your application, what “changes” you’ve done, what resources are being used, etc.

This is going to be like playing pin the tail on the donkey: anything is just going to be a guess.

1 like
qwertynik's avatar

@martinbean Thanks for pointing towards ways to make the question more actionable.

The app currently returns a hardcoded array. No additional service providers are used, other than the ones that come by default. Note: Edited the question with details about what the app returns.

By resources, not certain on what is being referred to. Server configuration has been added. Is more information required on the resources consumed during the testing process?

Please or to participate in this conversation.