At the moment any user-related image references use reference back to a php script. For example, on the viewtopic.php page user avatars are image tags with an src="./download/file.php?avatar=XXXX" and similarly for any images embedded in posts. This mean that when a user browser needs to download an image it must call a php script to do so. The Wikimedia engine uses a similar strategy of image management with the image meta-data in the database, but in this case the location is unwrapped and exposed as a direct src ref to the actual static file in the image store. I think that we should adopt a similar strategy for phpBB.
There are pros and cons to the scripted vs. direct static reference approach. For larger sites running PHP under mod_apache with a PHP accelerator such as Xcache or APC, the performance issues are probably a wash. However, for smaller sites running on an ISPs shared web service (which will be the vast majority of your forums), they will be running the PHP scripts under CGI/suexec or suPHP and without the benefit of a code cache. For such sites, there is a considerably difference in response and throughput for static images which are handled by the directly Apache core and those preprocessed through a PHP script.
I know that download.php does some validation logic and sets various HTTP headers to assist in caching, but the Apache core sets Etag header by default and most ISPs (and apps through .htaccess directive) also set the mod_expires directives to do likewise for static image file types, so this header logic in the download.php is really redundant.
I also realise that the advantage of moving the validation logic into download.php is that this is lazily evaluated only when the browser decides to load the image (and not if it is cached in the browser). However, this code is light compared to the overall phpBB start-up overhead, so moving it into a call in viewtopic which returns the static src reference would still in most cases result in a net processing saving.
Based on a sample of a million page request from our forums, we have:
- View Topic -- 71%
- ATOM feeds --9%
- View Forum -- 8%
- Home Page -- 4%
- UCP (mostly logon) 2%
- Search -- 2%
- Posting -- 1%
- All the other functions -- 3%