www.webdeveloper.com
Results 1 to 14 of 14

Thread: PHP and Memory

  1. #1
    Join Date
    Oct 2006
    Posts
    55

    PHP and Memory

    Hello
    Im building a browser based game (text and images)

    I have a debugger/benchmark script that I run at every opage load which gives me various information. One thing it logs is script exectution times (including how long it took for all of the php to load and execute) as well as memory usage.

    Im developing on a shared host so I guess things differ a bit when I go dedicated, but I have noticed a fully loaded profile page takes around 0.05 - 1 second to execute and consumes 1.1 - 1.3 MB of memory (using phps memory_get_usage() function)

    Im wondering if that much memory is a bad thing or not... Imagine 100 users load a page, then imagine 10,000 users. Granted if the system had 4GB+ of memory it might be able to handle it but it seems high.

    Its not a script more than its all scripts that run before the server sends the html to the browser.

    But these scripts are working to build the HTML page loading profile info from a db query or sessions, performing calculations, accessing classes, functions etc..

    And at the end stripping whitespace from the HTML (using ob_start with a strip function)

    Weird thing is, I have very optimized queries, and I never use *
    I free my results all the time and I never get big results anyway (we are talking 1000 bytes max in most cases, sometimes more)

    I have a debugger class that handles all this info, Ill post an example of what it spits out:

    Example 1 Initial page load where I run all queries and store info in session data:
    http://img651.imageshack.us/img651/3912/68408024.jpg

    Example 2 second page load (same one) where we skip most queries due to session info being present:
    http://img27.imageshack.us/img27/779/31897689.jpg

    I dont expect you guys to understand it all, but bascialyl I load all the modules I need first then run my scripts for that particular page.
    MU is memory usage, and I also put memory usage and peak usage on top and bottom of the output. For memory usage the first value is the memory size and the second value is the real usage (real allocation)

    It seems most of the data comes from loading the modules, but the modules themselves are just full of functions or classes, and they dont go over 100KB in size total.

    So Im not sure why the memory usage is so high.

    Any ideas?

    edit: as you can see, my queries and subsequent result usage etc only really use up to 100KB MAX of memory. So it couldnt be my queries. Even the first image shows that a lot of queries and calculations does little to add to the memory usage.

  2. #2
    Join Date
    Dec 2009
    Location
    Denmark
    Posts
    240
    Don't think I would think to much about it.
    Just made a test script

    PHP Code:
        $testArr = array("index1""index2""index3");
        echo 
    json_encode($testArr); 
    Now, this really small test uses 0.3mb.

    Imagine 100 users load a page, then imagine 10,000 users
    Well, it would also require your 10.000 users to load the page in the exact same ms. But yes, running a site with 10.000 users will require more than an old Pentium 4 with 256mb ram that you found hidden away in your garage

    You don't run google on your laptop...

  3. #3
    Join Date
    Nov 2008
    Posts
    2,477
    In my experience mysql is far more of a resource hog than PHP so I would be more worried about that. However as dk_zero-cool says you will need to scale your hardware with your users. To give you a bit of an idea though, one of the servers I work with has 4GB ram and runs a site that gets around 100 page requests per second and it never gets above 20% RAM useage, and that's for PHP, MySQL, Apache and the OS and associated processes. Obviously that's going to vary (potentially a lot) depending on your app, and being on a shared host it's more of an issue, but if you find you're running out of RAM and you've done all the optimizing you can, it's time to buy more RAM!

  4. #4
    Join Date
    Oct 2006
    Posts
    55
    Thanks for the responses. It just seemed scary to see such memory usage for an application which isnt all that heavy.

    The modules I load just contain classes or functions which dont even execute until later on in my page/script.

    I read somewhere that I should be unsetting all my variables once im done. Is this required for every variable I use inside and outside functions and classes?

    Is it worth the extra processing time?

  5. #5
    Join Date
    Nov 2008
    Posts
    2,477
    There's rarely any point in unsetting variables. Generally when it is done at all it is done as a flow control technique rather than out of concern for resources. As soon as your script stops processing (or your function exits) the variables are all destroyed automatically. The only exception would be if you were building massive arrays inside loops for example, and you want to ensure you don't hit PHP's memory limit setting - but this is usally a sign that you are doing something wrong anyway.

  6. #6
    Join Date
    Jul 2009
    Location
    Falls Church, Va.
    Posts
    780
    Quote Originally Posted by Mindzai View Post
    In my experience mysql is far more of a resource hog than PHP so I would be more worried about that.
    I researched this, actually. As to MySQL, the default settings are hoggish, sure. But PHP now supports MySQLi (i as in "improved") which is object oriented extension and works more efficiently than MySQL when called via PHP using the new functions in the proper way. It also supports transactions and prepared statements much as Oracle does, two enterprise level features. If you use persistent connections in MySQLi (which is possible) via pre-pending the hostname with "p", you should disable automatic cleanup (a feature intended to deal with stale client persistent connections) by compiling PHP with MYSQLI_NO_CHANGE_USER_ON_PCONNECT defined. You also should modify the max_connections and max_user_connections values in my.cnf to further optimize.

    Even though an OOP instance of the extension technically is a heavier footprint in memory than the legacy extension, when configured properly, you'll find the new extention is far faster *and* optimized for efficiency.

    MySQL 5.4 - Up To 90% Faster Query Response Times and Scalability Up to 16-way x86 Servers and 64-way CMT Servers

    MySQL 5.4 includes performance and scalability improvements enabling the InnoDB storage engine to scale up to 16-way x86 servers and 64-way CMT servers. MySQL 5.4 also includes new subquery optimizations and JOIN improvements, resulting in 99% better response times for certain queries. These performance and scalability gains are transparent and don't require any additional application or SQL coding.
    To clarify, the legacy extension configured out of the box under older or shared hosting platforms will suffer performance.

    FYI

    -jim

  7. #7
    Join Date
    Dec 2009
    Location
    Denmark
    Posts
    240
    #6 I am a bit confused.

    works more efficiently than MySQL when called via PHP
    Since mysqli is a driver build FOR PHP, what else would you call it in?

    And the MySQL 5.4 quote of yours, what is that for?
    The quote is about a server version, and what you are talking about is the two driver versions in PHP used to provide interfaces with, not only server version 5.4, but older version as well.

  8. #8
    Join Date
    Jul 2009
    Location
    Falls Church, Va.
    Posts
    780

    Wink

    Quote Originally Posted by dk_zero-cool View Post
    #6 I am a bit confused.


    Since mysqli is a driver build FOR PHP, what else would you call it in?

    And the MySQL 5.4 quote of yours, what is that for?
    The quote is about a server version, and what you are talking about is the two driver versions in PHP used to provide interfaces with, not only server version 5.4, but older version as well.
    Use OOP coding style vs. procedural style in PHP to work with mysqli functions.

    OOP:

    PHP Code:
    $mysqli = new mysqli("localhost""my_user""my_password""world");
    if (
    $mysqli->query("CREATE TEMPORARY TABLE myCity LIKE City") === TRUE) {
        
    printf("Table myCity successfully created.\n");
    }

    if (
    $result $mysqli->query("SELECT Name FROM City LIMIT 10")) {
        
    printf("Select returned %d rows.\n"$result->num_rows);
        
    $result->close();

    Procedural:

    PHP Code:
    $link mysqli_connect("localhost""my_user""my_password""world");
    if (
    mysqli_query($link"CREATE TEMPORARY TABLE myCity LIKE City") === TRUE) {
        
    printf("Table myCity successfully created.\n");
    }

    if (
    $result mysqli_query($link"SELECT Name FROM City LIMIT 10")) {
        
    printf("Select returned %d rows.\n"mysqli_num_rows($result));
        
    mysqli_free_result($result);

    As to the benchmark stats I included, it's to highlight the fact the latest extension on a fast server setup properly has outstanding performance as one might expect from an enterprise level solution.

    -jim

  9. #9
    Join Date
    Dec 2009
    Location
    Denmark
    Posts
    240
    As to the benchmark stats I included, it's to highlight the fact the latest extension on a fast server setup properly has outstanding performance as one might expect from an enterprise level solution.
    Yes that much I got, except that your so called benchmark is about a new MySQL server version. It has nothing to do with the usage of the MySQLI Driver.

    And there are also a difference between (Procedural MySQLI vs OOP MySQLI) and (Procedural MySQL vs OOP MySQLI)

    MySQLI is faster whether you use Procedural or OOP.
    So, make up your mind to which of the two you want to compare. Procedural MySQLI or Procedural MySQL. against OOP MySQLI.

  10. #10
    Join Date
    Jul 2009
    Location
    Falls Church, Va.
    Posts
    780
    My overall response was about MySQL in general, and I mentioned the improved driver in one part of my response and the major stable release in another part. I can't help it if you think I meant something else. And some (not all) developers feel using OOP style is more efficient that using procedural style which means less code in general, re-using of objects in memory which in turn means less overhead and thus increased efficiency. No other meaning or context is implied.

    This thread is about performance issues involving large data sets and limits, and one user mentioned MySQL resources hogging when I respectfully disagree and posted some points to support my view to the contrary. I did this to allow the OP to feel more confident that the database aspect of a modern LAMP setup really is not the concern it was in years past in terms of resource hogging and performance on data driven sites.

    I'd love to debate every single word, sentence, paragraph and point with you, but it's not a good use of this forum or my time (at least). I really don't expect to convince you, but hope this clarifies some of my points.

    If not, I tried, we both move on. I can live with it!

    -jim

  11. #11
    Join Date
    Dec 2009
    Location
    Denmark
    Posts
    240
    I'd love to debate every single word, sentence, paragraph and point with you, but it's not a good use of this forum or my time (at least). I really don't expect to convince you, but hope this clarifies some of my points.
    He he, don't need convincing on anything. I just wasn't able to figure out your point. You mixed a lot of things together without any pointers to their context.

  12. #12
    Join Date
    Oct 2006
    Posts
    55
    It would have been quite a heated debate.

    Well I have access to a clients server which is a dedicated beast, which serves solely as a web server. And memory usage was much lower. I saw no more than 800 as opposed to the 1200 on shared hosting. So I assume my code isnt as bad as I thought it was! It must be something the host is doing to add to the memory usage (or just the general lack of performance shared hosting provides)

    Either way Ive revisited all my for/foreach loops and unset variables that are reused every loop run (large ones like arrays).

    Thanks for all the info, I have taken a more PHP approach to the game, where I try to rely less on the Database and more on caching information in sessions and only revising the server when new information is available.
    I was originally worried that this method was consuming too much memory, but it seems the majority of my worries came from the shared host, not my code

    Thanks!

  13. #13
    Join Date
    Jul 2009
    Location
    Falls Church, Va.
    Posts
    780
    Quote Originally Posted by Kovo View Post
    ... it seems the majority of my worries came from the shared host, not my code...
    Yes - I concur. Some hosts run outdated LAMP setups, cap connections or throttle this or that, and folks wonder why things don't work and chalk it up to poor open source development. I hinted on some of the MySQL improvements of recent and others noted a few PHP best practices. So you're right to say a "majority" is host related (especially when shared) so good developers will benefit if they know a little about the back end technologies so they don't get trapped in a project from Hell. A project where the lay client notices performance issues like those mentioned here. Been there, done that.

    Thanks for posting about it, this is an interesting topic and an important one, I think.

    My .02

    -jim
    Last edited by SrWebDeveloper; 01-26-2010 at 01:26 PM. Reason: simple typo fix

  14. #14
    Join Date
    Oct 2006
    Posts
    55
    There are little to no resources out there that talk about the issue I had. I could not find one resource which showed examples of memory usage in different environments/setups.
    So I had no choice but to ask, and see other developers personal experience's.

    Hopefully people in the future will stumble upon this post and get help sans asking


    Thanks again

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles