On the Trivago Tech blog they've shared some of their experience in continuous performance improvements in PHP applications and how the Blackfire.io service helped them get their best performance.

Our mission is to provide the user with the ideal hotel at the lowest rate. Our backend consists of several services written in different languages. To succeed at this goal we do complex tasks in our main application developed in PHP. While doing this we need to keep the website as fast as possible.

We started to look for some tool that could help us identify performance issues in our code base. We evaluated Blackfire and decided that it was a good fit for our use case.

The article starts by answering the question of "why Blackfire?" and continues on, showing how they integrated it with their workflow. They use the SaltStack tooling to set up servers and configure them so it was just a matter of integrating the Blackfire agent and probe extension via that. They include an overall diagram of how it fits into the architecture and how they worked around the lack of Bitbucket server support. The post finishes with some examples of performance metrics from before and after the optimizations from their results stored in InfluxDB.

The SitePoint PHP blog there's a tutorial posted showing you how to integrate your application with Bugsnag, the "last error monitor you'll need". Bugsnag is an external service that provides you more insight into the errors in your application and statistics around them.

The pursuit of building an error-free application continues. But in the meanwhile, we need to monitor our application’s errors and take action quickly. Many companies have tried to solve this problem, and one of the best on the market right now is Bugsnag. [...] In this article, we’re going to discover Bugsnag and integrate it into an existing Laravel application. You can clone the demo app from Github to follow along.

The article walks you through the setup of the demo application (cloned from GitHub) and the creation of a Bugsnag account with a 30 day free trial. It then shows how to integrate the PHP notifier package into your application, though the sample application is Laravel-based so they show how to use this package in the examples. From there they show how to provide your credentials, set up the environment for the app (ex: production, development, etc) and methods for sending various messages types and content over to the service. The post then looks at the Bugsnag dashboard, giving a brief overview of how it looks and what features it includes.

Federico Cargnelutti has a quick post to his site today sharing some general API tips you could follow when creating your backend application.

Organizations who are paying attention already know they need to have an open web API, and many already have under development or in the wild. Make sure you haven’t been caught by the pitfalls of many early API releases.

He briefly mentions the idea of having multiple points of failure and includes five more general tips based on information from this video:

• Test it all
• Plan for future versions
• Embrace standards
• Monitor everything & be honest
• Fail well

On the PHPClasses.org blog today Manuel Lemos has shared some advice on tracking and fixing bugs and some strategies to help prevent them in the future.

No matter how hard you try to test your PHP applications before putting them in production, you will always ship code to your server that has bugs. Some of those bugs will be very serious and need to be fixed before they cause greater damages to your application data that may be too hard to recover. Read this article to learn about a several good practices that you can apply to track bugs in production code, so you can fix them before it is too late.

Suggestions included in his list are things like:

• Test as Much as Possible Before in your Development Environment
• Separate your Code from Environment Configuration files
• Track PHP Errors with Assertion Condition Tests
• Send PHP Errors to an Error Log File
• Monitor the PHP Error Log File to Quickly Fix Serious Bugs
• Fix Your Bugs but Never Edit Code on the Production Server

He also includes a brief look at some things to think about when considering "defensive coding practices" and links to other articles with more information.

On the Inviqa techPortal today there's a new post talking about the New Relic monitoring service and what it has to offer PHP developers and their applications to help them manage things like performance and resources.

The performance of a web application plays a critical role in how an application is perceived by its users. It is important to measure it, identify the causes if it changes and react swiftly to any unexpected changes. This article describes an industry leading tool, New Relic, and how it can be used to monitor and improve your site performance. [...] New Relic is a real-time application monitoring service, providing various metrics about the performance of your production site, covering everything from application database queries through to the time it takes for the end-user to view a page.

They walk you through a "getting started" with the tool and how to get it running on your server - for PHP this means installing an "agent" extension and a local daemon for it to feed information back to. They then get into some of the data New Relic provides including application performance details, browser information, throughput and an Apdex score.

Gonzalo Ayuso has a new post to his blog today looking at a method you can use for real-time monitoring of your PHP applications with a combination of websockets and Node.js. The trick is to handle the PHP errors and send them over to a Node.js server for processing.

The inspection of the error logs is a common way to detect errors and bugs. We also can show errors on-screen within our developement server, or we even can use great tools like firePHP to show our PHP errors and warnings inside our firebug console. That's cool, but we only can see our session errors/warnings. If we want to see another's errors we need to inspect the error log. tail -f is our friend, but we need to surf against all the warnings of all sessions to see our desired ones. Because of that I want to build a tool to monitor my PHP applications in real-time.

The service will work similar to a chat server, sending messages one at a time to the remote server via a web client (HTML5-based) and some backend PHP. He includes all the code you'll need to create the HTTP and web socket server as well as the web client (with some Javascript) and some example server-side PHP. It throws an exception and catches it to send to the waiting Node.js server. A screencast is also included showing the full process. You can get the complete code for this example in this repository on Gonzalo's github account.

WordPress developers (or just site admins) will be happy to know that a new book is in the works (by Alison) about securing, monitoring and generally "unhacking" WordPress.

I'm at the very early stages of writing a book about how to secure, monitor and un-hack WordPress. This book will be the culmination of everything I know about keeping WordPress hardened against attacks, how to keep an eye on your install so that you’re the first to know if something has happened, and how to handle the situation if you bought the book too late and got pwned anyway.

The book will be released as an e-book and she explains some of the specifics of that in the post - cost, pre-ordering, why an e-book and her qualifications to write and release the book as a good thing to follow.

On the Oracle Technology Network today there's a new article from Chris Jones about using the client identifier in the OCI8 PHP-to-Oracle connections to help with auditing, profiling and monitoring your Oracle database usage.

This "client identifier" can be used by Oracle Database to distinguish between individual web application users who all connect to the database using one common set of database credentials. For example, every page in a web site might physically connect to the database as the same database user PHPUSER. If two different people 'Chris' and 'Alison' are using the site, these two user names can be set as their respective client identifiers and be passed into the database.

He shows how to set these client identifiers via the oci_set_client_identifier function (and how you could use it in older versions of the OCI8 driver too). He provides a sample application to help you get a good overall picture complete with SQL to load the database and a basic login page to submit and pull that data back out.

He moves over to the database side where he talks about enabling auditing, pulling out the logged application ID and how to use this identifier to restrict access via a Virtual Private Database on the Oracle side.

Kevin Schroeder has a new post to his blog today on how to correctly evaluate the Zend Server product from Zend (disclaimer: he is a Zend employee).

As you all probably know, Zend has salespeople. Those sales people have sales engineers who show how to use our products. However, I personally hate being on the phone for a canned presentation when all I really want to do is tinker. So, in an effort to produce something of benefit today I decided to start a series of blog posts on how to evaluate Zend Server if you are a tinkerer, like me.

He gives a list of some of the features that the product comes with, but will only really focus on three of them in his series - application monitoring, code tracing and the Zend Server job queue (because he thinks they're the best of the crop). This post is just an introduction to the product and an overview of what it offers - expect more detail to come in future posts.

Continuing on in their series of working with stand alone PHP scripts, DevShed has posted this third and last part looking at the creation of a basic script you can use to monitor your server (an excerpt from Advances PHP Programming by George Schlossnagle).

Last week, we continued our discussion of PHP standalone scripts with child processes and more. This week, we conclude our discussion and bring together what you've learned.

They start with the creation of a very basic daemon, including permission restrictions. They then modify this heavily to support the monitoring of processes through various parameters like frequency, status_time, and a description of the service. They then create the full example script and show the usage by checking to see if a URL passed in can be opened.

They also include, as a bonus, another more useful script that will email someone when the specified service goes down (still a HTTP check, though).