Re: mod_php vs fastcgi/php speed [BENCHMARK]

2004-03-19 Thread Arkadiusz Miskiewicz
Dnia Friday 19 of March 2004 20:48, Mirco 'meebey' Bauer napisał:

> migrating from mod to cgi is good as in security, but performance and
> also problems with some scripts.
Could you also test fastcgi? cgi and fastcgi are different beasts.

> Mirco 'meebey' Bauer

-- 
Arkadiusz Miśkiewicz CS at FoE, Wroclaw University of Technology
arekm.pld-linux.org, 1024/3DB19BBD, JID: arekm.jabber.org, PLD/Linux




Re: mod_php vs fastcgi/php speed [BENCHMARK]

2004-03-19 Thread Arkadiusz Miskiewicz
Dnia Friday 19 of March 2004 20:48, Mirco 'meebey' Bauer napisał:

> migrating from mod to cgi is good as in security, but performance and
> also problems with some scripts.
Could you also test fastcgi? cgi and fastcgi are different beasts.

> Mirco 'meebey' Bauer

-- 
Arkadiusz Miśkiewicz CS at FoE, Wroclaw University of Technology
arekm.pld-linux.org, 1024/3DB19BBD, JID: arekm.jabber.org, PLD/Linux



Re: mod_php vs fastcgi/php speed

2004-03-19 Thread Arkadiusz Miskiewicz
Dnia Friday 19 of March 2004 14:32, Shri Shrikumar napisał:

> * How difficult is it to do? (est Man hours would be useful too)
I'm not familiar with apache internals, so I can't say but MPM's are written 
in modular way so it does not need to rewrite whole apache. You would have to 
fix/rewrite only one MPM module.

> * What are the benefits?
Joris replied about that, so I only add few things...

- from what I know no one from apache team is working on fixing perchild (no 
idea why)
- some guy started writting new MPM working in similar way as perchild - it's 
called metux MPM ( http://www.metux.de/mpm/en/?patpage=index,
http://www.sannes.org/metuxmpm/). Unfortunately this project seems to be dead 
(or almost dead), too.
- with perchild you will have each virtual host running under UID/GID 
specified in config file so you will have secure php, cgi, mod_perl, 
mod_python, mod_whatever (currently there are ways to get php and cgi (and 
only these) working under specified UID/GID).

Docs about perchild http://httpd.apache.org/docs-2.0/mod/perchild.html

Right now running apache and having multiple virtual hosts for multiple 
clients is not secure. Each client can look into others *.php, *.inc files, 
read for example database passwords from these files etc.

> Thanks and best wishes,
> Shri

-- 
Arkadiusz Miśkiewicz CS at FoE, Wroclaw University of Technology
arekm.pld-linux.org, 1024/3DB19BBD, JID: arekm.jabber.org, PLD/Linux




Re: mod_php vs fastcgi/php speed

2004-03-19 Thread Arkadiusz Miskiewicz
Dnia Friday 19 of March 2004 14:32, Shri Shrikumar napisał:

> * How difficult is it to do? (est Man hours would be useful too)
I'm not familiar with apache internals, so I can't say but MPM's are written 
in modular way so it does not need to rewrite whole apache. You would have to 
fix/rewrite only one MPM module.

> * What are the benefits?
Joris replied about that, so I only add few things...

- from what I know no one from apache team is working on fixing perchild (no 
idea why)
- some guy started writting new MPM working in similar way as perchild - it's 
called metux MPM ( http://www.metux.de/mpm/en/?patpage=index,
http://www.sannes.org/metuxmpm/). Unfortunately this project seems to be dead 
(or almost dead), too.
- with perchild you will have each virtual host running under UID/GID 
specified in config file so you will have secure php, cgi, mod_perl, 
mod_python, mod_whatever (currently there are ways to get php and cgi (and 
only these) working under specified UID/GID).

Docs about perchild http://httpd.apache.org/docs-2.0/mod/perchild.html

Right now running apache and having multiple virtual hosts for multiple 
clients is not secure. Each client can look into others *.php, *.inc files, 
read for example database passwords from these files etc.

> Thanks and best wishes,
> Shri

-- 
Arkadiusz Miśkiewicz CS at FoE, Wroclaw University of Technology
arekm.pld-linux.org, 1024/3DB19BBD, JID: arekm.jabber.org, PLD/Linux



Re: mod_php vs fastcgi/php speed

2004-03-19 Thread Arkadiusz Miskiewicz
Dnia Friday 19 of March 2004 11:24, Adam ENDRODI napisał:
> Privilege separation and fastcgi is not trivial to solve.  You must
> specify a different interpreter for each user.
Huh? Why different interpreter?
http://www.t17.ds.pwr.wroc.pl/~misiek/index.php/ApacheModFastcgiPHP

> Authorization and fastcgi is also an interesting question
> (just as with interpreted scripts in general).
I did not yet hit that problem

> bit,
> adam

-- 
Arkadiusz Miśkiewicz CS at FoE, Wroclaw University of Technology
arekm.pld-linux.org, 1024/3DB19BBD, JID: arekm.jabber.org, PLD/Linux




Re: mod_php vs fastcgi/php speed

2004-03-19 Thread Arkadiusz Miskiewicz
Dnia Friday 19 of March 2004 11:24, Adam ENDRODI napisał:
> Privilege separation and fastcgi is not trivial to solve.  You must
> specify a different interpreter for each user.
Huh? Why different interpreter?
http://www.t17.ds.pwr.wroc.pl/~misiek/index.php/ApacheModFastcgiPHP

> Authorization and fastcgi is also an interesting question
> (just as with interpreted scripts in general).
I did not yet hit that problem

> bit,
> adam

-- 
Arkadiusz Miśkiewicz CS at FoE, Wroclaw University of Technology
arekm.pld-linux.org, 1024/3DB19BBD, JID: arekm.jabber.org, PLD/Linux



Re: mod_php vs fastcgi/php speed

2004-03-19 Thread Arkadiusz Miskiewicz
Dnia Friday 19 of March 2004 06:42, Joris napisał:
> So far a google search has yielded nothing but unbacked statements (I'll
> clean up the language a bit): "mod_php is a lot fast er than php-cgi",
> and "fastcgi/php is a lot faster than mod_php". Not very usefull.
For me it was 0.7 req/s on one machine with mod_suphp (almost the same thing 
as php-cgi) and 70 req/s with php-fastcgi version.

The interesting thing is that no one works on fixing perchild MPM in apache2 
that would allow to use standard mod_php in secure way :/

It would be great if someone get paid to fix that once for all.

> --
>Greetings
> Joris
> [EMAIL PROTECTED]

-- 
Arkadiusz Miśkiewicz CS at FoE, Wroclaw University of Technology
arekm.pld-linux.org, 1024/3DB19BBD, JID: arekm.jabber.org, PLD/Linux




Re: mod_php vs fastcgi/php speed

2004-03-19 Thread Arkadiusz Miskiewicz
Dnia Friday 19 of March 2004 06:42, Joris napisał:
> So far a google search has yielded nothing but unbacked statements (I'll
> clean up the language a bit): "mod_php is a lot fast er than php-cgi",
> and "fastcgi/php is a lot faster than mod_php". Not very usefull.
For me it was 0.7 req/s on one machine with mod_suphp (almost the same thing 
as php-cgi) and 70 req/s with php-fastcgi version.

The interesting thing is that no one works on fixing perchild MPM in apache2 
that would allow to use standard mod_php in secure way :/

It would be great if someone get paid to fix that once for all.

> --
>Greetings
> Joris
> [EMAIL PROTECTED]

-- 
Arkadiusz Miśkiewicz CS at FoE, Wroclaw University of Technology
arekm.pld-linux.org, 1024/3DB19BBD, JID: arekm.jabber.org, PLD/Linux



Re: squid-wccp-kernel-2.6

2004-02-25 Thread Arkadiusz Miskiewicz
Dnia Saturday 21 of February 2004 14:31, Konstantin Kostadinov napisał:
> hi folks,
>
> a week ago i try to switch our company web-cache on 2.6.2 kernel, we use
> some "cisco stuff" and ip_wccp module [ at now on 2.4 kernel ] for
> squid<->cisco router communication.
>
> i read "rtfm" ;) in cicso-squid.org for ip_wccp module compile for 2.6
> kernels but the case that i heave is that i can't compile the module
> because 2.6 kernels schema i different from 2.4 kernels.
>
> i found one cisco module modified for 2.6 kernels too.
> in two words, i fight one day with it but .. ;)
>
> if someone run ip_wccp on 2.6 kernel i'll be very grateful for some
> know-how
I'm not running it but...

http://ftp.yars.free.net/pub/software/unix/platforms/linux/kernel/drivers/ip_wccp-for2.6.0.c

echo 'obj-m := ip_wccp-for2.6.0.o' > Makefile
make -C /usr/src/linux SUBDIRS=$PWD O=$PWD V=1 modules

> tanks
> Konstantin Kostadinov

-- 
Arkadiusz Miśkiewicz CS at FoE, Wroclaw University of Technology
arekm.pld-linux.org, 1024/3DB19BBD, JID: arekm.jabber.org, PLD/Linux


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]