sebkrack

Hallo und guten Abend zusammen,

folgender Sachverhalt:

Ich betreibe einen SOAP-Webservice mit Apache+PHP, die Server Anwendung ist hierbei from scratch selbst entwickelt, ohne irgendwelche SOAP-Klassen o.ä.

Folglich werden an den entsprechenden Server HTTP Nachrichten mit XML im Body versendet.

Nun zu meinem Problem:
Solange die Requests klein waren gab es nie Probleme. Die Request Größe betrug nie mehr als 1MB.

Da unser Kunde nun auch größere SOAP Nachrichten über diesen Webservice abwickeln möchte (ca. 15 MB) treten nun gehäuft Probleme auf: überschreiten des eingestellten memory_limits von 130 MB bei einer Request Größe von 15 MB!

Ein Teil des Problems ist sicher in meinem Code zu suchen, ich werde hier noch optimieren können mithilfe der Funktion memory_get_usage(). Das stellt kein Problem dar.

ABER: wenn ich in der ALLERERSTEN ZEILE meines PHP-Scriptes mir memory_get_usage() ausgeben lasse, habe ich bei besagter 15MB XML Nachricht bereits eine Speichernutzung von 46,1MB. Nach Auslesen von "php://input" kommen nochmal 15MB drauf (klar) so dass ich also wegen einem 15MB File mit einer Speicherauslastung von 61,1MB erst mit der Verarbeitung beginnen kann.

Da es ein hochfrequentierter Webservice ist, können wir uns einen so hohen Speicherverbrauch nicht leisten. Weiss jemand von euch woran es liegt, dass der Apache-PHP-Prozess offensichtlich bereits mit der 3-Fachen Requestgröße + x im Speicher gestartet wird? Eine Lösung wäre es für mich auch, wenn ich nach Auslesen von "php://input" die 45MB direkt wieder freigeben kann.

Ich hoffe Ihr könnt mir helfen und bedanke mich im Vorraus.

Grüße

Mister Ad

robo47

Je nach php-einstellungen steht der inhalt in
$HTTP_RAW_POST_DATA
-> http://www.php.net/manual/en/ini.cor...-raw-post-data

also könnte es deinen speicherverbrauch runterbringen wenn du raw-post-data deaktivierst (falls aktiviert)

ansonsten mal noch schauen ob vielleicht auch $_POST irgendwas drin hat.

ansonsten mal schauen ob dir xdebug weiterhilft:

http://derickrethans.nl/xdebug-and-t...ory-usage.html

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

sebkrack

Danke für die Antwort. Das xdebug sieht verdammt cool aus, das werde ich Montag direkt mal ausprobieren zum optimieren.

$HTTP_RAW_POST_DATA ist gefüllt und bringt mir tatsächlich 15MB Ersparnis, da ich dann das Auslesen von php://input einsparen kann. $_POST ist allerdings leer.

Damit ist nur leider die memory usage zu beginn des Scripts immer noch 3x so hoch wie die Größe des XML-Files...

Hält vielleicht der Apache und das PHP Modul jeweils nochmal die Daten irgendwo vor? Oder gibt es vielleicht eine Setting, so dass ein temp-file benutzt wird anstatt der Speicher? Das wäre zwar auch nicht gerade performant aber besser als 2 unnötige Kopien im Speicher irgedwo zu haben? Ehrlichgesagt kann ich mir irgendwie kaum vorstellen dass der Apache mit PHP-Modul so blöd gecodet ist, dass so viel unnötiger Speicher verbraucht wird?

Danke aber schonmal für den Hinweis auf xdebug

robo47

Apache hat imho erstmal nix mit dem speicherverbrauch von php zu tun, also wenn dann müsste das von php her rühren, lediglich eine Sache fällt mir ein die das ganze "langsamer" machen könnte und das wäre wenn der apache ein ausgefallenes log-format verwendet wo POST-daten mitgeloggt werden, aber das sollte sich nicht auf den speicherverbrauch von php irgendeinen einfluss haben.

Hast du mal ein paar Details zu apache/php-version, phpinfo() und so ? sprich auch welche module mitlaufen und soweiter, eventuelle prepend-scripts, etc.
Laufen vielleicht schon irgendwelche debugger wie xdebug oder ähnliches mit ? inwieweit kommt ein bytecode-cache (apc, xcache, ... ) zum einsatz ...

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

sebkrack

Hi,

prepend Scripte verwende ich keine, ein bytecode-cache kommt nicht zum einsatz. debugger laufen aktuell auch keine mit.

ich poste mal die ausgabe von phpinfo()

sebkrack

Anbei phpinfo html-formatiert als zip.

danke für die hilfe

Angehängte Dateien

phpinfo_sebkrack.zip (10,4 KB, 8x aufgerufen)

robo47

Also auf Anhieb fällt mir da nichts auf, aber dein PHP ist mehr als 4 Jahre alt (August 2006) ... da könnten sich schon ein paar Bugs und kram angesammelt haben, das sollte vielleicht mal geupdatet werden, vielleicht wirst du damit dein problem los.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

lstegelitz

Ein ganz simpler Trick bei großen XML Dateien: verkürze die Namen von Attributen und Tags auf ein absolutes Minimum (falls möglich). Sprechende Bezeichner sind zwar toll, blähen aber die XML Datei extrem auf.

Kann aber gut sein, das dieser Weg für dich nicht praktikabel ist, da dein Webservice ja scheinbar bereits im Einsatz ist...

__________________
Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

sebkrack

Hallo Isteglitz,

wie du schon vermutet hast ist das nicht praktikabel, da die WSDLs vorgegeben sind. Zudem besteht das XML-File zu 99,99% aus Base64

sebkrack

ja leider, das liegt nicht in meiner Hand. Ich hoffe unsre Sysadmins bald von einem PHP-Update überzeugen zu können