Stas:
One other thing you might want to mention in your thread: the use of
Apache::DBI to maintain persistent connections to the DB can cause a
problem if you have multiple modperl servers all talking to the same DB
server.
For instance, on our site, we have 2 hosts running modperl, each of which
is set to have a MaxClients of 128 (probably too much, but...) In
addition, there are various conventional CGIs talking to the same
host running a MySQL server. If we try to run more modperl servers (or
even during heavy traffic times with only 2 modperl servers), we
frequently see MySQL errors from "maximum number of connections exceeded".
This makes sense, as all of those long-lived, persistent DB connections
are presumably tieing up MySQL resources...
Granted, this is using MySQL pretty much out of the box, without much
attention spent on whether it is possible to configure a larger connection
limit, but I think it's something folks might want to be aware of.
Not sure if I've added anything to this thread, but...
<Steve>
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.
>
> > 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.
>
> > 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. 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.
>
> > 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.
>
> Les Mikesell
> [EMAIL PROTECTED]
>
=-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Steve Reppucci [EMAIL PROTECTED] |
Logical Choice Software http://logsoft.com/ |
508/958-0183 Be Open |
