On the SitePoint PHP blog there's a new tutorial from Daniel Berman showing you how to use the ELK stack to monitor WordPress applications, a combination of Elastic Search, Logstash and Kibana. You can find out about setting this stack up in this previous tutorial.

When something does go wrong, one of the first things you’re going to want to look at are the log files. Not because you enjoy it — log files are not easy to decipher — but because they contain valuable information that can shed light on what exactly occurred.

While [you can use the WP Log Viewer], analyzing WordPress and PHP logs is simply not enough. There are also web server and database logs to sift through. To successfully query huge volumes of log messages coming in from various sources and identify correlations, a more solid solution is required.

Enter the ELK Stack.

He shows how to enable the logging features in your WordPress application (in the wp-config file) and ensure they're not output to the users of your site. He then shows you how to install Filebeat to ship the logs over to the ELK stack. He switches over to the ELK side and shows the configuration needed on Logstash to properly handle the WordPress log format. The remainder of the post helps you get started analyzing the log results and limit it down to only what you need via the Kibana query syntax.

The SitePoint blog has posted a new tutorial from author Daniel Berman about using the ELK stack to monitor PHP applications. The ELK stack is made up of Elasticsearch, Logstash and Kibana to make for effective log storage and searching.

A modern web application environment consists of multiple log sources, which collectively output thousands of log lines written in unintelligible machine language. If you, for example, have a LAMP stack set up, then you have PHP, Apache, and MySQL logs to go through. Add system and environment logs into the fray — together with framework-specific logs such as Laravel logs — and you end up with an endless pile of machine data.

Talk about a needle in a haystack. [...] The ELK Stack (Elasticsearch, Logstash, and Kibana) is quickly becoming the most popular way to handle this challenge. Already the most popular open-source log analysis platform — with 500,000 downloads a month, according to Elastic — ELK is a great way to centralize logs from multiple sources, identify correlations, and perform deep-data analysis.

They walk you through the full installation of all three tools starting with Java (they all require it) followed by instructions for each piece. Once they're all up and running (and playing nice together) they help you configure it to pull in Apache access logs and search on the results. They then populate it with quite a bit more sample data and share some basic tips on searching using the custom searching "language". Finally they talk about the visualizations Kibana offers complete with an example showing browser percentages from users of the site.

On the eZ blog there's a new post, the first part of a series, showing how to optimize the performance of your LAMP stack with the help of some tuning on the server and software levels.

Nowadays, a website is not only a simple HTML page. Your visitors expect dynamic, personalized information fast and you need a scalable way to deliver content as quickly as possible. This, of course, puts significant pressure on page loads and response time. In this series of posts, we’ll explore eZ’s system architecture and provide recommendations on how you can optimize caching and decrease response time with eZ software.

They then talk about the various pieces of software that make up a typical environment and some tips on optimizing them:

• Varnish
• Apache
• MySQL and MariaDB

Each includes the configuration changes and setup that's helped eZ get the most out of their stack and links to other tools to help you evaluate the performance differences.

Andreas Gohr has posted an interesting article to his site showing you how you can easily visualize XDebug stack traces and make them a bit more clear than the usual output dump.

As alluded to in yesterday's post, I'm currently hunting an elusive bug with xdebug. The problem is, that it only happens sporadically and when I know it happened it is too late to set a break point. So usual debugging methods don't work. Instead I want to use xdebug's execution tracing: let it log all function calls and then pick through the log when the bug occurs.

[...] To ease my debugging I looked for tools that could read the computer readable format. I found a few promising candidates, but in the end they either didn't work or they did not provide what I needed. So instead of hunting the bug, I built a tool

His tool takes in the XDebug output and turns it into something much more readable and properly nested.

In this new post to his site Joshua Thjissen has shared some of his discoveries with Xdebug, Symfony 2 and problems with maximum nesting levels of objects in his testing.

Here you are, developing your code based on the Symfony2 framework. Creating a form here, add a Twig template there, until suddenly, boom! Your site doesn’t work anymore, and all the info you can find in your PHP logs is [an error about the maximum function nesting level being reached.

[...] What just happened? Did I create some kind of recursive function I wasn’t aware of, did somebody commit code that I accidentally pulled? Fortunately for us developers, there is a quick way to deal with this: google it...

According to the information he found via his search it's a common issue and can be "fixed" by bumping up the max_nesting_level to a higher value. He could have stopped there but he wanted to explain why this problem happened, what the nesting is all about, how it relates to the limitations of XDebug and why Twig could cause problems with it.

Lee Blue has started up a series of posts talking about his reasoning for moving back to PHP from Rails in his applications. In his first post of the series, he looks at application "shelf life" and the overall lifespan of the project and how that relates to things like maintainability and upgrade handling.

I plan to write a series of posts about how we develop, deploy, and support our affiliate software and digital downloads applications. And why, after 5 years of Ruby on Rails development we switched back to PHP. One of the reasons is what I refer to as the shelf life of a web application. Let’s talk about what happens to a web application if you just let it sit.

He talks about the "rotting on the vine" that one of his clients' Rails 1.0 application faced when the later versions of the Ruby on Rails framework. He talks about how these kinds of upgrades cost money (and time) and how, with the right selections for the deployment stack, some of the costs could be alleviated. He gives the example of a PHP-based deployment setup and how much of the related technology has been stable and (mostly) unchanging over the years, just with new features being added. He offers a few suggestions to avoid this "app rot" and things startups/freelancers can do to help prevent it in their clients' applications.

The Three Devs & A Maybe podcast has posted their latest episode today: Episode #41, an interview with Beau Simensen where they talk about his Sculpin project and his contributions to the Stack project.

This week we are very lucky to have Beau Simensen on the show to discuss all things Stack, Sculpin and podcasting. [...] We touch upon how Beau got into programming, and his progression through Perl to PHP. We then move on to how Stack and Sculpin came to being, and the problems they are each trying to solve. Finally we talk about an upcoming Symfony Live event in London that he will be presenting at (on Stack), and Edd will be attending.

Other topics mentioned include PHP-FIG, an article about the value of the HTTP Foundation component and a video of a presentation from Igor Wiedler about Stack. You can listen to this latest episode either through the in-page player or by downloading the mp3. You can also subscribe to their feed to get this latest episode and others as they're released.

The PHP.cc has a new post today sharing a video from their own Arne Blankerts that wonders if it's time to say goodbye to the LAMP stack.

The LAMP stack has been the tried and true backbone of the web for almost two decades. Lately though, more and more websites replace Apache HTTPD with nginx and move from just (My)SQL to No(t only)SQL. [...] In my "Goodbye LAMP Stack?" presentation at this year's International PHP Conference – Spring Edition, I gave a hands-on introduction to HHVM, the powerful new runtime for the PHP language, and showed how to get PHP applications to run on it.

The video is embedded in the page but it's a little difficult to read some of the slides so you can always head over to YouTube for a larger version. If you're just interested in the slides, you can find them here.

Dan Barrett has written up an excellent guide to setting up a LAMP stack on Debian from the ground up. It includes all the commands, configuration changes and screenshots of the interface you'll need.

Setting up a test environment can be a tricky thing when you compile PHP from scratch. As others have mentioned in the past, installations from Aptitude (and the like) lag behind which can quickly put your test environment out of date. Pulling inspiration from Juan Treminio and Brandon Savage, who both wrote excellent articles on setting up PHP from scratch. I like to keep my options open when developing which left both of those articles lacking a few features and extensions that I’d like to have bundled with PHP.

He guides you through a (detailed) process to get the following set up and running:

• Debian itself (GUI installer)
• Network configuration
• Installation of Apache
• both PostgreSQL and MySQL
• Other software including ImageMagick, GraphicsMagick
• PHP 5.5 (with several extensions of its own)

Gonzalo Ayuso has a recent post to his site showing you how to use Stack to create bundles for your Silex-based applications. Stack is a structure that allows for the reuse of HttpKernelInterface middleware to create a custom "stack" of functionality.

Nowadays almost every modern framework/applications implements HttpKernelInterface (Symfony, Laravel, Drupal, Silex, Yolo and even the framework that I’m working in ;) ) and we can build complex applications mixing different components and decorate our applications with an elegant syntax. The first thing than come to my mind after studying Stack is to join different Silex applications in a similar way than Symfony (the full stack framework) uses bundles.

In his example, he shows an example of a simple GET endpoint for a blog and API. In the first version, he calls the "run" method to execute the handling of the request. The second example, however, includes the attachment of a simple "MyKernel" middleware to the stack and calls "handle" to apply and send the modified Response back to the user.