Live-Site leer im Frontend oder weiterhin laden und nie laden

Ich stehe vor dem seltsamsten Problem in Magento. Wir verwenden die Version 1.9.0.

Von den letzten 2 Monaten ist unsere Live-Site für die verwendeten Browser "leer" oder "lade weiter". In diesem Browser haben wir die Website häufig besucht.

In einigen Browsern funktioniert es einwandfrei. in einigen zeigt leer.

Aber das Backend funktioniert in allen Browsern einwandfrei.

Wir haben Probleme mit Chrome, Mozilla, Opera und allen anderen Browsern.

1) Wenn wir den Browserverlauf [Cache und Cookies] löschen, funktioniert er.

2) Wenn wir die gleiche Seite in einem privaten Fenster öffnen, funktioniert es.

3) Wenn wir die Site in frisch installierten Browsern öffnen, funktioniert sie einige Zeit. wieder leer, nachdem wir die Seite benutzt haben.

4) Wenn wir den Ordner var / session löschen, funktioniert er für einige Zeit für alle Browser. Wieder Website leer.

5) Manchmal wird die Seite weiter geladen und sie wird niemals geladen ...

Ich habe system.log & exception.log überprüft . aber es scheint keine damit verbundenen Fehler zu geben. Wir verwenden https für sichere Seiten. Sogar wir haben Live Andriod App für diese Seite. Manchmal treten schwerwiegende Fehler auf:

**Fatal error**: Allowed memory size of 536870912 bytes exhausted (tried to allocate 85 bytes) in /lib/Zend/Db/Statement/Pdo.php or lib/Varien/Object.php or /lib/Varien/Db/Select.php or app/code/core/Mage/Core/Model/Config.php

wir setzen memory_limit = 1512 Mb in der php.ini

In .htaccess haben wir folgende Dateien.

php_value memory_limit 1512M php_value max_execution_time 18000

das haben wir kommentiert:

ini_set('display_errors', 1);

aber keine fehleranzeige im frontend. Dies ist ein Apache-Fehlerprotokoll :

child pid 23845 exit signal Segmentierungsfehler (11), möglicher Coredump in / etc / apache2

Wirklich zu kämpfen, um dieses Problem zu lösen. Hat dieses Problem mit unserem Code zu tun, oder hat dieses Problem mit der Serverseite zu tun?

ist Browser-Cookie das Hauptproblem? Wenn ja, was müssen Sie tun, um dieses Cookie-Problem für alle Browser zu lösen? Warum funktioniert es, sobald wir den Sitzungsordner gelöscht haben?

Diese Probleme treten beim Surfen auf unserer Website auf.

Aktivieren Sie zunächst den Entwicklermodus in Ihrer .htaccessDatei und fügen Sie am Ende der Datei Folgendes hinzu:

SetEnv MAGE_IS_DEVELOPER_MODE "true"

Bearbeiten index.phpund kommentieren Sie als nächstes die Zeile:

#ini_set('display_errors', 1);

Zeile referenziert:

• https://github.com/OpenMage/magento-mirror/blob/magento-1.9/index.php#L73

Melden Sie sich als nächstes über SSH an und suchen Sie eine Core-Dump-Datei unter /tmpdem angegebenen Segmentfehler. Manchmal kann es auch in der Wurzel sein /oder im Stammverzeichnis der Website selbst zum Beispiel: /var/www/html/videomergerapp/.

Wenn Sie keine Core-Dump-Dateien finden können, möchten Sie möglicherweise einige zusätzliche Direktiven zu PHP / Apache hinzufügen.

Schauen Sie sich hier um:

• /server/470407/how-to-get-a-core-dump-from-apache-when-segfaulting
• http://www.cyberciti.biz/tips/configure-apache-web-server-for-core-dump.html

Sobald Sie die Core-Dump-Datei (en) haben, können Sie gdb(wenn --enable-debug) verwenden, wenn PHP konfiguriert wurde. Sie können diese Bestimmung vornehmen, indem Sie Folgendes über die Befehlszeile eingeben:

php -i | grep debugOder erstellen Sie einfach eine PHP-Skriptdatei in Ihrem Webserver-Stammverzeichnis mit: <?php phpinfo(); ?>und zeigen Sie die Datei über den Webbrowser an, um die PHP-Konfigurationswerte anzuzeigen.

• https://bugs.php.net/bugs-generating-backtrace.php

Wenn es nicht aktiviert ist, können Sie keinen vollständigen Backtrace in PHP selbst erhalten, sondern nur Systemaufrufe auf höherer Ebene und / oder Apache-Backtrace:

Wenn Sie Zugriff auf die Core-Dump-Datei haben und etwas wie das Folgende eingeben, erhalten Sie eine Rückverfolgung, um die Fehlerursache zu ermitteln:

gdb /usr/local/apache2/bin/httpd /tmp/core.2027

Wenn Sie nur zufällige Probleme im Frontend und niemals im Backend feststellen, deuten die meisten Anzeichen auf ein mögliches Problem mit Ihrer Vorlagencodierung hin. Sobald Sie die leeren Seiten erfahren (und / oder Fehler angezeigt, wenn Sie Entwicklermodus und Fehleranzeige aktiviert haben). Melden Sie sich bei Ihrem Administrator an und deaktivieren Sie alle Caches und Cache-Speicher.

Gehen Sie dann zu app/etc/local.xmlund setzen Sie die deaktivierten lokalen Module auf true.

<disable_local_modules>true</disable_local_modules>

Dadurch wird der Auto Loader daran gehindert, Module zu laden app/code/local.

Um Community-Module zu deaktivieren, ist es am einfachsten, die einzelnen app/etc/modulesModuldefinitionsdateien zu durchsuchen und zu deaktivieren, indem Sie den aktiven Knoten wie folgt auf false setzen:

<active>false</active>

Auf diese Weise können Sie ausschließen, ob ein Modul eines Drittanbieters die Ursache des Problems durch den Prozess der Beseitigung verursacht. HINWEIS: Sie können nicht disable_local_modulesalle NON-CORE- Module durchsuchen (alles, was Mage_ * ignoriert!).

Wenn es immer noch Probleme gibt, würde ich versuchen, ein Standardvorlagenpaket vorübergehend zu erstellen, indem ich zu System> Design gehe und ein neues Design wie Standard oder Basis definiere. Wenn die Standardvorlagenpakete funktionieren, wissen Sie, dass die Fehlerursache in Ihren Vorlagendesigndateien (.phtml) liegt.

Viele Vorlagen, auf die ich gestoßen bin, verwenden schlecht Mage::getModel()->load()foreach-Schleifen, da dies eine schlechte Praxis ist und letztendlich große Mengen an Serverspeicher und Ressourcen verbrauchen kann.

Magento verfügt über ein Code-Analyse-Tool, mit dessen Hilfe Sie Ihre Vorlagendateien scannen können, um festzustellen, ob einer der folgenden fehlerhaften Codeteile vorhanden ist:

• https://github.com/magento-ecg/magniffer

Weitere Lektüre:

• Grundlagen zum Debuggen eines Magento-Stores

Außerdem kann es für alle hilfreich sein, welchen Cache und Sitzungsspeicher Sie verwenden, der in definiert ist app/etc/local.xml.

Hoffe das hilft!

Ich vermute, es gibt eine Rekursion in Ihrem Code. Bearbeiten Sie die Datei lib/Varien/Db/Adapter/Pdo/Mysql.phpund setzen Sie $_debugund $_logCallStackauf true. Dies sollte den Aufrufstapel in einer var/debug/pdo_mysql.logDatei protokollieren, die Ihnen eine Vorstellung davon geben sollte, ob Ihr Code eine Rekursion aufweist, wenn das Laden für immer dauert. Beachten Sie, dass diese Datei weiterhin sehr schnell wächst. Aktivieren Sie sie daher im Idealfall, wenn Sie glauben, dass das Problem vor Ort aufgetreten ist.

Eine andere Möglichkeit besteht darin, fehlerhafte Module / Erweiterungen zu deaktivieren, von denen Sie glauben, dass sie dies verursachen könnten. Dies kann auch Ihre einfache konfigurierbare Preiserweiterung sein. Versuchen Sie, sie vorübergehend zu deaktivieren, und prüfen Sie, ob sie das Problem verhindert.

Ich hatte das gleiche Problem auf einer Kundenwebsite. Überprüfen Sie Ihr Magento auf Malware.

Dies ist ein bekanntes Szenario. In der Regel handelt es sich um eine Walware, die den Inhalt der Beiträge des Benutzers auf eine externe Website umleitet.

Beginnen Sie mit der Überprüfung von index.php, normalerweise hacken sie es. Scrollen Sie den Code bis zum Ende, und überprüfen Sie ihn auch nach rechts und zwischen den kommentierten Zeilen in der Lizenzüberschrift. Hacker werden verwendet, um Code auf diese Weise zu verbergen.

Sie haben die "ewige Ladezeit", da versucht wird, Websites zu kontaktieren, die Ihr ISP blockiert hat.

Es sollte ziemlich einfach sein, die Malware zu finden und nach "base64" -, "eval" - und "mcrypt" -Strings zu suchen.

Ich habe auf einem Magento mit zwei Websites ein ähnliches Verhalten festgestellt. Die Seite wurde für ein paar Seiten gut geladen und dann für immer geladen.

Die Konfiguration der Basis-URLs war falsch. Die Secure Base-URL-Einstellung wurde auf die falsche Website gesetzt, während die Unsecure Base-URL korrekt eingestellt wurde.

Um dies zu beheben, müssen die Werte in der Tabelle core_config_data für die richtige Website geändert werden, dh die richtige URL wird mit "http: //" und einem abschließenden Schrägstrich im entsprechenden Wertefeld festgelegt den Pfad "web / unsecure / base_url" und "web / secure / base_url" für die richtige scope_id, die die Website-ID darstellt.

Beachten Sie, dass die sichere URL nur http lautet, weil es sich um eine Demo-Website handelt.