Beiträge von Synonym

Sagt mal, was kann das denn sein, wenn der Thunderbird keine Mails mehr empfängt?

Er schreibt zwar noch in der Statusleiste "Nachricht 1 von 284 wird empfangen", wird sie aber nicht. Gleichzeitig läuft der grüne Balken langsam durch und so 3 Min später heißt es "keine neuen Nachrichten". Dann wechselt er zum nächsten Konto und das Spiel beginn von vorn.

Versenden von Mails geht fehlerfrei.

Alex, nein, es ist kein Serverproblem. Habe dort dennoch alles neu gestartet, bleibt beim Fehler.

Thunderbird ist neu gestartet
Rechner neu gestartet
Fehlerkonsole aktiviert (keine Meldungen)
Zugriff per Telnet über CMD geht

Ich habe noch nicht mal ein Log-Eintrag auf dem Server, dass Thunderbird sich einloggt ....

Editor: UltraEdit *** Link veraltet *** allerdings bei mir noch Version 12.20. Damals gekauft und bin zufrieden mit.

Ansonsten: Ok, wenn es wieder geht passt es ja. Aber 5.3.2 erklärt einiges. Gerade im Bereich 5.4.x gab es sehr große Veränderungen, die auch teilweise nicht mehr mit älteren Versionen kompatibel waren.

Mein Problem ist, ich habe in dem Video so gut wie nichts verstanden und das Wort "Penguin" auch nicht bemerkt, zumindest nicht bei Deiner Zeitangabe. Ansonsten hatte ich Dir schon am Telefon gesagt, dass ich hier starke Sprünge habe und die eben nicht mit dem Linkabbau zusammenhängen

So, läuft wieder. War die Config oder was auch immer da drin. Config gelöscht und ohne gestartet, dann wurde sie neu angelegt. Piwik ging. Config vom Server geladen und angesehen. Einen Fehler gefunden. Beim letzten "PluginsInstalled" fehlte das "P", warum auch immer. Also hinzugefügt und wieder hoch geladen. Zack, Piwik ging nicht mehr. Also wieder gelöscht und neu angefangen. Config wieder automatisch erstellt und ging wieder. Runtergeladen, rein gesehen, nun fehlt das "P" nicht ??

In der neuen Config fehlen nun aber alle Einträge für "Plugins[]" und "Plugins_Tracker[]", läuft nun aber seit 2 Tagen stabil.

Hm, kann schon sein, dass da Hoster umstellen. Ob nun aber Modul oder fastcgi spielt eigentlich für den Betrieb keine Rolle. PHP-Versionen ändern sich manchmal. Weiß ich auch noch von Strato, da wurden die Hostingpakete damals von v4 auf v5 umgestellt. Die Nutzer hatten 6 Monate Zeit, alles anzupassen.

Aber Guppy, mal langsam und der Reihe nach.

Du hast also im Backend auf fastcgi umgeschalten?

Du bist Dir sicher, dass die /var/www/vhosts/system/http://domain.de/conf/httpd.config die richtige Datei ist?

Wenn ja, hast Du den Code dort eingebunden und "Habe ich ja - Resultat =0". Was bedeutet "Resultat =0"? Tat sich was oder nichts. Wenn sich nichts tat, dann ist das eher positiv als negativ.

Hast Du nach der Änderung der config auch den Apache neu gestartet? Änderungen wirken da nämlich erst nach einem Neustart und nicht in Echtzeit.

Was ist denn genau der Auslöser für die Aktion?

Und was bedeutet denn das hier: "Lt. Support php über Apache so alt dass gar nicht mehr installiert."?
Was ist "alt"? Die PHP-Version oder die Art der Anbindung, also Apache-Modul und nicht fastcgi oder was?

"Ist derzeit alles zum Kotzen, weil nahezu alle scripte die ich verwende nicht laufen"
Jetzt ist also PHP 5.5.9 drauf. Was war denn vorher drauf?

Kann schon sein, dass die da so heißt:
/var/www/vhosts/system/http://domain.de/conf/httpd.config

Mach Sie doch mal auf und schau rein was drinnen ist. Müsste ja eigentlich die Config dieses einen Hostes sein inkl. Servername, Rootpath etc.

Liegt an PHP. Das <? ?> ist schon lange deprecated.

Zitat von Scheroxx

Habe gerade ein Modul von meinem Hoster entdeckt, der die Produktbilder in der Datenbank komprimiert. Laut der Beschreibung werden die Bilder 25% kleiner. Werde das mal ausprobieren und schauen, ob sich die Ladezeit verbessert.

Die Ladezeit wird sich verkürzen, aber die der ganzen Seite. Da geht es nicht um den Zugriff auf den DOM, also ist das bei Google in der Messung egal, jedenfalls was die WMT betrifft.

Aber ehrlich gesagt, Bilder gehören normalerweise nicht in eine Datenbank, dafür ist die nicht gedacht und letztendlich zu langsam.

Na, ein Fazit habe ich auch nicht wirklich. Das muss Dein System-Admin wissen. An der SW lässt sich also nichts ändern, an der DB-Strukur auch nicht. Bleibt aber noch die DB an sich. Und die Caches der DB, das Filesystem, die Tabellenerstellung etc. Das muss aber Dein Admin wissen, denn der kennt ja das System. Im Notfall einfach Serverleistung erhöhen, aber die Handbremse auf zu machen ist meist besser.

Zitat von Scheroxx

Die Homepage hätte ich dir auch per PN schreiben können Ich hab damals mit deutlich weniger Artikel gestartet und musste dann mehrmals den Server aufstocken. der Server ist jetzt anscheinend auch wieder an der Grenze..

Ich habe gerade mal geschaut, was für einen Server ich habe. Das sind die Daten:
4 CPU Kerne Intel Xeon
8 GB RAM
SSD Raid Festplatten
Debian Linux 64Bit

Frage ist jetzt, was erhöht werden soll?

Huch, den Post hatte ich übersehen. Das kann man so aber nicht sagen, denn das System als ganzes ist unbekannt. Ich würde hier aber auf den RAM tippen und das in Verbindung mit der Config der Dienste. Kann auch sein, dass das System viel zu groß ist, die Dienste nur schlecht konfiguriert sind. Es gibt auch Leute, die ständig die Server erweitern, obwohl das Problem die Software ist @schnellschuss.... Da kommt leider vieles zusammen, was sich aus der Ferne nicht erörtern lässt.

Z.B. *** Link veraltet ***
Da werden für den Kalender an die 30 Mio Datensätze durchsucht. Warten = um die 100ms und das ist langsam, da aktuelle gesonderte Prüfungen laufen.

Umgebung:
Debian 8.3
2 Kerne AMD
2 GB Ram
SATA Software-Raid Platte

meine Hardware ist also deutlich schlechter als Deine, aber wesentlich schneller.

Anmerkung: Viele Datensätze und Treffer... Beste Beispiel ist pagespeed.de von Alex.

https://beispiel.rocks/beispiel.rocks…ap/o/seite-7714

Also alle Seiten mit O und eben Seite 7714. Da werden (weiß es nicht genau) an die 80 Mio Datensätze durchsucht. Status warten = 348 ms

äm, entweder bin ich nun falsch oder dein Script. Auf der Seite sind keine 60.000 Artikel, da pageniert. Wenn die da wirklich 60.000 lädt, aber gar nicht nutzt, dann ist das ein gravierender Fehler. Die Seite besteht aus einer festen Anzahl. Wenn eine höhere Anzahl an möglichen Artikeln zu Problemen führt, dann habt ihr ein Script- und / oder DB-Problem. Zudem geht es nicht um die Darstellung der Seite, sondern um den Abruf des Quelltextes.

Nachtrag: Hatte mich auf Deine Aussagen verlassen und falsch interpretiert. Die Seite /Damenmode/ hat eine reine Ladezeit von über 4 Sek und das wieder "warten", die anderen sind ähnlich. Problemsuche also auch beim Apache, wobei ich noch immer DB glaube,

So, habe endlich mal herausgefunden, um welche Seite es eigentlich geht. Bei Deiner URL oben hat die reine Seite eine Ladezeit von 1,73 Sek, also die reine Seite, kein CSS, JS oder Bilder. Und genau das ist das, was Google auch anzeigt. Davon sind 1,7 Sek vom Typ "Warten", also das ist das zwischen "request senden" und "Beginn der Antwort".

Also als erster Ansatz: Apache
Ist das Problem nur beim Filter und nicht bei anderen, dann scheidet der Apache aus

Bleibt also das Script als solches, PHP und die Datenbank

Caching scheidet aus, denn der Server cached (JS, CSS, Bilder). Die Seite selbst kann nicht gecached werden, da Session benutzt wird. Ist aber nicht so schlimm. Die Wartezeit schon. Sesson-IDs können noch dazu kommen, scheiden in meinem Test aktuell aber aus (habe es verhindert).

Und das deutet hin auf: Schlechte Scripte, schlechte Datenbank-Abfragen (PHP-seitig), schlechte Datenbankanbindung (gerade bei Shared-Hosting) und / oder schlechte Datenbank-Konfiguration (MySql).

Gerade bei Datenbank ist schlecht nicht immer gleich schlecht in dem Sinne. Manchmal sind da so viele Datensätze, dass das eben nicht schneller geht. In dem Fall ist dann schlicht der Server zu langsam.

Ok, eben die URL von Dir gefunden:

/index.php?stoken=2DF70510&lang=0&cnid=04e229d36272186fe2e8859f72f59b7a&actcontrol=alist&cl=alist&tpl=&oxloadid=&fnc=executefilter&fname=&attrfilter%5Bc1f2893f4d70693147c0bd972ed30f4a%5D%5BPrint%5D=1&attrfilter%5Bysstartprice%5D=0&attrfilter%5Bysendprice%5D=1900

Wenn da z.B. eine Session-ID drinnen steckt, die sich ständig ändert, dann bringt auch ein Caching nichts, denn das geht nur, wenn die URL gleich bleibt. Ist dem so, dann muss man sich die Frage stellen, ob die Session-ID immer und vor allem überhaupt erforderlich ist.

Ansonsten primär auch die Datenbank begutachten und die Abfragen. Wo lange dauert so eine DB-Abfrage mit dem Filter. Warum dauert die so lange? Was kann optimiert werden?

Du merkst also, das sind sehr viele Punkte, die aber alle zusammenhängen. Ohne das System zu kennen ist da eine genaue Antwort unmöglich.

Das ist schwer zu sagen, denn es kommt ja auf die Seite und den Server an.

Seite also die Größe, wenn da natürlich 5MB übertragen werden, dann ist das Mist.

Server, der die Daten bereitstellen muss. Auch hier ist es schlecht, wenn der Server erst mal eine Gedenkpause macht, bevor er die Daten ausliefert. Das hängt aber vom Server und der Software ab. Wenn der natürlich erst mal 400ms Daten intern bearbeitet, Datenbanken eventuell langsam sind, oder andere Dienste und die Übertragung dann erst beginnt, dann ist das verlorene Zeit. Zeit die Du nicht mehr aufholen kannst.

Im Grunde sind es ja mehrere Punkte:

-> Request an Server -> interne Verarbeitung Apache -> Verarbeitung PHP, MySQL etc -> Start der Übertragung vom Apache -> je nach Größe unterschiedliche Übertragungsdauer.

Für den Abruf und die Zeit zählt aber alles ab dem "Request". (DNS-Abfrage habe ich mal weg gelassen)

Und wenn z.B. der Zugriff auf MySQL länger dauert oder die Verarbeitung von MySQL, weil gefiltert werden muss, dann sind das Wartezeiten, die in die Gesamtsumme einfließen.

Das Problem oben liegt nicht direkt am "Filter", sondern am Server, Software und Umsetzung. Im speziellen Fall wohl an PHP / MySQL, denn dem Apache ist der Filter auch egal, für den ist das ein Request wie alle anderen auch.

Optimieren geht also nur an den Stellen. Unter anderem auch mit Server-Caching um PHP und MySQL zu entlasten, Browser-Caching per Expires, um zusätzlich den Apache auch noch zu entlasten oder zumindest ETAG, um die Übertragung minimal zu halten. Scripte optimieren, Server-DIenste optimieren, Anbindung optimieren, auch zwischen Apache/PHP und Datenbank etc.

Gerade beim Caching macht es einen großen Unterschied, ob ein Request reinkommt und...

.. der Apache sagt: "Eh Browser, das hast Du schon alles, nimm das einfach"

oder

.. der Apache an PHP übergeben muss, PHP dann eine Anfrage an die Datenbank stellt, diese es zusammensuchen und PHP liefern muss, damit das dann die Daten an den Apache geben kann, damit der es dem Browser sendet.

Ach das meinst Du. Das ist Google primär egal. Was aber nicht egal ist, ist die Ladezeit. Und wenn da mit irgendwelchen Filtern oder anderen Dingen die Verarbeitung / Generierung der Seite länger dauert, ja, dann ist das ein Nachteil. Die Länge der URL ist egal. Es zählt, wie schnell die Seite geladen wird, also die Seite selbst, nicht Inhalte wie Bilder, JS etc.

Und wenn Dein Server auf Grund der Filter länger braucht um die Seite zu generieren und auszuliefern, ja dann ist der Filter so gesehen ein Problem. Oder der Server zu langsam.

158 - 312ms

Was heißt "Filter" ?

Warum heimlich? Wurde doch vor Monaten groß diskutiert, dass das Süßhaufen das einführen will. Unter anderem wegen irgendwelchen Katastrophen und der Kritik, dass man die nur mit "gefällt mir" markieren kann.

Aber aufpassen beim RENEW! Wenn die dann am gleichen Tag laufen, dann geht es auch nicht.