Обсуждение: Benchmarking

Поиск
Список
Период
Сортировка

Benchmarking

От
mixo
Дата:
How can I benchmark the perfomance of Pg with the following setup:
  Perl 5.8.0 (perl-DBI, perl-DBI-Pg)
  postgresql-7.3.2-3
  apache-2.0.40-21
  mod_perl-1.99_07-5

I want to compare the perfomance of Pg against that of Mysql using my
own data.


Re: Benchmarking

От
Paul Thomas
Дата:
On 08/07/2003 09:14 mixo wrote:
> How can I benchmark the perfomance of Pg with the following setup:
>  Perl 5.8.0 (perl-DBI, perl-DBI-Pg)
>  postgresql-7.3.2-3
>  apache-2.0.40-21
>  mod_perl-1.99_07-5
>
> I want to compare the perfomance of Pg against that of Mysql using my
> own data.

IMHO, the first thing you should do is configure each database to provide
its optimum performance with your hardware and data. Anything less would
not be a fair comparison.

There are a number of open source web testing tools around. Apache JMeter
is a good one.

HTH

--
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller
Business |
| Computer Consultants         |
http://www.thomas-micro-systems-ltd.co.uk   |
+------------------------------+---------------------------------------------+

Re: Benchmarking

От
Chris Travers
Дата:
Re performance tuning-- PostgreSQL is configured out of the box to start
on just about anything.  It is not configured for performance.   If you
want decent performance with many concurrent connections, try setting
the shared_buffers to 1000 and make sure that Postgresql will start.
That is a good place to start.

Apache2 comes with a benchmarking tool called ab that I have found
useful.  I am not familiar with others.


Re: Benchmarking

От
mixo
Дата:
Perfomance matters the most. So, what would be the ideal setup for
permomance in
Pg?
Machine specs:

   PIII 1.0 GHz
   640 MB Ram
   36 Gig Hd partions as follows:
                                                      /dev/sda1
linux swap    1   Gig

/dev/sda2           /                   11 Gigs
                                                      /dev/sda3
          /var              11 Gigs
                                                      /dev/sda4
          Free             11 Gigs

/dev/sda4 is not currently mounted, so that in future when redhat has
new releases,
the insallation can be made without changing the existing installtion

Chris Travers wrote:

> Re performance tuning-- PostgreSQL is configured out of the box to
> start on just about anything.  It is not configured for performance.
> If you want decent performance with many concurrent connections, try
> setting the shared_buffers to 1000 and make sure that Postgresql will
> start.  That is a good place to start.
>
> Apache2 comes with a benchmarking tool called ab that I have found
> useful.  I am not familiar with others.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings




Re: Benchmarking

От
Richard Huxton
Дата:
On Wednesday 09 Jul 2003 8:20 am, mixo wrote:
> Perfomance matters the most. So, what would be the ideal setup for
> permomance in
> Pg?
> Machine specs:
>
>    PIII 1.0 GHz
>    640 MB Ram
>    36 Gig Hd partions as follows:
[snip]

Nobody can say - will you have one concurrent user or 100? Do you have one
table with 100 rows or 50 tables with 100 million? Are you largely reading or
largely updating?

Try the following settings in postgresql.conf as a start, but that's not to
say they'll be wonderful, just not too terrible.

# shared between backends, measured in 8kB blocks
shared_buffers = 1024
# Memory *per sort* in kB
sort_mem = 1024
# This doesnt control anything, it tells PG how much disk-cache you typically
# have (see output of free / top)
effective cache_size = 10000

You'll want to test with some real data, and real usage patterns. In terms of
your hardware, more RAM or another disk or two would be what I'd spend money
on if I had to.

Once you've got some tests going and have some more information, pop over to
the performance mailing list for further discussion.
--
  Richard Huxton