News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Julien Pauli:
Zoom on PHP objects and classes
March 26, 2015 @ 12:50:49

Julien Pauli has a recent post to his site that "zooms in" on objects and classes with a look behind the scenes at how they're handled in the PHP source (at the C level) with plenty of code examples and explanations as to how they work.

Everybody uses objects nowadays. Something that was not that easy to bet on when PHP5 got released 10 years ago (2005). I still remember this day, I wasn't involved in internals code yet, so I didn't know much things about how all this big machine could work. But I had to note at this time, when using this new release of the language, that jumps had been made compared to old PHP4. The major point advanced for PHP5 adoption was : "it has a new very powerful object model". That wasn't lies. [...] Here, I will show you as usual how all this stuff works internally. The goal is always the same : you understand and master what happens in the low level, to make a better usage of the language everyday.

The article does a great (if lengthy) job of covering everything that happens with PHP's objects and class system, including stats about memory consumption. He includes both the PHP code and the C code to illustrate what's happening with classes, interfaces, traits and object methods/attributes (including object references). He also talks about what "$this" is and how class destructors are handled.

0 comments voice your opinion now!
object class behindthescenes detail c code memory usage

Link: http://jpauli.github.io/2015/03/24/zoom-on-php-objects.html

Nikita Popov:
PHP's new hashtable implementation
December 26, 2014 @ 10:20:10

In his latest post Nikita Popov gives a detailed look at PHP's new hashtable implementation and what kinds of improvements it offers over the previous methods. The "hashtable" handling is how the language references array values created during the execution of a script.

About three years ago I wrote an article analyzing the memory usage of arrays in PHP 5. As part of the work on the upcoming PHP 7, large parts of the Zend Engine have been rewritten with a focus on smaller data structures requiring fewer allocations. In this article I will provide an overview of the new hashtable implementation and show why it is more efficient than the previous implementation.

He starts with an introduction to the concept of hashtables, describing them as "ordered dictionaries" of key/value pairs that (internally) reference values in an array. He looks at the old method PHP used to make these links and how the new version, with the help of zval handling, is different. He talks about how it handles the order of elements, does lookups and the introduction of "packed" and "empty" hashtables. He ends the post with a look at this new implementation's memory utilization and what kind of performance gains we can expect with its introduction in PHP7.

0 comments voice your opinion now!
hashtable array implementation php7 performance memory lookup

Link: http://nikic.github.io/2014/12/22/PHPs-new-hashtable-implementation.html

LeaseWebLabs.com:
How to use the "yield" keyword in PHP 5.5 and up
May 23, 2014 @ 12:09:47

In a recent post to the LeaseWebLabs blog Maurits van der Schee looks at the use of the "yield" keyword in PHP 5.5 to work with generators. A generator is very similar to a function that returns an array, in that a generator has parameters, can be called, and generates a sequence of values but it yields values one at a time.

The concept of generators is not new. The "yield" keyword exists in other programming languages as well. As far as I know C#, Ruby, Python, and JavaScript have this keyword. The first usage that comes to mind for me is when I want to read a big text file line-by-line (for instance a log file). Instead of reading the whole text file into RAM you can use an iterator and still have a simple program flow containing a "foreach" loop that iterates over all the lines.

He includes a few code examples showing a class that can read in data from a file in chunks and output the lines as they're extracted (versus using something like file). He also talks about a small performance comparison in working with the file pointer, fread over fgets. He even makes a simple benchmark script to compare the overall time and memory consumption of the fetching of different byte "chunks" from the file.

0 comments voice your opinion now!
yield generator file read fread fgets memory time benchmark

Link: http://www.leaseweblabs.com/2014/05/how-to-use-yield-keyword-php

Edd Mann:
Storing PHP Sessions/File Caches in Memory using TMPFS
April 17, 2014 @ 11:19:59

Edd Mann (of the Three Devs & A Maybe podcast) has shared a method of session storage he worked up to help increase performance in his application. He shows how to store sessions in memory with the help of TMPFS.

Yesterday I was looking through some application logs and noticed a significant bottleneck with I/O reads in the implemented file cache. [...] This was when I found 'tmpfs', saving me from all sorts of issues relating to adding yet another application to the production stack. 'tmpfs' appears as a mounted partition on your system, however, under the hood it allocates and uses a section of physical memory (non-persistent through reboots). [...] his results in the desired speed boosts, without tampering with the application logic itself. Even better, if the mount is unsuccessful for some reason, it will safety fall-back to using the persistent hard-disk solution.

Since PHP sessions make it easy to change the "save_path" location for the data in an ini value, setup is easy. He includes the needed configuration change and the commands you'll need to mount the tmpfs partition on your local file system.

0 comments voice your opinion now!
tmpfs session file cache memory tutorial comamnds ini

Link: http://eddmann.com/posts/storing-php-sessions-file-caches-in-memory-using-tmpfs

Kevin Schroeder:
How much memory does Magento use?
December 10, 2013 @ 10:42:23

Kevin Schroeder was asked recently (as a part of a training class) about the amount of memory Magento actually uses during its execution. Magento is a widely-used e-commerce platform built in PHP.

Now, I know what you're supposed to set it at, but I've never measured actual usage. So I gave some bullcrap answer about how it really depends on a bunch of things and that I really shouldn't give a precise answer. But the individual persisted and I was forced to put my tail between my legs and admit that I didn't know. So I promised that I would take a look and here are my results.

He briefly mentions how he tested the memory usage of the code overall by adding an event to several spots in the application and using memory_get_usage. Using the sample Magento data he worked his way through the site and tracked the events/memory usage on the various page of the site including:

  • Main category page
  • Category page with images
  • Simple product page
  • Add to Cart

Each of these has a graph showing the memory usage at each stage. Additionally, he's graphed them all together to compare the overall memory consumption.He finishes off the post with a few summary items and conclusions from his results.

0 comments voice your opinion now!
magento memory usage consumption graph

Link: http://www.eschrade.com/page/how-much-memory-does-magento-use/

MaltBlue.com:
ZendDbSqlSelect - The Basics (Columns, Limit & Order)
July 02, 2013 @ 09:53:32

Matthew Setter has posted the third part of his series looking at the Zend Framework 2's DbSqlSelect component and its use. In this latest (and last) tutorial, he talks more specifically about columns, limiting and ordering.

Welcome to the third and last part in this series, introducing you to working with the ZendDbSqlSelect classes in Zend Framework 2. In part one we looked at building SQL Where clauses using the where related functions, predicates and closures, as well as compound queries. In part 2, we looked at all forms of SQL joins as well as a slightly more esoteric feature of SQL - UNIONS. Here, in part 3, in the words of Coldplay, we're going back to the start, and looking at the fundamentals.

He looks at three specific elements - the class constructor, the "limit" and "order" functions and the "Expression" class. He includes sample code showing how to create the class - one normally and one bound to a specific table. The next example shows how to define the columns to be selected using the "select" method. Finally, he shows the use of the "Expression" objects to perform SQL operations in the query (like "COUNT").

0 comments voice your opinion now!
zendframework2 db sql select series part3 column limit order

Link: http://www.maltblue.com/tutorial/zend-db-sql-the-basics

Software Gunslinger:
PHP is meant to die, continued
April 26, 2013 @ 09:15:56

In his previous post ("PHP was meant to die") the point was made that PHP isn't really designed as a language to handle long running processes very well. It's made to handle a few operations and then die at the end of the request. In this follow up post he talks more about using PHP for long running processes and a library that could help.

Yes, I already acknowledged that PHP has a garbage collection implementation starting 5.3.0 and up (opt-in or opt-out, that's not the problem). I also acknowledge that garbage collection works, and is able to take care of most circular references just fine. [...] Anyway, as previously stated too, garbage collection is a great thing, but not enough for PHP. It's a borrowed feature that does not play well with old fundamental decisions inherited from the original design. Garbage collection is not a magical solution for every problem, like many tried to argue about. Let's illustrate with another example.

His example uses the React PHP library (a non-blocking I/O platform) to handle a lot of incoming data to a port and report back some memory usage and limit settings. He explains a bit about what's happening and shares the results of the test, including the end result - a fatal error when the memory limit was hit. He still comes to the same conclusion, ultimately...PHP is just not the language to use for long-running processes that do any large amount of work.

0 comments voice your opinion now!
react die longrunning process testing socket server memory limit

Link: http://software-gunslinger.tumblr.com/post/48215406921/php-is-meant-to-die-continued

Software Gunslinger:
PHP is meant to die
April 05, 2013 @ 10:47:40

In this new post, titled "PHP is meant to die", the author looks at one weakness he sees in the PHP language - how PHP handles long running scripts and functionality.

In my opinion, a lot of the hatred that PHP receives misses the utter basic point: PHP is meant to die. It doesn't mean that a perfectly capable (to some extent) programming language will disappear into nothingness, it just means that your PHP code can't run forever. Now, 13 years after the first official release in 2000, that concept still looks valid to me.

He talks about some of the "dying" that PHP is good at (like making general website-related requests) but notes that if you try to have it do much more, PHP acts up. He points to the complexity of web-based applications and notes that, while PHP is good for some of it, it's not a fit for all functionality. He also covers the bringing of processes to the foreground that are best left in the background and how - despite the best of intentions - making a PHP daemon to solve the problem isn't a viable option.

Do you see the pattern? I've inherited projects where PHP was used for daemons or other stuff that's not just regular websites (yes, I'm a hired keyboard), and all of them shared that same problem. No matter how good or clever your idea looked on paper, if you want to keep the processes running forever they will crash, and will do it really fast under load, because of known or unknown reasons. That's nothing you can really control, it's because PHP is meant to die. The basic implementation, the core feature of the language, is to be suicidal, no matter what.
0 comments voice your opinion now!
die memory issues longrunning process daemon problem

Link: http://software-gunslinger.tumblr.com/post/47131406821/php-is-meant-to-die

Derick Rethans' Blog:
MongoDB Cursors with PHP
May 22, 2012 @ 12:23:16

Derick Rethans has a new post to his site today about MongoDB cursors in PHP when using the PHP driver and how it handles pulling data from the server.

Recently I was asked to improve the MongoCursor::batchSize documentation. This began an indepth investigation in how the PHP driver for MongoDB handles pulling data that's been queried from the MongoDB server. Here are my findings.

He talks about the cursor that's created when a "find" call is made and how you can add on additional options (via other methods on the cursor) to its execution. He also covers how you can set your own batch size, using limit to only fetch a certain number of results and combining the two to make for more memory efficient, yet complete, returned data sets.

0 comments voice your opinion now!
mongodb cursor batchsize limit tutorial


Larry Garfield's Blog:
readfile() not considered harmful
May 04, 2012 @ 09:51:38

In this new post to his blog Larry Garfield tries to dispel a common misconception in the PHP development world - that the readfile function should be considered harmful and can cause memory issues in your code.

If you're like me, you've probably read a dozen or two articles about PHP performance in your career. Many of them are quite good, but some are simply flat out wrong, or misinformed. One of the old truisms that has been repeated for as long as I can recall is "don't use readfile() if you have big files, because it reads the whole file into memory and your server will explode." [...] There's just one problem with that age-old truism: It's not true.

He created some benchmarks to illustrate the differences between several of the common methods for working with files via the fread, fpassthru, stream_copy_to_stream and of course readfile. He reports the results based on the runtime and the peak memory usage and noted, ironically, that while the times varied slightly, the memory consumption was exactly the same for all of the approaches. Since there's no real reason not to use "readfile", he looks at three reasons why there might be this stigma attached to it (including the issues that could come up with output buffering enabled).

0 comments voice your opinion now!
readfile file handling harmful dispel myth benchmark memory



Community Events

Don't see your event here?
Let us know!


example voicesoftheelephpant library opinion security introduction framework api extension video series laravel5 php7 release community language podcast interview laravel version

All content copyright, 2015 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework