Beiträge von codestyling

    In der Zwischenzeit gibt es jetzt eine Beta 2 zu Download, die auch 64bit Server korrekt behandeln sollte (deutsch statt englisch).
    PHP 4 Verträglichkeit wurde von schnurpsel bereits getestet und arbeite auch wieder.
    Link: http://www.code-styling.de/deutsch/wordpr…auch-minimieren

    Ebenfalls sehr lesenswert ist die vorläufige Analyse, die ich anhand der Rückmeldungen erstellt hab. Nicht nur WordPress selbst verschwendet Speicher, ein Blick in die PHP Bugliste spricht Bände!
    Link: http://www.code-styling.de/deutsch/wordpr…-erste-analysen


    Wie kann ich das Problem lösen, um die Regelungen von Wordpress zu umgehen. Hab Google und hier auch die SuFu benutzt aber nichts gefunden, dass funktioniert :(

    Du must schon sagen, daß das die letzte Regel ist und der Rest nicht mehr ausgeführt werden soll:

    Zitat

    Ich habe vor einiger Zeit Thomas Urban von http://www.toxa.de kontaktiert, weil er einen Performance Patch für das Lesen der Sprachdatei in den WP Trac eingebracht hat.
    WP Core Member haben dafür kein Interesse gehabt, aber ich hab mir das angesehen. Nach mehreren Tests und mit meinen Hinweisen haben wir eine neue Version der Datei geschrieben, die Sprachdateien einliest. Diese bringt mein Windows System von 4 MB Verbrauch für die de_DE.mo auf 2 MB runter und ist deutlich flotter.
    Diese ist eine Modifikation in Beta Status jedoch schon genügend oft getestet. Wer diese ebenfalls (ohne Gewähr) testen möchte, kann sich bei mir melden. Ich betone nochmal den Betastand, damit keine Mißverständnisse auftauchen.

    (auch im Blog Artikel kommentiert, ein öffentlicher Betatest sozusagen, wer will)

    Kannst du mal xdebug deaktivieren und alle debuggin Sachen ?
    Ich glaube, der "merkt" sich zu viel Stacktrace, da die neuen mopo Klassen, die Nikolays geschrieben hat, 3300 Instanzen einer Klasse anlegt und die füllt (sehr komische Programmierung, ist in WP < 2.8 ganz anders).

    Das ist ja 8MB Unterschied. In meinem Windows System unter PHP 5.3 braucht die Sprachdatei die bekannten ~4MB. Dann müssten deine Plugins also die restlichen 4MB aufbringen ?

    Und Hinweis für PHP 5.3: hab ich getestet. WP 2.8.x läuft drauf, alle WP Versionen darunter jedoch in keinem Fall! Da kommst du aus Warnings und Errors gar nicht mehr raus.

    Das Problem liegt auch teilweise beim Verständnis des Providers. Wenn man 64Bit läuft und die Speicherverwaltung des System nun mit doppelt so großen Adressen, Zahlen und Strukturen hantiert, dann sollte man auch so schlau sein und das PHP Limit entsprechend anzupassen, wenn PHP ebenfalls 64Bit ist.
    Aber das ist bei einigen Providern noch im Lernprozess begriffen.

    Ein Text (String) verdoppelt sich natürlich nicht, der Inhalt ist auch bei 64bit genau gleich lang. Aber die Verwaltung, wo genau der im Speicher liegt (Pointer) war 4 Byte und ist nun 8 Byte. Auch ist unter 64Bit die Speicherverwaltung sehr viel großzügiger mit Anforderungen von Speicherblöcken (Granularität) die von 4kB Seiten schon mal auf 8kB oder 64kB Seiten gestellt sein kann. Stell dir vor, du willst was mit der Größe von 30 Byte in den Speicher legen, dann landet das bei 32bit in einem 4kB Block unter 64Bit aber u.U. in einem 64kB Block. Auch wenn dann nix mehr in dem Speicher soll, hast du den gerade verbraucht. Dieser Overhead ist dann das eigentliche Problem, aber eben auch OS abhängig.
    Somit wird das nie genau x2 sein aber deutlich in die Richtung gehen.

    Genug techy Zeugs jetzt ... :mrgreen:

    Vorsicht, jetzt wird es techisch.

    Da sich laut den oben genannten Aussagen der Speicherverbrauch quasi verdoppelt hat, mal die ketzerische Frage, ob der alte Server 32Bit und der neue Server 64bit ist ?

    Aus meiner täglichen Erfahrung im Bereich C++ im Enterprise Entwicklungbereich kann ich sagen, das der Speicherverbrauch für ein und dasselbe Programm nur einmal 32bit und einmal 64bit compiled nahezu mit Faktor 2 zu Laufzeit eingeht, wenn man nicht nur Strings "hortet".
    PHP intern ist in C geschrieben und unterliegt somit ebenfalls einem Größenzuwachs beim Schritt von 32 zu 64 bit für Datentypen wie Zahlen, Strukturen, Arrays oder Pointer. Und davon gibts haufenweise intern bei der Ausführung eines (oder mehrerer) PHP Scripte.

    Dies würde sehr passend die Verdopplung erklären. Kannst du dies bestätigen, das du von 32 auf 64 bit Platform umziehst ?

    Zu dem Problem von Tine68 hatte ich bereits hier Setllung genommen, das muß angepasst werden!
    Thema: http://forum.wordpress-deutschland.org/sprachdatei/55…html#post262289

    Das zweite Problem ein Message Context Problem seitens des Codes, wenn man das so scannen lässt. Das können wir zwar beheben, aber ein re-scan aller PHP Dateien von WP produziert das wieder.

    Ich werde Robert nochmal informieren, sollte kurzfristig lösbar sein.

    Ich verstehe es auch nicht, so viel hat mein Blog noch nie verbraucht! Ohne deutsche Sprachdatei läuft es derzeit (laut memory overview) mit 17,25 MB Usage.

    Sobald ich die de_DE in die config.php einfüge, geht es immer bis an Speicherlimit - mit besagter Fehlermeldung. Komischerweise stieß ich schon bei 44 MB um ein paar KB an die Grenzen, und jetzt sogar bei 50 MB???

    Mit Wp2.8.1 lief es übrigens noch einwandfrei... *grübel*


    Wie genau hast du die deutsche Sprachdatei da hinbekommen ?

    Erst kürzlich hatten wir hier das Problem, das jemand Bilder per FTP (PNG's) hochgeladen hatte, die das FTP Programm fälschlicherweise als Text! erkannt hat und Korrekturen an Zeilenumbrüchen gemacht hat.
    Wenn sowas mit der de_DE.mo Datei beim Upload passiert (Datei danach beschädigt!), dann lädt die endlos den Speicher zu bis der Provider Stop sagt.
    Kannst du die Sprachdatei von WP nochmal per FTP im Transfer Modus Binär hochladen ?
    (Es könnte aber auch die Sprachdateien von Plugins erwischt haben).

    Weitere mögliche Gründe sind Fehleinstellungen beim Provider. Bespielsweise ist eine PHP Einstellung zend.ze1_compatibility_mode = On für ein benutztes PHP >= 5.0 tödlich und crashed je nach Provider umgehend das Dashboard.

    Auch ist eine andere Einstellung als mbstring.func_overload = 0 sehr bedenklich und hat u.U. den gleichen Effekt auf die Sprachdateien für WP Versionen 2.8.0 / 2.8.1 wie oben beschrieben.

    Ausgehend von WP 2.7.x Versionen ist dies:

    nicht korrekt für dies hier:

    PHP
    $trans = _c('number_format_decimals|$decimals argument for http://php.net/number_format, default is 0');
            $this->number_format['decimals'] = ('number_format_decimals' == $trans) ? 0 : $trans;
    
    
            $trans = _c('number_format_decimal_point|$dec_point argument for http://php.net/number_format, default is .');
            $this->number_format['decimal_point'] = ('number_format_decimal_point' == $trans) ? '.' : $trans;
    
    
            $trans = _c('number_format_thousands_sep|$thousands_sep argument for http://php.net/number_format, default is ,');
            $this->number_format['thousands_sep'] = ('number_format_thousands_sep' == $trans) ? ',' : $trans;

    In Version ab 2.8.0 sieht das so aus:

    Die korrekte Übersetzung wäre dann:

    wobei man das auch einfach leer lassen kann, was zum Standard führt.


    Allerdings ist der Dezimal Separator im Deutschen eigentlich ',' statt '.' und der Tausender-Separator '.' statt ',' wenn man sich an die Standards halten würde. Nur führt das bei Berechnungen u.U. zu Problemen denn folgender deutsch formatierter Wert ist für PHP bei Umwandlung in eine Zahl was anderes:

    Code
    100.000,00

    wird dann in PHP als Fließkomma Zahl:

    Code
    100.0

    denn PHP läuft in den meisten Fällen auf US locale.