benchmarking

[nightowl]

Dunno if the install-forum is best suited but let's give it a try :

I have installed Postgres and PHP together with Apache. Now I'd like to find out if my site (low budget hardware, just intel P4) would be enough for my site (Linux OS)

Thouhgt I'd run some benchmarking software which could help me find out. I'm currently looking for that software, preferably free.

It would need to test if data can be retrieved fast enough to handle a number of clients and/or process some batch-jobs at night. Problem is that I don't have the data yet to perform the test IRL...

anybody knows a good benchmarking program ?

[saloon12yrd]

Hm I don't know real-life benchmarking tools for that issue (if you find some let me know!) but I administer a server for two local newspapers which do half a milion page impressions (not hits) per month. The system is a single Pentium II with 256 MB RAM.
It's an old system and by now it runs at its limit (loadavg 1.6) but it's not getting visibly slower yet.
I tend to believe that a P4 will fit 🙂)

Greets,

Dominique

[nightowl]

I am still looking for that benchmarking tool so please let me know if anybody has one.

I have ran a list of queries on an existing db once on a pentium 100. It took the queries more than 10 minutes to complete. The same page, the same data, ran on a "real" server (think it was a PowerPC?) in less than 3 minutes ...

I wonder, are you using Postgres too ?

[[deleted]]

the apache webserver comes with a utility called 'ab' which lets you simulate concurrent users and reports the min, max and average speeds.

Just feed it an URL to work with and it will keep requesting that URL as often as you like.

a very simple benchmark thingy is to make PHP keep track of how long the page took to load, using microtime() and print that at the bottom.

But the specs of your machine are just one third of the total performance. Much more important is how you use the database, and how that database is set up.
Does it have proper indexes? does it even have enough memory?

[nightowl]

That is another thing which I would like to find out indeed. I have never set up a decent database-sever before and it is important to test it before it goes into production.

However, I couldn't yet find any source of information about how to set up a database (Postgres) for maximum performance. Indexes are one thing, I know there is an article about them here at PHPBuilder.com.

Is there more about this ?

[[deleted]]

A search on google.com should get you lots of info,
but if you want you could post your database model and we'll have a look at it for you.

[nightowl]

tried it before with a search for postgres benchmarking etc. I didn't get much of a result. I'll keep looking.

The database-model is rather complicated to post. I guess it should be normalised OK, though I have to work on the indexes. Thx for the offer though.

[[deleted]]

Just a structure dump would do, phppgadmin is good for that.
But if you don't want to...

[Anon]

Hi,

 You need to be careful as to how far you normalized your database.  If it is performing joins for most of the requests to it, you are not tuning it properly.  You also need to keep the following in mind; there are two ways to benchmark your system for web access:

1. Consecutive access hits - where users are only on for up to 30 minutes each and you have high volume

2. Prolonged use - where users are on for possibly hours - logged in and taking up your system resources (session environment which may include stored queries).

I would have to say that you need to have a target machine set up and monitor its transaction space usage for Postgre SQL to get a better idea of utilization.

Just my $.02.

Regards,

[[deleted]]

A few notes:

Be very carefull when you don't normalize to the third form.
It may be faster to select from just one table, but you must take great care to keep your data consistent.

Do not, ever, sacrificy consistency for speed. A database is no good if it's fast and full of crap data.

HTTP is stateless, so there is no difference between a user that visits once and a user that stays for hours.

Database transactions cannot span accross HTTP requests.

[Anon]

Hi,

 You're right about normalization.  You SHOULD NEVER substitute data / information consistency for speed; not a good choice if you ever want to work with it.  However, you should not make every data design default to 3rd normal form if it doesn't need it.  I have seen designs that were so far normalized that there were continuos streams of joins that were using quite a bit of resources.  Also, when the data was being used for reports and metrics, it was joined the same way!  That represents too much normalization to the point where the individual data components (tables) were not in a usable form.

 The reference I made to the session pieces was related to tracking session information and requiring resources for it.  If you enable session state and begin attaching information to it, there is a performance price.  And, if you are using a db to store / track session information, the price could be high.

Regards,