Add APC caching

[GoogleCodeExporter]

Create a flexible caching mechanism that will allow users to specify the use of 
APC as the cache instead of the filesystem. This should give things a speed 
boost.

Original issue reported on code.google.com by joe.lencioni on 14 Jun 2010 at 9:00

[GoogleCodeExporter]

I think it will be much better just to store cache files in directories with 
names corresponding to request, like this:

/slir/w100-h100/path/to/image.jpg

And add in .htaccess this string:

RewriteCond %{REQUEST_FILENAME} !-f 

So when Apache get request like /slir/w100-h100/path/to/image.jpg he checks if 
file DOCUMENT_ROOT/slir/w100-h100/path/to/image.jpg exists. If file is found so 
apache don't call PHP and just send file to client. If file not found so apache 
call PHP, and SLIR generate cache file and makes header('Location: 
slir/w100-h100/path/to/image.jpg'); So in this case PHP will never be used to 
read-and-send images content to client - this is very good for server server 
memory, processor and connection speed.

Don't you think so?

Original comment by barbushin on 29 Jul 2010 at 2:07

[GoogleCodeExporter]

I agree--I'm not entirely sure that APC caching will be all that appropriate 
for SLIR, but it is worth thinking about.

I really like your proposal in regards to memory and processor usage, but there 
are a few reasons why I haven't implemented it that way.

1. It will clutter up the SLIR directory.
2. Ideally, the SLIR cache should be stored outside of the web tree for 
security purposes.
3. Most importantly, SLIR needs to check the source file to see if it is newer 
than the cached file on each request. If it is, it needs to re-render and 
re-cache. Your proposed solution breaks this functionality.

Original comment by joe.lencioni on 29 Jul 2010 at 2:15

[GoogleCodeExporter]

1. Whats the problem to use /slir/images/... directory?

2. I don't understand why? Anyway if there are links like 
/slir/w100-h100/path/to/image.jpg so user share pictures to anybody. If he want 
to make them more secure he can make some secure names 
/slir/w100-h100/path/to/hAsHdjkdl1dsa.jpg

3. This is not so big problem like dead server because of 100 SLIR requests per 
second. There are some issues like manual cache clearing by user, or 
automaticaly clear cache by CRON.

I need to say, that I trying to use SLIR today, and when I saw that there are 
no file-caching I changed my mind about using it, because I was scared: what 
will happen with my server if I will have > 100 SLIR-requests per second?

You should understand that 100 SLIR-requests can be just 1 page visited by 1 
user where there are 100 photos that must be resized.

Original comment by barbushin on 29 Jul 2010 at 2:31

[GoogleCodeExporter]

> Whats the problem to use /slir/images/... directory?

If the images are stored in /slir/images/..., that .htaccess rule will not 
work. For the .htaccess rule to work, the files (or in this case, directories) 
would need to be stored in the SLIR directory.

> I don't understand why? Anyway if there are links like 
/slir/w100-h100/path/to/image.jpg so user share pictures to anybody. If he want 
to make them more secure he can make some secure names 
/slir/w100-h100/path/to/hAsHdjkdl1dsa.jpg

I don't mean it will make the images more secure, I mean it will make your web 
server more secure. The potential problem is that if the web server can write 
to a directory that is directly servable by the web server, someone may be able 
to trick the server into writing a PHP script there and then have access to it.

> This is not so big problem like dead server because of 100 SLIR requests per 
second.

If you are using an opcode cache like APC, the PHP hit is pretty minimal when 
SLIR is serving cached images. Even without an opcode cache, it isn't too bad.

> There are some issues like manual cache clearing by user, or automaticaly 
clear cache by CRON.

Indeed, periodic cache clearing needs to be addressed.

> I saw that there are no file-caching

What do you mean by this? SLIR has a cache of rendered images and symlinks to 
the rendered images based on the individual requests (because different 
requests can produce the same rendered image).

Original comment by joe.lencioni on 29 Jul 2010 at 2:49

[GoogleCodeExporter]

> If the images are stored in /slir/images/..., that .htaccess rule will not 
work.

Of course I mean that .htaccess must be rewrited.

> If you are using an opcode cache like APC, the PHP hit is pretty minimal when 
SLIR is serving cached images. Even without an opcode cache, it isn't too bad.

 course I'm talking not about processor-time and memory that will be used by PHP parser. I'm talking about processor-time and memory that will be used by GD extension for imges resizing.

And otherwise one PHP process takes at least 3mb or memory, so 3mb * 100 
processes = 3Gb of memory will be required to let them work in 1 second... and 
there must be very very good processor to  let them work so quickly.

> The potential problem is that if the web server can write to a directory that 
is directly servable by the web server, someone may be able to trick the server 
into writing a PHP script there and then have access to it.

There is only one unsecure problem in this case - stuppid developer, that will 
write some code that can be used to hack his server. But I can say, that if 
developer is so stuppid - he will not care about 777 or 755 rights of any other 
folders, so anyway he will be hacked. 

Do you know such very popular library like PHPSpeedy? This library is realy 
very very popular, and this lib also uses DOCUMENT_ROOT/cache/ dir to write 
there some cache files. And 1000 projects that use this library don't care 
about this, because without this feature library will not have sense to be 
used. IMHO I can say the same about  SLIR - without realtime file cache this 
library is very dangerous for server highload stability, and this is very 
critical problem to use it.

>> I saw that there are no file-caching

I mean that there are no caching to the files that are sending to client only 
by Apache (without PHP).

This is very bad when PHP is used to send static resources (like images, JS, 
CSS...) because every PHP process costs to much memory and processor time, so 
"smart" developers and system administrators always trying to never allow PHP 
do this. Most smart developers and sysadmins are using Nginx, because even 
Apache is not so good to send many resources files to client.

And you're talking about don't use shared file caching, and send and sometime 
evern render images everytime by PHP? Ok, it's possible, but only on not so big 
projects.

Original comment by barbushin on 29 Jul 2010 at 3:25

[GoogleCodeExporter]

You make some interesting points. Will you send me a patch that incorporates 
these ideas?

Original comment by joe.lencioni on 29 Jul 2010 at 4:38

[GoogleCodeExporter]

I just write my own lib for this case, you can take a look how it works 
https://code.google.com/p/primage and make patch by yourself

Original comment by barbushin on 1 Aug 2010 at 5:30