I have this app/social network i’m about to launch. The back-end uses PHP+ MySQL to serve the Mobile app (iOS and Android) I read a lot of things but they are very confused. They are not CLEAR if an application using APACHE (get data from database receiving in json, load images, load and send messages, post text, etc) will really be faster just because it’s a dynamic content WHEN we’re scaling (like many people using at the same time). Some say it’s the same, some say apache is faster, some test i saw showed nginx faster than apache even for dynamic content when there’s more than 10 requests at the same time. Anyone would tell me if an API (php+mysql) for a mobile app would be faster on APACHE or NGINX? (DEFAULT installation, im not talking about ninja tricks) ??
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
@MrCruz Apache with mod_php is a bit faster than Nginx with php-fpm. I love the simplicity of Nginx and would always go with that. And I find it much easier setting up multiple Nginx in load balancing, which is great for scaling.
But talking about speed and serving dynamic content, then it really hasn’t much to do with Apache or Nginx. Since you need to make sure your application will respond as fast as possible, so it doesn’t hold up one of the connections in Apache/Nginx. So this leads us to PHP and MySQL.
You’ll get much more difference in what version of PHP you’re running. Nothing below version 7.0 is worth looking at, since it’s almost twice as fast as earlier versions.
You might want to switch from MySQL to MariaDB, since it has some extra features. And remember to create correct indexes in your database, since that can easily make 10x the speed difference. Actually you should be using PostgreSQL with it’s JSON storage, but that would be a big change, so let’s skip that.
Make sure everything is cut to the bone and optimized. Optimization/tweaking/tuning actually makes a huge difference. If you’re not interested in that, then just spend more on CPU/RAM and that’ll “fix” it.
I would do a Nginx, php-fpm, MariaDB, and cache with memcached or Redis. All of these can be setup on the same server or each on their own server and multiplied for scale.
Dang, just reloaded and saw the typical great answer from @jtittle :-)
@MrCruz
LTS = Long-Term Support Release. This means that Ubuntu 16.04 will continue to receive updates for a period of 5 years from the date of release. A non-LTS release, such as 16.10, will not.
As far as Ubuntu 16.04 goes, the commands to add the MariaDB repository would be:
@MrCruz
Personally, I’d recommend NGINX over Apache. I find that configuring + optimizing NGINX is far less a chore than it is with Apache, it works out of the box with fastcgi using PHP-FPM (without having to use a module), and it’s also very simple to configure as a web server, reverse proxy, or even a load balancer.
That being said, while the default configuration may work short-term, at some point, to achieve a level of performance needed for your application to scale, you will have to modify configuration and begin tweaking configuration files. There’s really no way around that. The default configuration with NGINX and Apache is meant to get you started, but it’s not really intended for full-on production usage.
The same can be said of PHP/PHP-FPM, MySQL/MariaDB/Percona, etc. Base or stock installations are just a means to get you started. At some point, you’ll have to dive in or hire a sysadmin to do the work for you if you plan on scaling as there’s only so many cases where you can throw hardware at an issue before it no longer works. In doing so, you’ll also end up spending more trying to cope with load than you would hiring a sysadmin to manage it for you (if you’re not comfortable or capable of working from the CLI on your own).