RootForum Community

Ist der Code denn so viel schlechter als beim phpbb? Was ich mich frage, nach dem Link vorhin zur angepassten viewtopic beim phpbb, ob in meiner topic.php denn eine signifikante "Bremse" drin ist?

mark007q wrote:Ist der Code denn so viel schlechter als beim phpbb?

Der Source von PMF ist unleserlicher, enthält Fehler (Backticks, ungeprüften Input, etc.) und ist unter Umständen unsicher. IMHO ist hier phpBB2 das bessere Produkt.

mark007q wrote:Was ich mich frage, nach dem Link vorhin zur angepassten viewtopic beim phpbb, ob in meiner topic.php denn eine signifikante "Bremse" drin ist?

Die gesammte Code-Struktur ist eine Bremse, da hilft nur noch ein kompletter Rewrite.
An Deiner Stelle würde ich auf phpBB2, oder Phorum umsteigen und mich in den jeweiligen Source einarbeiten, um diesen selbst optimieren zu können. Das Optimieren des MySQLd allein reicht bei keiner (Foren-)Software...

Ich hatte vorab auf Forensoftware.de und auch hier mal geschaut:

http://boardunity.de/das-phpmyforum-t2465.html

Da kam das Boardsystem eigentlich recht gut weg, auch wohl hinsichtlich der Performance.

Joe User wrote:IMHO ist hier phpBB2 das bessere Produkt.

Fairerweise muss man sagen, dass das Vanilla phpBB2 auch ziemliche Probleme hat(te).

Roger Wilco wrote:Fairerweise muss man sagen, dass das Vanilla phpBB2 auch ziemliche Probleme hat(te).

ACK, wobei meines Wissens nach, für phpBB2-2.0.22 aktuell "nur" drei eher unkritische Security-Bugs offen sind, einer ist im CVS bereits gefixt. Zudem wird am phpBB2 seit mehreren Monaten vorübergehend nicht mehr gearbeitet, um phpBB3 endlich releasen zu können. Danach wird auch phpBB2 wieder mit Bugfixen versorgt, laut den Entwicklern sollen dann auch endlich normale Bugs behoben werden. Vorerst wird aber alle Kraft in phpBB3 investiert...

So - mein Provider hat nun heute versucht nach den hier empfohlenen 48 Stunden das Script auszuführen.

Dabei tauchten einige Fragen auf:

# ./tuning-primer.sh

- INITIAL LOGIN ATTEMPT FAILED -

Testing Stored for passwords: None Found

- RETRY LOGIN ATTEMPT FAILED -

Could not auto detect login info!

Do you have your login handy ? [y/N] :

Soll diese Frage mit Yes (y) oder mit No (N) beantwortet werden?
Bei Yes werden danach sicherlich Zugangsdaten gefordert.

Könnte mir da jemand weiter helfen?

Viele Grüße
Mark

Der Techniker muss die Zugangsdaten für den MySQL-Root-User eingeben...

Ok, jetzt habe ich die Werte erhalten:

-- MYSQL PERFORMANCE TUNING PRIMER --
- By: Matthew Montgomery -

MySQL Version 4.1.22-max-log i686

Uptime = 2 days 17 hrs 42 min 22 sec
Avg. qps = 10
Total Questions = 2597696
Threads Connected = 1

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/4.1/en/ ... ables.html

SLOW QUERIES
Current long_query_time = 5 sec.
You have 303 out of 2597708 that take longer than 5 sec. to complete
The slow query log is enabled.
Your long_query_time seems to be fine

WORKER THREADS
Current thread_cache_size = 16
Current threads_cached = 15
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 500
Current threads_connected = 1
Historic max_used_connections = 24
The number of used connections is 4% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See "MEMORY USAGE" section to make sure you are not over-allocating

MEMORY USAGE
Max Memory Ever Allocated : 306 M
Configured Max Per-thread Buffers : 2 G
Configured Max Global Buffers : 202 M
Configured Max Memory Limit : 2 G
Total System Memory : 4.98 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 169 M
Current key_buffer_size = 128 M
Key cache miss rate is 1 : 2983
Key buffer fill ratio = 52.00 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 64 M
Current query_cache_used = 20 M
Current query_cach_limit = 2 M
Current Query cache fill ratio = 32.64 %
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current record/read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 6 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 2558 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 1024 tables
You have a total of 166 tables
You have 202 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 172798 temp tables, 8% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 1020 K
Current table scan ratio = 3202 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 291
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'

Das Einzige was man an der my.cnf noch tunen könnte, ist "max_connections = 50", der Rest ist bereits optimal gewählt.

Dein Problem liegt also definitiv in der Forensoftware, die Hardware schliesse ich bei einem Managed-Server mal aus. Entweder Du lebst mit diesen unregelmässig hohen Ladezeiten, oder Du optimierst die Forensoftware, oder Du wechselst die Forensoftware (Empfehlungen siehe oben).

Ok, die max_connections werde ich runter setzen lassen.

Zwei Fragen habe ich noch:

Die Werte für join_buffer_size und query_cache_limit sind die so ok?
Oder sollte man join_buffer herauf setzen? GGf. query_cache_limit auch?

mark007q wrote:Die Werte für join_buffer_size und query_cache_limit sind die so ok?

Ja, die sind vollkommen ausreichend.

Erst einmal (bevor ich das vergesse) vielen Dank für die zahlreichen Denkanstöße. Mich treibt noch eine Frage um:

Meine max_connections waren ja mit 500 nun ganz offensichtlich deutlich zu hoch angesetzt. Was genau bringt denn das Heruntersetzen auf z.B. 50 - ich meine, werden hierdurch an anderen Stellen Ressourcen frei, was sich dann u.U. auf die Performance auswirkt?

Durch das Herabsetzen von max_connections wird etwas ungenutzter RAM freigegeben, was sich bei Deinen 4GB allerdings kaum bemerkbar machen wird...

Woher nimmst du die 4GB?

OK, habe den Swap vergessen :oops:

Seit gestern ist alles deutlich schneller geworden - warum auch immer. Wahrscheinlich liegt es dann doch an dem Cache, der mehr und mehr Wirkung zeigt.

Meiner Meinung nach ist es nun ziemlich schnell:

http://www.polar-chat.de/hundeforum.html

Muss man sich eigentlich wegen diesen Sachen Sorgen machen?

Aborted_clients 114
Aborted_connects 26

Dann habe ich noch ein paar Veränderungen vorgenommen:

Ich habe nun in der index.php und topic.php bestimmte Abfragen mit der if Anweisung nur durchführen lassen, wenn man eingeloggt ist.

Die Anzahl der Datenbankabfragen hat sich hierdurch lt. der Statistikanzeige des Forums minimiert. Weniger Datenbankabfragen = schneller.

Aber macht das denn Sinn auch in Bezug auf PHP? Also mit anderen Worten, ist die if Anweisung dort zur Unterscheidung ob jemand eingeloggt ist oder nicht und dann daraufhin eine Datenbankabfrage durchgeführt wird, sehr Performance "killend"?

matzewe01 wrote: Was ich noch tun würde, z.B. gzip komprimierung bei der ausliferung aktivieren, sofern es Dein Forum unterstützt.

Unterstützt das Forum, aber ich dachte hierdurch würde sich der Seitenaufbau normalerweise verschlechtern?

Ich würde das nicht über PHP, sondern per mod_deflate machen, ist schneller und schont nebenbei noch Ressourcen.

Zumindest habe ich diese Auswahlmöglichkeit:

Wenn Sie diese Option aktivieren, wird das phpMyForum alle Seiten mit GZIP komprimieren um Bandbreite zu sparen. Die komprimierten Seiten werden nur an Benutzer geschickt, deren Browser dies unterstützen. Es gibt allerdings Leistungseinbußen aufgrund des Komprimierens. Um diese Option benutzen zu können, muss der Server die ZLIB unterstützen.

Level 0 - 9 einstellbar.

Dein Anbieter soll mod_deflate im Apache aktivieren und an passender Stelle Folgendes in der httpd.conf eintragen: So werden alle Text-Dateien komprimiert ausgeliefert, sofern der Client dies unterstützt.

Danke für den Tipp, habe ich in Auftrag gegeben und ist auch schon innrehalb von 2 Minuten aktiviert worden.
Das hat der support insoweit angemerkt.

Frage: Ist die Funktionalität hier eigentlich auch aktiviert? Ist die Load Zeit der Seiten hierdurch spürbar besser?

mark007q wrote:Frage: Ist die Funktionalität hier eigentlich auch aktiviert?

Ja, nur in etwas anderer Form, da wir nicht Apache+mod_php sondern Lighttpd+PHP-FCGI einsetzen.

mark007q wrote:Ist die Load Zeit der Seiten hierdurch spürbar besser?

Für die User mit Analog/ISDN-Zugängen auf jeden Fall, die Anderen haben eh kein Problem mit <100kb Text. Eine weitere Senkung der Ladezeit brachte die Optimierung der HTML- und CSS-Dateien.

Bei mir ist nun einige Zeit ins Land gegangen und ich habe mich derweil mit der Optimierung der Datenbankstrukturen beschäftigt und zudem mir versch. Queries angeschaut.

Nun habe ich noch einmal eine generell Frage:

Bei dieser Ausgabe:

Qcache_free_blocks 5677
Qcache_free_memory 26402256
Qcache_hits 3987831
Qcache_inserts 3387158
Qcache_lowmem_prunes 2730
Qcache_not_cached 150643
Qcache_queries_in_cache 25886
Qcache_total_blocks 57579

basierend auf diesen Einstellungen:

query_cache_limit 2097152
query_cache_min_res_unit 4096
query_cache_size 67108864
query_cache_type ON
query_cache_wlock_invalidate OFF

Würden sich da evtl. andere Werte für das query_cache_limit und/oder die query_cache_min_res_unit anbieten?