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.

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.

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.

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.

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.

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).