Hello

Thanks for this discussion, everyone. At least I know I'm doing the right thing by optimizing it often. :)

Much quieter site. Size of the database 12 MB; this year (average daily use):
211 unique visitors, 15 simultaneous connections, 761 visits, 1090 pages, 2815 hits, bandwith 6.28 MB.

For comparison: size of the database is 156 MB, 219,675 unique visitors, 881,148 visits, and 730 pages.

A database with a size of around 150MB should not necessitate the optimisation every few days.

I looked into some of the scripts (mlf2, version 2.3.1).

As an example: thread.inc.php contacts the database 11 times to read, change or delete entries. In the script posting.inc.php I found 78 database calls.

To use the script posting.inc.php as an example. If requested, most of the database calls stay untouched. Some are for special purposes like moving or deleting existent postings, others are nessesary to read and write a posting. many of them read or write into one field in a database table to change a timestamp or to mark or lock a thread. There, where data from different tables were requested, queries works with JOINs and that's optimisation in itself.

If the few queries could be optimised, it would be only a little step forward, but I don't think that it sovles the problem. If you and Wima, who reported the same problems, have to optimise the data structures manually, there must be other bottle necks.

Can you tell us please, what you are doing with what piece of software, when you optimise the database? What are the changes you observe?

Same questions will go in german to Wima.

Tschö, Auge