On Tue, 18 Jan 2000, Leslie Mikesell wrote:
> According to Stas Bekman:
>
> > We all know that mod_perl is quite hungry for memory, but when you have
> > lots of SQL requests, the sql engine (mysql in my case) and httpd are
> > competing for memory (also I/O and CPU of course). The simplest solution
> > is to bump in a stronger server until it gets "outgrown" as the loads
> > grow and you need a more sophisticated solution.
>
> In a single box you will have contention for disk i/o, RAM, and CPU.
> You can avoid most of the disk contention (the biggest time issue)
> by putting the database on it's own drive. I've been running dual
> CPU machines, which seems to help with the perl execution although
> I haven't really done timing tests against a matching single
> CPU box. RAM may be the real problem when trying to expand a
> Linux pentium box.
Adding another disk wouldn't cut I/O times because the database is the
only one who does I/O - since mod_perl processes has all the code loaded
in memory. (I'm talking about code that does pure perl and sql processing)
so it's clear that the DB is I/O and CPU bounded (RAM only if there are
big joins to make) and mod_perl CPU and mostly RAM bounded.
> > My question is a cost-effectiveness of adding another cheap PC vs
> > replacing with new expensive machine. The question is what are the
> > immediate implications on performace (speed)? Since the 2 machines has to
> > interact between them. e.g. when setting the mysql to run on one machine
> > and leaving mod_perl/apache/squid on the other. Anyone did that?
>
> Yes, and a big advantage is that you can then add more web servers
> hitting the same database server.
good!
> > Most of my requests are served within 0.05-0.2 secs, but I afraid that
> > adding a network (even a very fast one) to deliver mysql results, will
> > make the response answer go much higher, so I'll need more httpd processes
> > and I'll get back to the original situation where I don't have enough
> > resources. Hints?
>
> The network just has to match the load. If you go to a switched 100M
> net you won't add much delay.
Everything is relative :)
> You'll want to run persistent DBI
> connections, of course, and do all you can with front-end proxies
> to keep the number of working mod_perl's as low as possible.
This is not different from the single box solution. I don't need this, but
if someone needs a different connection for each user, you cannot use
persistance for that.
> > I know that when you have a really big load you need to build a cluster of
> > machines or alike, but when the requirement is in the middle - not too
> > big, but not small either it's a hard decision to do... especially when
> > you don't have the funds :)
>
> The real killer time-wise is virtual memory paging to disk. Try to
> estimate how much RAM you are going to need at once for the mod_perl
> processes and the database and figure out whether it is cheaper to
> put it all in one box or two. If you are just boarderline on needing
> the 2nd box, you might try a different approach. You can use a
> fairly cheap box as a server for images and static pages, and perhaps
> even your front-end proxy server as long as it is reliable.
That's easy. I don't let my box doing even a single page swapping by
setting the limit on the number of procs allowed to be spawn. Works
wonderful.
_______________________________________________________________________
Stas Bekman mailto:[EMAIL PROTECTED] http://www.stason.org/stas
Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC
perl.apache.org modperl.sourcegarden.org perlmonth.com perl.org
single o-> + single o-+ = singlesheaven http://www.singlesheaven.com
