[pLog-svn] resserver usage

Wed Oct 4 22:21:39 GMT 2006

Some more benchmarks I was working on today, tested with curl loading  
the same URL 100 times (a 450kb JPEG file)

testfopen.php
-------------
real    0m11.127s
user    0m1.205s
sys     0m1.893s

direct url
----------
real    0m10.170s
user    0m1.171s
sys     0m1.846s

resserver.php 1.1.1
-------------------
real    1m39.753s
user    0m1.209s
sys     0m2.000s

optimized resserver.php 1.1.1
-----------------------------
real    1m24.475s
user    0m1.210s
sys     0m2.007s

altresserver.php
----------------
real    0m36.123s
user    0m1.230s
sys     0m2.012s

testfopen.php is a test to see how fast a raw fopen()+fread() is in  
PHP, and it's a useless version of resserver.php. "Direct url"  
downloads the URL via the web server, "resserver.php" is the default  
version of resserver.php included in 1.1.1, "optimized resserver.php"  
very similar to the code in 1.1.1 but removed a few things that could  
potentially be removed, and finally "altresserver.php" is a very  
small version of resserver.php that still loads a few classes (like  
GalleryResources and GalleryResource)

Not much to comment on these figures, other than we're currently  
using the slowest method and that direct url would still be the  
preferred way.

At this point I am not sure if it's a good idea to create complex  
rewrite rules or use obscure modules that no user will probably ever  
have available, and instead we should concentrate on doing it  
properly once and for all. Some of these workarounds could be used as  
temporary solutions while we fix what is fundamentally slow (or  
broken), and that is the way in which we handle and serve files.

By the way I've attached the files I used for these tests, although  
if you want to run them you'll need to make a few changes (file  
paths, URLs, etc)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: altresserver.php
Type: text/php
Size: 1830 bytes
Desc: not available
Url : http:// devel.lifetype.net/pipermail/plog-svn/attachments/20061005/762bbc74/altresserver-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resourceserveraction.class.php.new
Type: application/octet-stream
Size: 2787 bytes
Desc: not available
Url : http:// devel.lifetype.net/pipermail/plog-svn/attachments/20061005/762bbc74/resourceserveraction.class.php-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testfopen.php
Type: text/php
Size: 382 bytes
Desc: not available
Url : http:// devel.lifetype.net/pipermail/plog-svn/attachments/20061005/762bbc74/testfopen-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repeat.sh
Type: application/octet-stream
Size: 610 bytes
Desc: not available
Url : http:// devel.lifetype.net/pipermail/plog-svn/attachments/20061005/762bbc74/repeat-0001.obj
-------------- next part --------------

On 4 Oct 2006, at 14:00, Jon Daley wrote:

> On Wed, 4 Oct 2006, Reto Hugi wrote:
>>>  	Yes, this method allows the filename to be seen.  (and I just put
>>> up a .zip file on the same page to test your theory)  The third  
>>> method on
>>> that page does work correctly.
>>
>> ok, that's what I expected (thank for the provided tests, I can't  
>> do ssh
>> connections from work...)
>>
>> To sum it up:
>> - in case we want access control, there's no way around the method  
>> we use
>> now.
> 	No, I disagree.  I believe I can do access control with the  
> rewrites.  I will work on that later today.
>
>> of course protecting direct file access and more advanced features in
>> lifetype are to be implemented yet, but it's an option we have.
>
>> - in case we want a performant download, we need at least server
>> redirection if not direct file access.
> 	Yes.
>
>> - having rewrites for each file is not an option
> 	I am interested in the external program method, perhaps we do  
> different methods, and people can choose which one they want.  The  
> default is the way it is now, x-sendfile and RewriteMap are  
> alternatives for people who want higher performance.  exec(renice  
> +10) is an option for people who just want to keep the resources  
> from sucking up too much processor time, but is also optional.  I  
> think all of these solutions (other than our current method) will  
> cause problems for different groups of people.
>
>> - maybe we should again think about leaving the "real" filenames  
>> on the
>> filesystem. AFAIK the "virtual" filename saved in lifetype's  
>> database has
>> to be unique for a blog as well, and all files are physically  
>> saved under
>> their blog id folder anyway. i don't think it's a problem to use  
>> the real
>> filename. not even regarding security/access control because if  
>> access
>> control is going to be implemented, direct access to the directory
>> /gallery/ has to be blocked anyway (or "gallery" should not even  
>> be under
>> the web root)
>>
>> - leaving the original filenames would ease the redirecting stuff  
>> (i.e.
>> only a handful rewrites would do) and give us nice filenames.
>>
>> - IMO the only reason for redirecting would be to get events within
>> lifetype (for stats or whatever a plugin may do) else, direct  
>> access would
>> be better.
>
>
>
> -- 
> Jon Daley
> http://jon.limedaley.com/
>
> A cement mixer collided with a prison van on the Kingston Pass.
> Motorists are asked to be on the lookout for 16 hardened criminals.
> -- Ronnie Corbett
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://devel.lifetype.net/mailman/listinfo/plog-svn
>