According to Jeffrey W. Baker:
> I will address two points:
>
> There is a very high degree of parallelism in modern PC architecture.
> The I/O hardware is helpful here. The machine can do many things while
> a SCSI subsystem is processing a command, or the network hardware is
> writing a buff
Marko van der Puil wrote:
> so httpd 1 has just queried the database and httpd 2 is just executing...
> It also has to query the database, so it has to wait, for httpd 1 to finish. (not
> actually how it works but close enough)
> Now httpd 1 has the results from the query and is preparing to rea
Hi,
Thanks for your reaction, still you seem to have misunderstood the point I am
trying to make, and I will post it again in the list.
There's different architectures that you can go with.
1. Put all your servers into one box.
Mysql
mod_perl
httpd_docs (static)
squid
the lot.
When it boggs d
On Fri, 28 Jan 2000, Marko van der Puil wrote:
> There has been an discussion in the Mod_Perl mailing list about whether you
> would profit from splitting your Mod_Perl enabled Apache server and a SQL
> database like MySQL over multiple machines. To give this discussion some
> technical and scient
At 11:16 28-1-2000 +0100, Marko van der Puil wrote:
>Hello,
>
>In response to Stas's question about improving performance by splitting your
>SQL and Apache over diffent machines... Please reads Stas's original posting
>for this discussion.
>
>There has been an discussion in the Mod_Perl mailing li
Hello,
In response to Stas's question about improving performance by splitting your
SQL and Apache over diffent machines... Please reads Stas's original posting
for this discussion.
There has been an discussion in the Mod_Perl mailing list about whether you
would profit from splitting your Mod_P
> 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.
Three other possibly relevant points (reiterating, the guide):
0. Pers
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 whi
> > 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
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 solu
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 "o
Ok, thanks for the asnwers
Seems like a great addon for the guide's performance chapter.
Just to ride on this thread and to make the the section complete, what are
the suggested HW requirements for a machine running a general SQL vs
machine doing pure I/O and CPU (httpd/mod_perl). Let me try:
I
JWB is correct, it is very common to have httpd's and database servers on separate
machines.
To reduce any network latency, you might also consider putting in a dedicated network
connection between the DB box and the
httpd box. Multi-home each box and route all database query traffic onto the
JWB is correct, it is very common to have httpd's and database servers on separate
machines.
To reduce any network latency, you might also consider putting in a dedicated network
connection between the DB box and the
httpd box. Multi-home each box and route all database query traffic onto the
> "SB" == Stas Bekman <[EMAIL PROTECTED]> writes:
SB> Throwing away the cheap box and putting two expensive instead is even
SB> better :) Of course you are right about long-term planning, I was talking
SB> about the case when you don't have to buy the cheap box, since we have it
SB> already..
We had to throw our sql onto another machine( 500Mhz PPIII/FreeBSD/MySQL )
over
the holidays and it
has been, in a word, awesome. Totally incredible. As long as the machines
are on the same network it works great and performance really was boosted
( ~2 million dynamic hits per day over the holiday
> SB> replacing with new expensive machine. The question is what are the
> SB> immediate implications on performace (speed)? Since the 2 machines has to
> SB> interact between them. e.g. when setting the mysql to run on one machine
> SB> and leaving mod_perl/apache/squid on the other. Anyone did t
Stas Bekman wrote:
>
> Well, I've got a performance question
>
> 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
> "SB" == Stas Bekman <[EMAIL PROTECTED]> writes:
SB> replacing with new expensive machine. The question is what are the
SB> immediate implications on performace (speed)? Since the 2 machines has to
SB> interact between them. e.g. when setting the mysql to run on one machine
SB> and leaving m
Well, I've got a performance question
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 get
20 matches
Mail list logo
