devopsy.kinsta.cloud

Tag: application performance

  • 14 Tools That Raise Web and App Performance

    14 Tools That Raise Web and App Performance

    In the DevOps Era, teams increasingly are turning to a variety of tools to integrate, accelerate and automate. Speed and efficiency are critical. This is especially amplified in continuous delivery (CD), which enables IT teams to achieve fast and reliable releases. If successful, CD allows for a faster time to market, increased operational effectiveness and getting the right product and features to production as quickly as possible and at a high-performing level.

    So, what are some of the tools that can help to raise software performance? Here is a list of 14 that we at log management platform Logz.io love, some of which will be entirely new to you.

    Continuous Integration Tools

    Jenkins

    An extensible continuous integration (CI) engine, Jenkins is a top tool for DevOps engineers who want to monitor the executions of repeated jobs. With Jenkins, DevOps engineers have an easier time with integrating changes to projects as well as access to outputs to notice easily when something goes wrong. It’s not the fastest or the fanciest tool, but it’s really easy to use, and it has a great ecosystem of plugins and add-ons. It is also optimized for easy customization.

    TeamCity

    TeamCity is a major all-in-one and extensible, continuous integration server. Written in Java, the platform helps developers build and test software continuously as well as monitor externally run jobs such as cron jobs and procmail jobs. It increases the scale of automation and is gaining popularity quickly in DevOps circles. The platform is supported in other frameworks and languages by 100 ready-to-use plugins. TeamCity installation is really simple and has different installation packages for different operating systems.

    Bamboo

    Developed by Atlassian, Bamboo does more than just run builds and tests. It connects issues, commits, test results and deployments so the whole picture is available to your entire product team, from project managers to developers and testers to system administrators. Bamboo supports builds in any programming language using any build tool such as Ant, Maven and make, as well as any command-line tool. Build notifications can be customized based on the type of event and received over e-mail, instant message, RSS or pop-up windows in Eclipse-based IDEs and IntelliJ IDEA.

    (For more, a colleague of mine has published a guide to continuous integration tools.)

    Load and Performance Testing Tools

    JMeter

    Apache’s open-source, Java-based JMeter has a user-friendly GUI, making test development and debugging much easier. JMeter has been widely used for 15 years and is now a popular open-source alternative to proprietary solutions such as Silk Performer and HP LoadRunner. One of key benefits of JMeter is that it is scalable. When you need a higher load than a single machine can create, JMeter can execute in a distributed mode—meaning that one master JMeter machine controls a number of remote hosts. JMeter also has multi-protocol support and out-of-the-box support for HTTP, SMTP, POP3, LDAP, JDBC, FTP, JMS, SOAP and TCP.

    BlazeMeter

    For all of the benefits that it brings, JMeter is limited in its capabilities when used as a standalone tool. For an alternative, check out BlazeMeter, a good tool that allows you to run JMeter in the cloud, increasing scalability even further and providing comprehensive test results in easy-to-read graphs. With BlazeMeter, software delivery and DevOps teams can boost their productivity by seamlessly sharing test scripts with their peers for faster feedback, deeper learning and higher performance. BlazeMeter also has easy integrations with leading CI tools including Jenkins and TeamCity.

    Taurus

    Continuing on the previous point, JMeter is a great tool, but it’s not perfect. Automation and integration with other systems is difficult at times, and it’s another tool to learn and master. This where a tool like Taurus comes in. Beyond JMeter, the list of popular free and open-source tools include alternatives such as The Grinder, Gatling or Locust (also a great tool for load testing, Python-based), each having its own advantages and disadvantages. Taurus is an automation-friendly testing tool that extends and abstracts the above tools (as well as Selenium), and helps to overcome various challenges. Taurus provides a simple way to create, run and analyze performance tests. The idea of Taurus is to provide language creation/configuration scripts (in JSON or YAML) in a more user-friendly way. Not only can you create scripts with Taurus, one of its many additional benefits is that you can also use pre-existing scripts.

    Application Performance Monitoring Tools

    New Relic APM

    Application performance monitoring (APM) tools allow you to target bottlenecks with your application’s framework. New Relic is the reigning market leader—and for good reason. It lets you pinpoint precisely where and when bottlenecks are occurring. DevOps engineers can use the tool to spend less time monitoring applications and more time building and deploying. New Relic offers web request monitoring for .NET, Java and more. It automatically shows a component-based breakdown of the most important requests. A popular, reliable tool, New Relic APM is a great choice for DevOps engineers.

    AppDynamics

    AppDynamics is also a great tool that enables you to monitor Java, .NET, PHP and Node.js applications. AppDynamics offers performance management solutions that let developers diagnose and fix application performance problems in real time. AppDynamics’ monitoring capabilities also help to simplify the management of complex, business-critical apps.

    Dynatrace

    Dynatrace helps users to monitor application servers, database servers and web services. Its feature set in terms of .NET offers code-level monitoring (including CPU and wait times), end-to-end tracing and user experience monitoring. It supports the entire application life cycle, from development environments to load testing to production.

    Infrastructure Tools

    AWS CloudWatch

    Amazon offers AWS CloudWatch, which enables operations to see usage and performance information through their APIs. AWS CloudWatch offers metrics on data transfer, disk usage and CPU utilization that can also be configured to trigger notifications and alerts whenever thresholds are exceeded. AWS users can also inject their own metrics through CloudWatch APIs to generate a comprehensive cross-analysis.

    Google Cloud Monitoring (StackDriver)

    Google Cloud Monitoring provides dashboards and alerts for your cloud-powered applications. Teams can review performance metrics for cloud services, virtual machines and common open-source servers such as MongoDB, Apache, Nginx and Elasticsearch. You can also use the Cloud Monitoring API to retrieve monitoring data and create custom metrics.

    Virtualization and Containers

    Docker

    An open platform for distributed applications, Docker is an application for DevOps engineers who want to “build, ship and run any app, anywhere.” Docker makes it easier for developers and SysAdmins to push code from development to production without the inevitable hiccups that come from using different, clashing environments during the entire application life cycle. Docker is driving the trend toward microservices, in which applications are broken into smaller, self-contained components that are packaged and deployed independently as containers.

    (For those who like the platform, we have a guide to Docker monitoring with the ELK Stack.)

    Configuration Management Tools

    Ansible

    Ansible, recently acquired by RedHat, is a the Python-powered IT automation and configuration framework that allows users to manage their systems without configuration or setup. DevOps engineers can leverage Ansible to save time in application deployment, configuration management and continuous delivery, as well as when managing systems. It recently released its latest version.

    Chef

    Chef is a systems and cloud infrastructure framework that automates the building, deployment and management of infrastructure via short, repeatable scripts called “recipes.” But the real power of Chef is in its use of pluggable configuration modules (a.k.a., cookbooks), nearly 2,000 of which are available within the Chef community. Chef can integrate with cloud-based platforms such as Rackspace, Internap, Amazon EC2, Google Cloud Platform, OpenStack, SoftLayer and Microsoft Azure to provision and configure new machines automatically.

    So, that’s it! What do you think of these tools? Are there any others that you prefer as alternatives? I’d love to hear your thoughts in the comments below.

  • Application Monitoring in the Age of Big Data

    Application Monitoring in the Age of Big Data

    Operations (or ops, as it is known colloquially) has been necessary since the first shared systems came online in the ’60s. While the job title didn’t necessarily exist, the same questions needed answers then as they do now:

    • Is it up and accessible?
    • Is it responding in a reasonable time frame?
    • Is it performing better or worse now than previously?

    In a simple system, say a static web site, these questions are answered easily by requesting the page. In an automated fashion, of course.

    However, when you look at any “late model” technical infrastructure, you’ll find many, many moving parts. These range from border routers to web servers, work queues to databases and data caches to big data clusters. There are thousands upon thousands of computing instances, software processes, network storage devices and network links that can go down, up or just plain wonky. This means potentially millions of places where things can go wrong.

    How do you keep an eye on all of these potential issues? How do you know if they’re responsive? How do you know if things are getting better or worse?

    Some Monitoring Progress

    The “old” method was to write some sort of monitoring script that polled some data that you thought would represent the overall health of that component. Through the years things have gotten more granular. Our monitoring script libraries have grown and we’ve even instrumented our applications with counters (statsd, librato, etc.) and come up with big data storage (opentsdb) to house all of these data points.

    The question remains, Do we have any more clarity than before? We unarguably have more data points. So we must know more about the performance of our systems, right?

    Turns out, in practice, we just have a lot of data and a lot of people attempting to decipher what that data means. If you’ve worked in operations you’ve been up at 2 a.m. looking at status dashboards with green, yellow and red icons and many, many graphs, all in an effort to answer the question: What is going on?

    Sure, some incidents are easy: An instance was retired, or a fiber line was cut somewhere in Kansas.

    I’m talking about the ones that aren’t so clear cut, so to speak:

    • Site feels slow
    • Median response times are up 25 percent from yesterday
    • Usage is down week over week compared to some relevant time frame

    How do you answer those questions in a haystack of data points, up/down status and, in some cases, just plain noise? Application performance managers (APMs) came along and gave us tooling in the app frameworks and the browser. Now we have visibility into which calls are performing poorly and how our app “feels” to the end user.

    This has helped by breaking down the haystack into smaller haystacks and provided a way to search and sort potential performance issues. However, most APM tools depend on instrumenting code such as Java, .Net or Ruby, and are not able to provide monitoring insights for the rapidly growing open source frameworks such as Grails, Akka, Netflix OSS and the like. We’re still left with the haystack problem: What is going on?

    When I’m up at 2 a.m., stumbling over to the computer to find out what issue PagerDuty has alerted me to, I don’t really want to pore through page after page of graphs and up/down status. What would be really helpful is a system that can aggregate all those monitoring data flows and statuses, actually apply some intelligence. Then it could tell me, “Look at this response time of this component, and this metric is reporting something anomalous. This is most likely causing your issue right now.”

    In other words, it would be helpful to have a system that can show both the symptoms and the root cause of the issue. That system also would provide high-quality, high-value information about my infrastructure and combine anomaly detection with root cause analysis to provide real root cause detection.

    One new startup, OpsClarity, is hoping to make troubleshooting more accurate and efficient by combining data science and anomaly detection with root cause analysis.

    Perhaps this is the long overdue beginning of the next age in monitoring.

     

    About the Author/Michael Hobbs

    Michael Hobbs HeadshotMichael Hobbs is the director of Technical Operations at Expa, a startup studio based in San Francisco. Significant experience in building, operating and automating highly scalable application infrastructures has allowed him to contribute to the success of Infusionsoft and Stumbleupon, among others. Michael continues to put that expertise to work at Expa by advising and assisting the next generation of Internet companies. Michael is also a significant contributor to many open source projects, including dokku and herokuish.

     

  • SDN has a lot to offer to DevOps

    SDN has a lot to offer to DevOps

    When discussing DevOps it’s natural to focus the attention on the one operations  team that focuses on application infrastructure. But when you start digging in to DevOps and its applicability to all four operations groups you’ll find that technological shifts in the network – like software-defined networks (SDN) – are just as important to the overall success of DevOps-related initiatives as the spread of software-defined operations going on across the application infrastructure.

    One of the intersections of network and app infrastructure operations is around speed. Not just speed of deployment of services supporting applications, which is critical, but also the resulting speed of the application itself. Application performance management (APM) is a less often mentioned concern of those looking at DevOps but it is one with which developers and app infrastructure operations alike are very interested in not just monitoring and measuring but improving.

    But here’s the thing: the relationship between the app infrastructure and the network are intertwined when it comes to application performance. Measuring and monitoring in the app infrastructure is all well and good, but it is impacted by network performance. And vice versa. Technically speaking, the app infrastructure folks are going to end up tweaking things like TCP; changing window sizes and timeouts in order to improve poorly performing apps. And they should, as TCP is highly tunable and one of the primary means of changing the performance behavior of an application.

    But tweaking TCP has an impact on network performance. TCP is a reliable transport protocol, meaning its particular about thinks like packet order and its very responsible about making sure each and every packet is received. When one isn’t, it resends it. And resends it. And resends it. Retransmit storms contribute to the congestion of the network, which in turn contributes to the need to retransmit, which in turn… well, I think you see the Catch-22 here. While the app infrastructure team is pointing fingers at network operations, the network operations team is pointing fingers at the app infrastructure team.

    Both are equally responsible for the problem.

    SDN promises, in part, to address the problems associated with speed. Both speed of service deployment (through operationalization) as well as speed of delivery, i.e. application performance. SDN will, ostensibly, provide the means to both recognize application specific performance requirements and adjust, as necessary, the delivery of application data through the network in order to meet those requirements. But what it also implies is the ability to provide visibility into the reason why new routes were necessary. There are plenty of reasons an application might initiate a retransmission storm and some of them are related to the application platform (TCP problems), others to the client or the Internet itself, and still others to the network. Being able to quickly identify what is causing a degradation in application performance gives everyone the ability to react and resolve the problem faster.

    That goes to MTTR (mean-time to resolution), a key DevOps-related metric.

    But for all that to happen, there has to be some collaboration (sharing) going on between network and app infrastructure operations. There has to be less finger pointing and more question asking going on between the two, and the sharing of collected performance data across the entire application delivery chain – from network to platform to the app itself. SDN provides a means through which such measurements can be obtained and shared with other systems – and teams. This ability is important. Puppet Labs 2014 State of DevOps Report named it a “top practice” correlated with MTTR, and CA’s latest report indicated 19% of organizations adopting DevOps have experienced “Improved quality and performance of our deployed applications.”

    Monitoring and measuring application performance is a key component of DevOps, and yet a significant portion of that performance is dependent on and related to the network. Which means app infrastructure operations can’t measure or address poor performance without understanding the network’s contribution to the whole.

    SDN “apps” can be one way in which app infrastructure and network operations can gain insight into how apps are performing and how the network is impacting that performance – for good or bad. Whether it’s simply having the data to share or providing an interface into the network to gather the data, SDN has the potential to enable greater collaboration across network and app infrastructure teams.

    That makes it an excellent player in the wider ecosystem of tools and frameworks that support the need for monitoring and measurement associated with DevOps initiatives.

     

  • 5 ways APM can solve your DevOps worries

    5 ways APM can solve your DevOps worries

    This week at the InterOp conference in New York I had the chance to talk to a lot of IT managers transforming their organizations to adopt a DevOps culture. One of the key questions I heard repeatedly was – are there some best practices to break down the wall between Dev and Ops?  How do you get to a point where we can deploy code multiple times a day like Facebook , Amazon and Netflix without impacting our users’ experience ? How do we minimize the risk of deployment failures and the blame game that ensues? With the need to innovate and close the customer feedback loop quickly Ops is being asked to deploy code more rapidly than ever before.  The complexity of hundreds of developers updating code makes it a very sensitive environment. The last thing Operations wants is an outage leading to financial loss and the last thing development wants is to get a call in the middle of the night to figure out what code change caused it.

    To have tight control over this fast paced environment we need Application Performance Management at every step. APM can help break down the Chinese wall between Dev and Ops and eliminate the finger pointing that happens during outages. Here are 5 APM best practices to enable a smooth DevOps working environment

    1. Use the same APM tool in Dev and Ops: APM should not be an afterthought , should not be a tool that only Operations looks at to monitor apps. APM is essential in every step along the way , from dev/test to staging to production. As a part of test deployment, developers should use the same APM tool as Ops to see the impact of the code deployment on the application’s performance and catch issues before hand. With the same tool everyone is on the same page and there is less confusion on the metrics being tracked. Developers can’t say “Sorry Ops, we are not seeing the problem”
    2. Isolate and fix performance problems sooner with Code Level Diagnostics:  Today’s APM tools come equipped with deep diagnostics that lets you drill down to the line of code that may be causing a performance slowdown. When code deployed in the Test or Staging environment results in a response time spike, developers can use deep dive code diagnostics to detect the line of code, the SQL query, the method call that may have caused the spike and fix the problem before it is deployed on production. For example, you can detect that a SQL query is taking way longer than it did last week for a specific mobile device platform.
    3. Detect changes with Deployment Detection: When new version of code is deployed in production, the change should be detected automatically without having to reconfigure the APM tool.
    4. Analyze Pre and Post Deployment Performance Trends: Get before and after snapshots of the end to end transactions from your APM tool and compare performance trends over time. With topological visualizations you can, at a glance, see if any particular business transaction slowed down post deployment. With historical data you can see how the application’s performance and resource consumption is evolving over time. This will help fine tune your apps’ resources as well. For example you can determine whether an AJAX call has been slowing down over the last 2 weeks due to the slow down of a third party API call or because a disk consumption is increasing over time.
    5. Automate actions on failures: Configure your APM tool to take actions on failures. For example configure an action to automatically increase memory if a memory spike alert is generated post-deployment while you take the time to diagnose the root cause.

    Using APM let your developers focus on writing code rather than spend time fighting deployment catastrophes and enable a healthy collaborative working environment between Dev and Ops.