From the Blogosphere
Five PHP APM Tips and Tricks | @DevOpsSummit #DevOps #Microservices
The importance of business transactions to your monitoring solution
By: AppDynamics Blog
Oct. 30, 2015 08:00 AM
Top Five PHP APM Tips and Tricks
This article series has covered a lot of ground: it presented an overview of application performance management (APM), it identified the challenges in implementing an APM strategy, it proposed a top five list of important metrics to measure to assess the health of an enterprise PHP application, and it presented AppDynamics’ approach to building an APM solution. In this final installment this article provides some tips-and-tricks to help you implement an optimal APM strategy. Specifically, this article addresses the following topics:
Business Transaction Optimization
AppDynamics will automatically identify business transactions for you and try to name them the best that it can, but depending on how your application is written, these names may or may not be reflective of the business transactions themselves. For example, you may have a business transaction identified as “POST /payment” that equates to your checkout flow. In this case, it is going to be easier for your operations staff, as well as when generating reports that you might share with executives, if business transactions names reflect their business function. So consider renaming this business transaction to “Checkout”.
Next, if you have multiple business transactions that are identified by a single entry-point, take the time to break those into individual business transactions. There are several examples where this might happen, which include the following:
If a single entry-point corresponds to multiple business functions then configure the business transactions based on the differentiating criteria. For example, if the body of an HTTP POST has an “operation” element that identifies the operation to perform then break the transaction based on that operation. Or if there is an “execute” action that accepts a “command” URI argument, then break the transaction based on the “command” segment. Finally, URI patterns can vary from application to application, so it is important for you to choose the one that best matches your application. For example, AppDynamics automatically defines business transactions for URIs based on two segments, such as /one/two. For most PHP MVC frameworks, this automatically routes to the application controller and action. If your application uses one segment or if it uses four segments, then you need to define your business transactions based on your naming convention.
Naming and identifying business transactions is important to ensuring that you’re capturing the correct business functionality, but it is equally important to exclude as much noise as possible. Do you have any business transactions that you really do not care about? For example, is there a web game that checks high scores every couple minutes? Or is there a PHP CLI cron job that runs every night, takes a long time, but because it is offline and does not impact the end user, you do not care? If so then exclude these transactions so that they do not add noise to your analysis.
Out-of-the-box, AppDynamics captures the entire stack trace while trimming any granularity below the configured threshold. If you are only interested in “big” performance problems then you may not require granularity as fine as 10 milliseconds. You can increase this interval to 50 milliseconds, but you will lose granularity. If you are finely tuning your application then you may want 10-millisecond granularity, but if you have no intention of tuning methods that execute in under 50 milliseconds, then why do you need that level of granularity? The point is that you should analyze your requirements and tune accordingly.
Next, observe your production troubleshooting patterns and determine whether or not the number of snapshots that AppDynamics captures is appropriate for your situation. If you find that, while capturing up to 5 snapshots every minute for 5 minutes is resulting in 20 or more snapshots, but you only ever review 2 of those snapshots then do not bother capturing 20. Try configuring AppDynamics to capture up to 1 snapshot every minute for 5 minutes. And if you’re only interested in systemic problems then you can turn down the maximum number of attempts to 5. This will significantly reduce that constant overhead, but at the cost of possibly not capturing a representative snapshot.
AppDynamics defines three types of thresholds against which business transactions are evaluated with their baselines:
If your application response times are volatile, then the default threshold of two standard deviations might result in too many false alerts. In this case you might want to increase this to more standard deviations or even switch to another strategy. If your application response times have low volatility then you might want to decrease your thresholds to alert you to problems sooner. Furthermore, if you have services or APIs that you provide to users that have specific SLAs then you should setup a static SLA value for that business transaction. AppDynamics provides you with the flexibility of defining alerting rules generally or on individual business transactions.
You need to analyze your application behavior and configure the alerting engine accordingly.
Out of the box, AppDynamics identifies tiers across common protocols, such as HTTP, PHP CLI, PHP MVC, and so forth. For example, if it sees you make a database call then it assumes that there is a database and allocates the time spent in the method call to the database. This is important because you don’t want to think that you have a very slow “save” method in a ORM class, instead you want to know how long it takes to persist your object to the database and attribute that time to the database.
AppDynamics does a good job of identifying tiers that follow common protocols, but there are times when you’re communication with a back-end system does not use a common protocol. For example, I was working at an insurance company that used an AS/400 for quoting. We leveraged a library that used a proprietary socket protocol to make a connection to the server. Obviously AppDynamics would know nothing about that socket connection and how it was being used, so the answer to our problem was to identify the method call that makes the connection to the AS/400 and identify it as a custom back-end resource. When you do this, AppDynamics treats that method call as a tier and counts the number of calls and captures the average response time of that method execution.
You might be able to use the out of the box functionality, but if you have special requirements then AppDynamics provides a mechanism that allows you to manually define your application tiers by using the PHP API functions to further tailor your application.
Capturing Contextual Information
When performance problems occur, they are sometimes limited to a specific browser or mobile device, or they may only occur based on input associated with a request. If the problem is not systemic (across all of your servers), then how do you identify the subset of requests that are causing the problem?
The answer is that you need to capture context-specific information in your snapshots so that you can look for commonalities. These might include:
Think about all of the pieces of information that you might need to troubleshoot and isolate a subset of poor performing PHP transactions. For example, if you capture the User-Agent HTTP header then you can know the browser that the user was using to execute your business transaction. If your HTTP request accepts GET parameters, such as a search string, then you might want to see the value of one or more of those parameters, e.g. what was the user searching for? Additionally, if you have code-level understanding about how your application works, you might want to see the values of specific method parameters.
AppDynamics can be configured to capture contextual information and add it to snapshots, which can include all of the aforementioned types of values. The process can be summarized as follow:
The only warning is that this comes at a small price: AppDynamics uses code instrumentation to capture the values of methods parameters. In other words, use this functionality where you need to, but use it sparingly.
Application Performance Management (APM) is a challenge that balances the richness of data and the ability to diagnose the root cause of PHP performance problems with minimum overhead required to capture that data. There are configuration options and tuning capabilities that you can employ to provide you with the information you need while minimizing the amount of overhead on your application. This article reviewed a few core tips and tricks that anyone implementing an APM strategy should consider. Specifically it presented recommendations about the following:
APM is not easy, but tools like AppDynamics make it easy for you to capture the information you need while reducing the impact to your production applications.
The post Top 5 PHP APM Tips & Tricks appeared first on Application Performance Monitoring Blog | AppDynamics.
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week