Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
auf der Site werden alleine 18CSS Dateien geladen
Scripte von Plugins die man vermutlich nicht sitewide braucht
caching wird ziemlich sicher nur für "not logged in " user gemacht
von mir aus fahr das mit einer reinen HTML Site hoch und es wird ewigst und drei Tage brauchen :-)
Hallo!
Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.
Mal daran gedacht, Pagespeed zu deaktivieren und einen richtigen Reverse Proxy einzusetzen?
Dann teste doch mal ausführlich mit einem Standard-Theme.
P.S. Ich würde mal die Angaben in deinem Header reduzieren. Dort ist fast deine halbe Serverkonfiguration sichtbar ;-).
Hallo,
anstatt per Trial & Error in dem Sumpf rumzurühren solltest Du etwas analytischer an das Problem heran gehen. Erste Informationsquellen sind die Logs vom Server, zusätzlich kannst Du über einen Zeitraum von evtl. 2-3 Tagen ein Log von WordPress generieren lassen.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);Das Logfile findest Du dann in wp-content.
Wenn sich die Probleme für angemeldete Benutzer einstellen, ist das ja bereits eine erste Abgrenzung. Ich kenne diese Probleme, wenn Slugs und oder Taxonomien doppelt deklariert wurden. Das bremst WP ungemein aus, weil es zu Fehlern bei den DB-Abfragen kommt und dann Klassen/Funktionen mit leeren Variablen dastehen.
Kann durchaus sein - muss aber nicht. Wie gesagt: die Summe aus Plugins und Verbastelungslevel potenziert sich sehr gerne.
Vor ein paar Wochen hatte ich ein solches Problem bei einer Instanz, die in 3 Sprachen mittels WPML-Plugin übersetzt wurde. Weder Beiträge noch Seiten noch Custom Post Type konnte gespeichert werden. 2 Ursachen wurden ausfindig gemacht: 3 Bugs im WPML-Plugin und ein weiteres Plugin für die Massenbearbeitung von Tags. Teilweise wurden die Slugs ohne Vorwarnung überschrieben und die kompletten Taxonomien im Bereich der Mehrsprachigkeit zerwürfelt. Macht Spaß, so ein Malheur direkt in der Datenbank zu beheben.
Der (Neu)Kunde hat souverän reagiert und wir portieren grade fleissig auf Typo3. ;)
Eine strukturierte Vorgehensweise mit Konzept, Plan und Umsicht ist immer eine gute Sache. Als erfahrener WordPressler (aber keine Super-Experte) programmiere ich das, was ich brauche, lieber selber. WordPress verleitet leider dazu, für jeden Wunsch ein Plugin zu suchen und einzusetzen. Das führt häufig zu Problemen. Natürlich gilt das auch bei anderen Systemen wie Typo3 - auch dort kann man nicht einfach eine Extension installieren und alles läuft. Dafür ist das System selbst schon viel zu komplex.
Eine Alternative zu WordPress ist Ghost. Für den normalen Anwender aber nicht praktikabel, da ohne profundes Wissen schon die Installation scheitert (sofern man kein Hosting bucht).
Wenn Du eingeloggt bist, werden zusätzliche Dinge (u. a. auch Plugins) abgefragt. Das kann sich dann schon mal "beissen" oder schlichtweg die Datenbankabfragen ausreizen. Der Fehler steckt im Detail und das ist bei WordPress ziemlich schwierig einzugrenzen, da es eben über keine ausgereifte Debugroutine verfügt.
Ein Bekannter hatte auch mal eine extreme Bremse in seinem Blog. 2 Tage habe ich ihm unter die Arme gegriffen und wir haben nicht mal Ansatzweise das Problem eingrenzen können. Bis eine Kollegin meinte: "Hat der die Unterverzeichnisse ausgeschaltet?". Klingelingeling! Verzeichnis mit mehr als 10.000 Dateien hat der Server nicht mehr gepackt. Upgrade, ein paar Einstellungen angepasst, läuft. Ein weiteres großes Manko bei WordPress: Themes (und ggf. Plugins) generieren für ihre Bedürfnisse teilweise eine absolute Unmenge an verschiedenen Bildgrößen. WordPress hat hier kein Caching und vor allem kein Processing. DAM und FAL gibt es nicht, auch wenn die Mediathek das irgendwo suggeriert. :)
Was Du noch machen kannst: es gibt das ein oder andere Plugin, was die verschiedenen Taxonomien überprüfen kann. Ich habe hier auch ein kleines PHP-Skript, was die Permalinks ausgibt. Bei Interesse poste ich das mal.
Ghost verfolgt mehr den reinen Blog-Charakter. Ist natürlich auch mehr. Basiert auf node.js, deswegen kann man das nicht einfach runterladen und installieren. Das als kleine Vorabinfo. :)
Ich kann Dir nur empfehlen, bei WordPress auf möglichst viel zu verzichten. Und anstatt alles per Plugin nachzurüsten selber Hand anzulegen. Vieles ist bspw. auch innerhalb des Themes (functions.php) zu erledigen. Erfordert Programmierkenntnisse.
Die WordPress-API generiert von Haus aus sehr viele Datenbankabfragen. Wenn dann noch ein komplexes Theme mit Framework und ein ganzes Bataillon an Plugins hinzu kommt, hat der Webserver schnell eine Spaßbremse. Je nach Konstellation werden dann Cache-Plugins mehr zur Spaßbremse als zu einer Verbesserung der Situation. Abhilfe schafft bei WordPress - so meine eigene Erfahrung - ein Server mit SSD (Datenbank wohlgemerkt).
Hmmm, jetzt verstehe ich nichts mehr...
Nur kann mir mal jemand sagen, was das RSS Widget von Wordpress damit zu tun hat, ob man angemeldet ist, oder nicht? Weil bei Gästen baute sich die Page instand auf. Nun habe ich wieder ca. 4 - 5 Sekunden Ladezeit, was im Rahmen ist.
Ich verstehe den Zusammenhang wie gesagt zwischen RSS Widget und Angemeldet, oder Gast. Absolut nicht.
Das PHPMagazin veröffentlicht zurzeit eine umfangreiche Serie über PHP Profiler im Vergleich. Sie stellen XHProf und auch meinen bevorzugten Xdebug vor.
Da du einen eigenen Server hast, kannst du Xdebug gleich mit Netbeans verbinden und kannst in deiner IDE genau sehen, was wo wie hängt.
Hoffe, die Antwort hilft dir weiter
https://github.com/syamilmj/Aqua-Resizer
Potentielle Quelle für Deine Systembremse! Vermutlich im Theme verankert.
Du kannst mit dem folgenden Befehl unter Linux suchen gehen:
grep -rnw './' -e "aq_resize"Bitte vorher in den Theme-Ordner wechseln (und etwas Zeit mitbringen).
Steht auf der Webseite - generiert On-the-Fly Thumbnails.
Skript als datei.php im Hauptverzeichnis von WordPress speichern (dort wo die wp-config.php ist).
Es sind 2 Varianten für die Datenbankabfrage vorhanden. Wenn es bei der Variante mit WP_Query Probleme geben sollte, kommentier die beiden Zeilen aus und darunter die Abfrage über get_results ein.
Du kannst die Ausgabe auch um weitere Felder ergänzen. Vorsicht bei umfangreichen Instanzen - hier sollte man mit LIMIT arbeiten (Skriptlaufzeit).
<?php
include "wp-load.php";
$posts = new WP_Query('post_type=any&posts_per_page=-1&post_status=publish');
$posts = $posts->posts;
/*
global $wpdb;
$posts = $wpdb->get_results("
SELECT ID,post_type,post_title
FROM {$wpdb->posts}
WHERE post_status<>'auto-draft' AND post_type NOT IN ('revision','nav_menu_item')
");
*/
header('Content-type:text/plain');
foreach($posts as $post) {
switch ($post->post_type) {
case 'revision':
case 'nav_menu_item':
break;
case 'page':
$permalink = get_page_link($post->ID);
break;
case 'post':
$permalink = get_permalink($post->ID);
break;
case 'attachment':
$permalink = get_attachment_link($post->ID);
break;
default:
$permalink = get_post_permalink($post->ID);
break;
}
echo "\n{$post->post_type}\t{$permalink}\t{$post->post_title}";
}Nach der Verarbeitung bitte wieder löschen.
Das kannst Du mit dem Skript automatisieren (SQL-Befehl DISTINCT reicht für den Anfang).
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!