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

BitExpert Blog:
Processing CSV files in a memory efficient way
April 23, 2015 @ 10:50:59

In their latest post Florian Horn shares some of his experience in using the PHPExcel tool to parse CSV files and the performance issues he ran into. Fortunately, he found a solution...in the form of another library.

A little while ago I had to dive deeper into the performance optimized usage of PHPExcel. Our users are uploading files like Excel or CSV with a lot data to process. Initially we used the PHPEXcel instance without any tuning of the default configuration which lead to heavy memory issues on relativly small files. So I had to avoid reading all file content at ones to the buffer (like file_get_contents does).

In my research mainly optimizing the usage of PHPExcel I came across a tiny library I am grown really fond of. It is called Goodby/CSV. Both tools have a very well grounded documentation to read in and understand the basics and the usage.

He describes some of the main differences between the two tools and includes some basic benchmark results comparing memory consumption and overall speed.

0 comments voice your opinion now!
phpexcel csv file goodbycsv process performance memory benchmark

Link: https://blog.bitexpert.de/blog/processing-csv-files-in-a-memory-efficient-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/

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

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


Joshua Thijssen's Blog:
Bloom Filters
April 09, 2012 @ 11:13:32

In this new post to his blog Joshua Thijssen describes something that can help when processing large amounts of data (like, in his example, the text of a book) to search through the information and find if a certain piece of data is in the set - a bloom filter.

Most of my co-workers never really heard of bloom filters, and I'm continuously need to explain what they are, what their purpose is and why it's a better solution than other ones. So let's do an introduction on bloom filters. [...] Bloom filters have the property of being exceptionally fast AND exceptionally small compared to other structures but it comes with a price: it MIGHT be possible that our bloom filter thinks that an element is inside our set, when it really isn't. Luckily, the reverse is not possible: when a bloom filter says something is NOT in the set, you are 100% sure that it isn't part of the set.

He explains how the filter works, noting how it's better for memory consumption and how it's possible for it to give a "maybe" response instead of ab absolute "yes" or "no". He also points out a PHP extension, bloomy that takes the hard work out of it for you.

0 comments voice your opinion now!
bloom filter search memory consumption speed



Community Events

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


interview opinion laravel application api extension voicesoftheelephpant series example release version conference podcast library symfony2 community introduction framework performance php7

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