Question posted in 
Say I have a backend application on an internal server.
Say I have another webserver running Apache and PHP which must proxy the first app.
On one hand, I can leverage ProxyPass with Apache with:
ProxyPass / http://myhiddenserver.com/
On the other hand, I could do a simple php script using libcurl to implement the same proxy behavior.
curl_exec( $ch );
What are the cons of the second option compared to the first one? I’m interested in whether there might be bottlenecks being introduced by the PHP script or if the two solutions are kind of equivalent.
I’m talking about servers under high load.
While using Apache is obviously straighforward, the PHP will give me a lot of freedom if I want to do conditional stuffs before proxying (like particular caching).
Thanks!
2
Answers
If you use PHP for proxy requests, your web server will also be involved in it, according to this using only the web server will be better.
But if you want to add some custom logic to the process, it’s better to use PHP.
In any case, these solutions are not equivalent.
Also you should look at Nginx for proxy, it’s may be more efficient solution:
https://serverfault.com/questions/143238/nginx-vs-apache-as-reverse-proxy-which-one-to-choose
Apache lives in front of your PHP application. Apache is always going to receive the web request. So the real question is, should PHP also receive a web request that Apache could have handled on its own, or should you bring PHP into it?
Your response time will be faster if the request never gets to the PHP app, as there will be 1 less set of code involved (probably only milliseconds, but milliseconds can matter at times). It will also be cheaper for you in the long run to just have Apache do the work because if you have PHP do it, then that’s one step closer to needing to upgrade your PHP server sooner. Web applications (PHP in this case) have a maximum amount of simultaneous requests they can handle because they have the whole framework (maybe you’re using Laravel) loaded up into RAM, and simultaneous requests require more CPU power. So if for example your PHP server can handle 50 requests at once because that’s what your hardware is capable of, well if you make PHP be a proxy server, you just used up a fair amount of your available requests. Apache will wait until you have a free PHP worker to fulfill the request, but that waiting means a slower response for users using your PHP application as a whole.
How big of a difference it is could be measured by benchmarks and load testing. You may find that it’s negligible. Maybe this proxy feature will be very unused. But if you have the capabilities to just configure Apache to do the work, and Apache can meet all of your needs, then I would have Apache do it.
Some people may prefer to do it in PHP if they have a team that is proficient in PHP and not Apache, because doing it in PHP makes it easier for them to manage.
In the end this is sort of an opinion question.
But the concrete unopinionated answer is that if you can do it in Apache and feel comfortable with managing it in Apache instead of PHP, you will need to upgrade your PHP server less soon which means it will be cheaper for you, and will have marginally faster response times. (By how much depends on response times and web traffic volume and other factors.)