Groups

Group Admins
  • Avatar Image
    camille
  • Avatar Image
    Ariel Sommeria-Klein

amfPHP Users

Public Group  |  active 4 months, 3 weeks ago ago

This forum is not active anymore, please ask your questions on stackoverflow

Amfphp 3 – Migrating from 1.9 – Memory exhausted issue

Viewing post 1 to 13 (13 total posts)
  • Stephen Schmitz

    said

    Hi,

    We are trying to move our codebase from Amfphp 1.9 to 2.0.1. We saw the migration page which was helpful. We found a couple of issues that were not on that page, such as amfphp 1 was more tolerant of receiving extra arguments in the service functions than amfphp 2. So, basically 2.0 is stricter, which is good.

    However, now we have one issue that I am concerned about. Under version 1, we were bringing large amounts of data across to flex, such as 28,000 rows of data. At some point, we reached a limit with amfphp 1. But now, under amfphp 2, we are exhausting memory at less than 9,000 rows. Does anyone know why this is the case? Is amfphp grabbing more memory on its own, or is it more efficient for certain large data tasks?

    Here’s the error:
    Allowed memory size of 33554432 bytes exhausted (tried to allocate 72 bytes) in

    Thanks
    Steve

  • Ariel Sommeria-Klein

    said

    thank you for pointing out the bit about argument checking. It’s actually a config switch called checkArgumentCount, but it should show up in the migration page.
    regarding your memory: the same basic mechanism for converting your php data to amf is used on both 1.9 and 2.0. It has just been debugged and improved, and this is the first time we hear of memory issues. If you can php serialize your data I can take a look.

  • Stephen Schmitz

    said

    Hi ariels,

    Thanks for the info on the argument count, and also on the memory issue.

    Another thing we noted while migrating is that session handling is different. Now we have to call session_start() before accessing session variables. Again, this is probably an improvement over 1.9.

    In regards to the memory issue, I’ve bumped up the max memory usage in the script. That’s temporarily helped the situation. I’ll get back to you later, either with any findings or the php serialized data.

    Thanks
    Steve

  • Stephen Schmitz

    said

    So, I started playing with the configuration of the const inside Serializer.php. I changed:

    const MAX_STORED_OBJECTS = 128; //1024;

    This has shown enormous improvement in performance for large amounts of data serialization.

    Any thoughts or side effects I should watch out for?

    Thanks again

  • Ariel Sommeria-Klein

    said

    You save a lot of bandwidth in AMF by sending references to previously encoded objects instead of sending the same object. These references must be stored, and this comes at a cost of memory and performance.

    So if you lower MAX_STORED_OBJECTS, serialization will go faster and use less memory, but your bandwidth use might go up.

    If of course there is never twice the same data in what amfPHP returns, or bandwidth is not an issue, then by all means lower MAX_STORED_OBJECTS.

  • alejandrotabares

    said

    Hello

    I found the same problem and my configuration is:

    $amf_config = new Amfphp_Core_Config();

    $amf_config->disabledPlugins[] = ‘AmfphpAuthentication';
    $amf_config->disabledPlugins[] = ‘AmfphpCharsetConverter';
    $amf_config->disabledPlugins[] = ‘AmfphpCustomClassConverter';
    $amf_config->disabledPlugins[] = ‘AmfphpDiscovery';
    $amf_config->disabledPlugins[] = ‘AmfphpDummy';
    //$amf_config->disabledPlugins[] = ‘AmfphpErrorHandler';
    //$amf_config->disabledPlugins[] = ‘AmfphpFlexMessaging'; // DO NOT DEACTIVATE
    $amf_config->disabledPlugins[] = ‘AmfphpGet';
    $amf_config->disabledPlugins[] = ‘AmfphpIncludedRequest';
    $amf_config->disabledPlugins[] = ‘AmfphpJson';
    $amf_config->disabledPlugins[] = ‘AmfphpLogger';

    And now run so fast as 1.9 version.

    Also a plugin for support gzip compression has been created (currently in pull request process), you can find it here:

    https://github.com/lordoffreaks/amfphp-2.0/tree/master/Amfphp/Plugins/AmfphpGzip

    Becasue of it´s not currently a core plugin, for implementation we added it to src/AmfPlugins directory, in this way:

    $amf_config->pluginsFolders[] = AMFPHP_ROOTPATH . ‘src/AmfPlugins/';

    $gateway = Amfphp_Core_HttpRequestGatewayFactory::createGateway($amf_config);

    Hope it helps you

  • Deleu

    said

    Since the topic was unburied, let me ask this:
    MAX_STORED_OBJECTS is used when AmfPHP returns Referenced objects? If I have a project where I WILL NEVER return 2 identical objects (reference), then can I use it as MAX_STORED_OBJECTS = 1 and improve the speed of things?

  • Ariel Sommeria-Klein

    said

    @alejandrotabares
    I like your suggestion and I think it can be useful in some cases. However, I don’t think it should be added to the basic distribution, for 2 reasons:

    – gzip should be handled at the server config level if possible.
    – it introduces a php extension dependency.

    So how about you keep it separate as a plugin, and I list it in the plugins exchange?

  • alejandrotabares

    said

    Hello @ariels

    I´m agree with you, becuase even if the plugin checks for the extension dependency, I think like you, it´s not a good idea have I into de basic distribution.

    I create a repo into github for the plugin

    https://github.com/lordoffreaks/AmfphpGzip

    I´ll be happy if you list it in the plugin exchange :-D

    Thanks in advance

Viewing post 1 to 13 (13 total posts)
Topic tags: amfphp2, memory

Warning!

This content
is outdated.

Discover Silex v2,
online website builder.

Sign up for Silex Labs news by email

SilexLabs community Tweets