This is an archived copy of the forum for reference purposes

Memory Used in Single Page App

posted by blogwalker 8 years ago

After working with flourishlib for a few weeks, I started doing some benchmarking to see how things were performing. When doing that, I was surprised to find that my application was using 7MB+ of memory. While not approaching the megalithic levels of CakePHP, I was surprised. I am used to apps taking less than 2MB of memory. I suspected the ORM, and I was correct. So I created a simple single page application that uses autoload to load the libraries, creates a database connection, attaches it to an orm. Creates an Active Record on over one table in the database. Uses a couple of ORM features, in this case DateCreatedColumn. Get all the rows in the table/record with a RecrodSet. The table has 4 rows in it. Loops over the recrod set and displays an ul.

The result of this is a whopping 5.8MB of memory use. Is this to be expected? I can do the same thing with idiorm and paris for 1MB. I know paris does not have all the features of the flourishlib orm, but I can add a lot of behaviors to an AR by adding methods.

Is there a plan to reduce the memory usage? Best practice? (unsetting the record set has no impact, using memory_get_usage() at the end of the script.)

Hmm, I can't argue with you on this one. Numerous fActiveRecord extension classes here and I get about 9.63 MB memory usage from (memory_get_usage() / 1024 / 1024) after generation of my relatively simple homepage. I'm not complaining (yet) since the server I'm on has 1048864k memory and generally speaking, I'm the only user on besides a few testers.

Mem:   1048864k total,   616544k used,   432320k free,     3696k buffers
Swap:   530140k total,   297752k used,   232388k free,    33240k cached

Have a copy of JIRA running too, and a PHP-written daemon doing Twitter requests (takes up about 5 MB, and yes it uses fRecordSet therefore fActiveRecord).

This server I'm using is for development only. The server we will end up on for production will probably be far better.

The documentation has some really good information about caching and performance in general. Wikipedia and Twitter both use memcache, I'd suggest looking into it. Servers I've used in the past have used APC or Memcache (they were all running Drupal installs). http://flourishlib.com/docs/PerformanceTips I pretty much can't argue against any of these things mentioned here.

Another neat trick which I've looked into implementing in my own new Flourish-based site. The Drupal module named Boost (which I use on anfplaylists.com) does the following:

Page requested: Does the already-generated HTML exist in /caches?
  YES - Can the user accept gzip/DEFLATE? Serve the gzip'd version
    NO - The user cannot accept gzip, serve the non-gzip'd version
  NO - Run the PHP code to generate the HTML, serve it to the user, save the HTML version and the gzip'd HTML version

Cron job: Flush all HTML caches if their expiration time is up

This would be relatively easy to implement especially with the help of the Flourish library.

Finally, if you REALLY want to reduce memory usage, start writing PHP extensions. Just note that call_user_func_array() I don't think works well from a PHP extension standpoint. And just look at how foreach works in C:

for (
  zend_hash_internal_pointer_reset_ex(arr_hash, &pointer); 
  zend_hash_get_current_data_ex(arr_hash, (void**) &data, &pointer) == SUCCESS;
  zend_hash_move_forward_ex(arr_hash, &pointer)
) { }

GAH! But hey, more speed! Extension Writing: http://devzone.zend.com/article/1022 I am actually looking into this to convert my translation class to C for more speed since string manipulation is often one of the largest bottlenecks in PHP applications.

posted by audvare 8 years ago

I have not done any memory optimization for Flourish and I don't have any specific plans to, but that is not to say I wouldn't be open to it.

Just for reference, PHP uses quite a bit of memory just to load the Flourish classes. On my 32-bit VM loading every class is Flourish uses 14.25MB. The source code itself it over 1MB, but about 1/3 of those lines are comments.

If you have some examples of Flourish using a lot of memory (after loading classes into memory) please feel free to open a ticket. I'd be happy to try and fix gratuitous memory usage.

posted by wbond 8 years ago