Back to Vincent's original request about session id and login: how secure is
your session id? Have you signed it? If not, someone can try to sending
random IDs and break your authentication.
Well, if you sign it and sign it properly, you basically end up with the
same idea in those "Authen + Ticke
On Fri, Jun 24, 2011 at 12:17 PM, Perrin Harkins wrote:
>
>
> Are you comparing that to mod_perl with a proxy server in front of it?
> That is the equivalent architecture. If you remove the proxy,
> mod_perl becomes faster but the scalability suffers. I wouldn't
> recommend anyone run mod_perl
On Fri, Jun 24, 2011 at 8:10 AM, Perrin Harkins wrote:
> On Fri, Jun 24, 2011 at 12:45 AM, Phil Van wrote:
> > One should really try mod_fcgid + perl application. that is lighter,
> faster,
> > and more stable.
>
> FastCGI works fine, but these claims are not true.
One should really try mod_fcgid + perl application. that is lighter, faster,
and more stable.
mod_fcgid provides also authenticate/authorize/access controls, besides
dynamical content.
These are probably all you want to get from mod_perl.
On Tue, Jun 21, 2011 at 2:13 PM, Perrin Harkins wrote:
>
Just curious: since you are already running FastCGI, why not serving
dynamic contents directly via it? Also, you may eliminate Squid. Using
Apache for static content is good enough (easy to get 5k static PV per
second per server, or 400 millions per day).
Phil
On 9/17/09, Jeff Peng wrote:
>
>
Great to hear that! My experience, that programs written in application
frameworks usually take more memory and CPU resources to run, is based on
old versions. The new ones may have been improved very much in this area.
PV
On Fri, Mar 27, 2009 at 1:21 AM, Rolf Schaufelberger wrote:
> Hi,
>
> d
My 2 cents.
Based on daily traffic:
1 - 1000 unique sessions
shared hosting,
=> CGI Perl (CGI.pm)
=> Php
1000 - 5000 unique sessions (fun sites)
shared hosting (modperl is not available)
=> CGI Perl + mod_rewrite (to cache dynamic contents)
=> Php
daily traffic: 5,000 - 20,000 unique sessions (
