pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: PFC <lists@peufeu.com>
To: fzied@planet.tn
To: pgsql-performance@postgresql.org
Subject: Re: scaling up postgres
Date: Sat, 03 Jun 2006 11:57:50 +0200
Message-ID: <op.takdyoomcigqcu@apollo13> (raw)
In-Reply-To: <200606030931.k539V38Y007877@smtp2.planet.net.tn>
References: <200606030931.k539V38Y007877@smtp2.planet.net.tn>


> One beast will be apache, and the other will be postgres.

> I'm using httperf/autobench for measurments and the best result I can get
> is that my system can handle a trafiic of almost 1600 New con/sec.

> NB : apache when stressed for a static page, i can handle more 16k new  
> con/sec

	That's not the point.
	Here are a few points of advice.

	USE LIGHTTPD DAMMIT !

	If you want performance, that is.
	On my server (Crap Celeron) it handles about 100 hits/s on static files  
and 10 hits/s on PHP pages ; CPU utilization is 1-2%, not counting PHP.
	lighttpd handles 14K static pages/s on my laptop. That's about as much as  
your bi-xeon does with apache...

	You want a web server that uses as little CPU as possible so that more  
CPU is left for generating dynamic content.

	Also, you want to have a number of concurrent DB connections which is  
neither too high, nor too low.
	Apache + mod_php needs to spawn a lot of processes, thus you need a lot  
of database connections.
	This tends not to be optimal.

	Too few concurrent DB connections -> network latency between DB and  
webserver will be a bottleneck.
	Too many connections -> excess context switching, suboptimal use of CPU  
cache, memory use bloat.

	So, I advise you to use lighttpd fronting PHP as fastcgi (if you use PHP)  
; if you use Java or whatever which has a HTTP interface, use lighttpd as  
a proxy for your dynamic page generation.
	Spawn a reasonable number of PHP processes. The number depends on your  
application, but from 10 to 30 is a good starting point.

	USE PERSISTENT DATABASE CONNECTIONS !

	Postgres will breathe a little better ; now, check if it is still slow.  
If it is, you need to find the bottleneck...
	I can help you a bit by private email if you want.



view thread (28+ messages)  latest in thread

Message-ID: <op.takdyoomcigqcu@apollo13>
Permalink:  ../op.takdyoomcigqcu@apollo13/
Also on:    postgresql.org/message-id/op.takdyoomcigqcu@apollo13

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: lists@peufeu.com, fzied@planet.tn
  Subject: Re: scaling up postgres
  In-Reply-To: <op.takdyoomcigqcu@apollo13>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox