Re: Ways to scale a mod_perl site

On Sat, Sep 19, 2009 at 11:43 AM, Tina Müller wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Fri, 18 Sep 2009, Igor Chudov wrote: > > On Fri, Sep 18, 2009 at 10:13 AM, Tina Mueller >> wrote: >> >> > How does the user invalidate that "session"? (in case the cookie leaked >> > or

Re: Ways to scale a mod_perl site

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 18 Sep 2009, Igor Chudov wrote: On Fri, Sep 18, 2009 at 10:13 AM, Tina Mueller wrote: > How does the user invalidate that "session"? (in case the cookie leaked > or something like that). Or how can the website owner log out a certain > use

Re: Ways to scale a mod_perl site

On Sep 16, 2009, at 9:13, Brad Van Sickle wrote: I've never seen the need to do that. In fact, I would suggest you drop sessions altogether if you can. If you need any per-session information then put it in a cookie. If you need this information to be tamper-proof then you can create a has

Re: Ways to scale a mod_perl site

While many great minds are here, I would like to focus on one point for a moment, which in my experience, has been the most critical: The database Before I were to ask any other of your questions (all of which were valid), I would ask myself: - What kind of database tables am I implementing? (i

Re: Ways to scale a mod_perl site

On Fri, Sep 18, 2009 at 12:11 PM, James Smith wrote: > Igor Chudov wrote: > > > > On Fri, Sep 18, 2009 at 10:13 AM, Tina Mueller wrote: > >> On Wed, 16 Sep 2009, Michael Peters wrote: >> >> On 09/16/2009 12:13 PM, Brad Van Sickle wrote: >>> >>> Can I get you to explain this a little more? I do

Re: Ways to scale a mod_perl site

On Fri, Sep 18, 2009 at 10:13 AM, Tina Mueller wrote: > On Wed, 16 Sep 2009, Michael Peters wrote: > > On 09/16/2009 12:13 PM, Brad Van Sickle wrote: >> >> Can I get you to explain this a little more? I don't see how this could >>> be used for truly secure sites because I don't quite understand

Re: Ways to scale a mod_perl site

On 09/18/2009 12:16 PM, Ihnen, David wrote: Its security through obscurity admittedly - security in that you can't see my code, methodology, or shared secret configuration. No it's not really through obscurity. Even if someone found out your method of serialization your data is still safe. I

RE: Ways to scale a mod_perl site

to:bvansick...@gmail.com] Sent: Wednesday, September 16, 2009 9:13 AM To: Michael Peters Cc: Mod_Perl Subject: Re: Ways to scale a mod_perl site > >> 3) Being enabled by item 2, add more webservers and balancers >> 4) Create a separate database for cookie data (Apache::Session object

Re: Ways to scale a mod_perl site

Tina Mueller writes: > On Wed, 16 Sep 2009, Michael Peters wrote: > [...] >> If you need to store per-session data about a client that the client >> shouldn't be able to see, then you just encrypt that data, base-64 >> encode it and then put it into a cookie. > > How does the user invalidate that

Re: Ways to scale a mod_perl site

Brad Van Sickle writes: >> >>> 3) Being enabled by item 2, add more webservers and balancers >>> 4) Create a separate database for cookie data (Apache::Session objects) >>> ??? -- not sure if good idea -- >> >> I've never seen the need to do that. In fact, I would suggest you >> drop sessions alt

Re: Ways to scale a mod_perl site

On 09/18/2009 11:13 AM, Tina Mueller wrote: How does the user invalidate that "session"? (in case the cookie leaked or something like that). Or how can the website owner log out a certain user? When you generate the hash for the cookie, you can also include the timestamp and the IP address of

Re: Ways to scale a mod_perl site

On Wed, 16 Sep 2009, Michael Peters wrote: On 09/16/2009 12:13 PM, Brad Van Sickle wrote: Can I get you to explain this a little more? I don't see how this could be used for truly secure sites because I don't quite understand how storing a hash in a plain text cookie would be secure. If you

Re: Ways to scale a mod_perl site

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 unsubscribe Jeff Peng wrote: > > -Original Message- >> From: Brad Van Sickle >> Sent: Sep 17, 2009 12:13 AM >> To: Michael Peters >> Cc: Mod_Perl >> Subject: Re: Ways to scale a mod_perl site > &

Re: Ways to scale a mod_perl site

On Fri, Sep 18, 2009 at 8:12 AM, Fayland Lam wrote: > This? > http://search.cpan.org/~jkrasnoo/ApacheCookieEncrypted-0.03/Encrypted.pm > > Catalyst has a plugin: > > http://search.cpan.org/~lbrocard/Catalyst-Plugin-Cookie

Re: Ways to scale a mod_perl site

This? http://search.cpan.org/~jkrasnoo/ApacheCookieEncrypted-0.03/Encrypted.pm Catalyst has a plugin: http://search.cpan.org/~lbrocard/Catalyst-Plugin-CookiedSession-0.35/lib/Catalyst/Plugin/CookiedSession.pm Thanks. On Fri, Sep 18, 2009 at 9:06 PM, Igor Chudov wrote: > Michael, you inspired me

Re: Ways to scale a mod_perl site

Michael, you inspired me to reimplement cookies this way. For my site, the cookie table is the most frequently updated one (even though I do not grant cookies to search engines). I will try to use this kind of implementation. Even now, my users like the fact that they can stay signed on forever,

Re: Ways to scale a mod_perl site

-Original Message- >From: Brad Van Sickle >Sent: Sep 17, 2009 12:13 AM >To: Michael Peters >Cc: Mod_Perl >Subject: Re: Ways to scale a mod_perl site > but I was unaware that there might be >an option for doing this without using a DB with mod_perl . As Tina

Re: Ways to scale a mod_perl site

3) Being enabled by item 2, add more webservers and balancers 4) Create a separate database for cookie data (Apache::Session objects) ??? -- not sure if good idea -- I've never seen the need to do that. In fact, I would suggest you drop sessions altogether if you can. If you need any per-se

Re: Ways to scale a mod_perl site

On Wed, 16 Sep 2009, Igor Chudov wrote: On Wed, Sep 16, 2009 at 11:05 AM, Michael Peters wrote: Reducing DB usage is more important than this. Also, before you go down that road you should look at adding a caching layer to your application (memcached is a popular choice). It is not going to

Re: Ways to scale a mod_perl site

-Original Message- >From: Phil Van >Sent: Sep 18, 2009 4:10 AM >To: Jeff Peng >Cc: modperl-list >Subject: Re: Ways to scale a mod_perl site > >Just curious: since you are already running FastCGI, why not serving >dynamic contents directly via it? we needed

Re: Ways to scale a mod_perl site

On Thu, Sep 17, 2009 at 4:23 PM, Torsten Foertsch wrote: > I'd go for Apache's mod_cache + mod_disk_cache. The only thing you have > to do is to set cache control headers. Mod_cache is really fast b/c it > skips almost all of the http request cycle. And in your case it takes > load from the datab

Re: Ways to scale a mod_perl site

On Wed 16 Sep 2009, Igor Chudov wrote: > >> I have very little static content. Even images are generated. My > >> site generates images of math formulae such as (x-1)/(x+1) on the > >> fly., > > > > I can understand generating them on the fly for flexibility > > reasons, but I'd cache them, and ser

Re: Ways to scale a mod_perl site

: > > > -Original Message- >>From: Cosimo Streppone >>Sent: Sep 17, 2009 3:43 AM >>To: Mod_perl users >>Cc: Jeff Peng >>Subject: Re: Ways to scale a mod_perl site >> >>Jeff Peng wrote: >> >>> How many servers? >>

Re: Ways to scale a mod_perl site

Igor Chudov wrote: Guys, I completely love this discussion about cookies. You have really enlightened me. I think that letting users store cookie info in a manner that is secure (involves both encryption and some form of authentication), instead of storing them in a table, could possibly result

Re: Ways to scale a mod_perl site

-Original Message- >From: Cosimo Streppone >Sent: Sep 17, 2009 3:43 AM >To: Mod_perl users >Cc: Jeff Peng >Subject: Re: Ways to scale a mod_perl site > >Jeff Peng wrote: > >> How many servers? >> We have run the systems with about 500 million PV

Re: Ways to scale a mod_perl site

In data 17 september 2009 alle ore 09:43:50, Cosimo Streppone ha scritto: Jeff Peng wrote: How many servers? We have run the systems with about 500 million PV each day, with many squid boxes + 200 apache webservers + 200 mysql hosts. The applications were written with FastCGI. Wow! Wh

Re: Ways to scale a mod_perl site

Jeff Peng wrote: How many servers? We have run the systems with about 500 million PV each day, with many squid boxes + 200 apache webservers + 200 mysql hosts. The applications were written with FastCGI. Wow! Why don't you tell or blog a bit about this? I would love to know more about what

Re: Ways to scale a mod_perl site

scale a mod_perl site My algebra.com server serves about 77k pageviews and a little over a million objects requests per day (with half of it being served in just 4 hours). I peak out at 35 requests per second currently. I use mod_perl, mysql, and perlbal with everything running on one server

Re: Ways to scale a mod_perl site

Igor Chudov writes: > My algebra.com server serves about 77k pageviews and a little over a million > objects requests per day (with half of it being served in just 4 hours). I > peak > out at 35 requests per second currently. Some high-level advice: Profile everything you can to see where your

Re: Ways to scale a mod_perl site

Perrin, thanks a lot. I bought all books recommended below. Should be a good read. I want to be ready when the need arises, and I do not want to do anything stupid in the meantime that would make me not scalable. Again, thank you. Igor On Wed, Sep 16, 2009 at 1:12 PM, Perrin Harkins wrote: >

Re: Ways to scale a mod_perl site

On Wed, Sep 16, 2009 at 11:49 AM, Igor Chudov wrote: > Any thoughts? In addition to the good advice you're getting on the thread, here are some books you might find useful: - Practical mod_perl -- http://modperlbook.org/ -- is old, but has a lot of general architecture and tuning advice that rea

Re: Ways to scale a mod_perl site

On Wed, Sep 16, 2009 at 12:21 PM, Douglas Sims wrote: > I'm curious... what is the hardware like on the one server? How many CPUs > and RAM? > > AMD Athlon quad core, running 32 bit Ubuntu Hardy. 16 GB of RAM. Algebra.Com data is stored on an SSD> > Also, a few thoughts... > > - You do a 301 f

Re: Ways to scale a mod_perl site

Guys, I completely love this discussion about cookies. You have really enlightened me. I think that letting users store cookie info in a manner that is secure (involves both encryption and some form of authentication), instead of storing them in a table, could possibly result in a very substantial

Re: Ways to scale a mod_perl site

I'm curious... what is the hardware like on the one server? How many CPUs and RAM? Also, a few thoughts... - You do a 301 from algebra.com to www.algebra.com. That doesn't take much work from the server, but why not just serve up everything from the original location? - The algebra problem I j

Re: Ways to scale a mod_perl site

On 09/16/2009 01:02 PM, Igor Chudov wrote: I actually do cache generated pictures, I store them in a database table called 'bincache'. This way I do not have to compute and draw every image on the fly. If I have a picture in bincache, I serve it, and if I do not, I generate it and save it. That

Re: Ways to scale a mod_perl site

On 09/16/2009 12:48 PM, Adam Prime wrote: I have very little static content. Even images are generated. My site generates images of math formulae such as (x-1)/(x+1) on the fly., I can understand generating them on the fly for flexibility reasons, but I'd cache them, and serve them statically

Re: Ways to scale a mod_perl site

On 09/16/2009 12:13 PM, Brad Van Sickle wrote: Can I get you to explain this a little more? I don't see how this could be used for truly secure sites because I don't quite understand how storing a hash in a plain text cookie would be secure. If you need to store per-session data about a client

Re: Ways to scale a mod_perl site

On Wed, Sep 16, 2009 at 11:48 AM, Adam Prime wrote: > Igor Chudov wrote >> >> >> I have very little static content. Even images are generated. My site >> generates images of math formulae such as (x-1)/(x+1) on the fly., >> > > I can understand generating them on the fly for flexibility reasons,

Re: Ways to scale a mod_perl site

Igor Chudov wrote: On Wed, Sep 16, 2009 at 11:05 AM, Michael Peters > wrote: On 09/16/2009 11:49 AM, Igor Chudov wrote: 1) Use a load balancer like perlbal (I am already doing that) A load balancer is good but so are proxies. If you can separat

Re: Ways to scale a mod_perl site

On Wed, Sep 16, 2009 at 11:15 AM, C. J. L. wrote > > I would buy a fast server with 4 or more cpu cores and the SSD or SAS > drives and run the backend db on a dedicated mysql instance. > By the way, guys, the performance difference between a regular SATA drive and a fast SAS drive is comparativ

Re: Ways to scale a mod_perl site

On Wed, Sep 16, 2009 at 11:05 AM, Michael Peters wrote: > On 09/16/2009 11:49 AM, Igor Chudov wrote: > > 1) Use a load balancer like perlbal (I am already doing that) >> > > A load balancer is good but so are proxies. If you can separate your > application server from the server that servers stat

Re: Ways to scale a mod_perl site

On 09/16/2009 11:49 AM, Igor Chudov wrote: 1) Use a load balancer like perlbal (I am already doing that) A load balancer is good but so are proxies. If you can separate your application server from the server that servers static content then you'll get a boost even if they are on the same ma

Ways to scale a mod_perl site

My algebra.com server serves about 77k pageviews and a little over a million objects requests per day (with half of it being served in just 4 hours). I peak out at 35 requests per second currently. I use mod_perl, mysql, and perlbal with everything running on one server. The server has a solid st