0

So a theoretical scenario:

example.com/picture.jpeg direct link to file

example.com/some-endpoint/picture.jpeg link to php script which reads in the file and returns it as content.

Is there some serious performance penalties for doing something like this? Why I want to do it like this, I want to do some authentication checks, making sure that for example user is authorized to see the file/mofify headers etc...

So apart from the obvious overhead of running PHP framework to serve the file... would this be significantly slower?

Cause I just can't see why it would be any slower to read file with PHP rather than with Apache.. or am I missing something?

galdikas
  • 1,609
  • 5
  • 19
  • 43
  • That is just a bit weird question. Best practice would be to return file by any webserver you have like apache or Nginx. It is absolutely unclear why would you need to return image through php? But technically there is no big difference in performance if you request that file 1/hr or even 1/s and file is small. The question is what will happen if load increases? – Alex Feb 25 '19 at 20:09
  • a random disk I/O request to find the file on disk is and remains a random disk I/O request to get the file it does matter if you are using PHP or Apache (C/C++) for that matter.. The speed will be limited by your disk hardware.. There are some cases for small images to be beter stored in a database then on the filesystem i once found a document about it. – Raymond Nijland Feb 25 '19 at 20:18
  • ... Edited [found](http://www.faculty.jacobs-university.de/pbaumann/iu-bremen.de_pbaumann/Papers/blob-report.pdf) it, they benched it where less then 1MB was faster in a database vs filesystem it's a old document so nowadays that might have changed into a larger value. – Raymond Nijland Feb 25 '19 at 20:18
  • @Alex as I meantioned, If I want only certain users to access file, there is no way for me to ensure that via Apache. And well... what would happen with increased load? – galdikas Feb 25 '19 at 20:19
  • You _can_ ensure access is gated by Apache, but the setup is far more complicated than reusing your application logic and letting PHP do the work. In my experience, that complication is unwarranted. If you're at the scale level where the difference matters, its easier to just scale out than detour around this. – bishop Feb 25 '19 at 20:21
  • Possible duplicate of [Fastest Way to Serve a File Using PHP](https://stackoverflow.com/questions/3697748/fastest-way-to-serve-a-file-using-php) – yivi Feb 26 '19 at 08:09

1 Answers1

1

The more processes involved, the more performance will suffer. So you can expect some performance hit, but how much you will need to measure and then decide if that is worth it for your auth checks. In my experience, the cost is marginal.

One thing, don't forget scaling performance: when you're tying up your PHP processes streaming files you're reducing the total number of processes available to serve other requests.

If you're worried about scale and performance, do everything you can to serve this content up-stream. For example:

  1. Perform the auth check in PHP, then issue a redirect to a CDN with a sufficiently large keyspace (eg UUID) -- you might have to rotate files in this keyspace periodically if you're worried about people reusing these URL.
  2. Require the auth have been performed already and have the load balancers check the auth tokens against an IdP.

When you implement it in PHP, make sure to use something like readfile with output buffering disabled. Otherwise, you're increasing the size of your web service process by the size of the content, which could cause out of memory exceptions.

bishop
  • 37,830
  • 11
  • 104
  • 139