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

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


UMumble.com:
Working with memory
February 14, 2012 @ 08:44:02

On the UMumble blog there's a recent post looking at memory consumption in PHP applications - what PHP does for you when managing how it uses your system's memory and what you need to worry about in your code.

There is a widespread view that the ordinary PHP developer does not need to control memory management, but "controlling" and "knowing" are slightly different concepts. I will try to throw light upon some aspects of memory management when working with variables and arrays, and some interesting pitfalls of the internal optimization of PHP. As you can see, the optimization is good, but if you do not know exactly how it is optimized, you might meet the pitfalls, which can make you pretty nervous.

They talk about some of the basics - how variables are stored in hash tables and how this helps memory consumption - as well as using the memory_get_usage method to find your current consumption. This is show for both regular strings and arrays, comparing larger data (and assigning it multiple times) to simpler structures. They also mention how PHP handles memory usage in passing by reference and copying of values.

0 comments voice your opinion now!
memory consumption tutorial usage management internals


IBM developerWorks:
Store datasets directly in shared memory with PHP
January 20, 2012 @ 11:29:24

On the IBM developerWorks site today there's a new tutorial showing you how to store shared data directly to a shared memory space of your PHP application.

Once created, and given proper permissions, other processes in the same machine can manipulate those segments by: read, write, and delete. This means that an application written in C can share information with an application written in other languages, such as Java or PHP. They can all share information, as long as they can access and understand that information. [...] This article's proposal is simple, learn how to create and manipulate shared memory segments with PHP and use them to store datasets that other applications can use.

Your PHP installation will need to have been compiled with "enable-shmop" to work with the code in this tutorial. Their examples show how to use the shmop_open, shmop_write and other related functions to read, write, remove and close segments in the shared memory space. They also include an example of using the SimpleSHM library to make it easier to interact with the shared memory space as a standard storage location.

0 comments voice your opinion now!
shared memory shmop dataset simpleshm storage


Volker Dusch's Blog:
Never trust other peoples benchmarks - A recent example (exceptions)
January 19, 2012 @ 09:20:32

In response to a previous post benchmarking exceptions, Volker Dusch has posted some of his own thoughts and benchmarking results on the same topic.

Some days ago there was a blog post regarding php exception performance in 5.4 and the numbers got reported all over the place. The actually numbers are secondary. The main point is: Don't trust "random" stuff on the Internet when thinking about improving your application performance. You always need to measure things for your self and take care doing so! I've initially trusted the benchmark myself and disgraced the whole post saying: "Well yes, exceptions are slower than if statements but nice that they got faster".

He includes some results with a bit more standardized testing - one run with both 5.3 and 5.4 using XDebug and another with it turned off for both. His results make sense, if you think about them:

So what we learn from that? Running stuff with debugging tools is slower than not doing that. That's why we don't use xDebug in production.
0 comments voice your opinion now!
benchmark rebuttal xdebug trust exception speed memory



Community Events





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


opinion library api unittest bugfix podcast introduction series update interview version symfony language framework community release deployment laravel zendserver package

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