CArehart.org

We all want our web apps and APIs to respond quickly and scale to dizzying heights of traffic, but have we really built our apps to scale to ten times, or even double, our current traffic? Asynchronous messaging is a powerful architectural pattern that will help us avoid fundamental problems with scaling while keeping our ColdFusion apps fast and responsive. In this session, we'll look at how systems like Amazon's Simple Queue Service (SQS) and Simple Notification Service (SNS) – along with similar systems from other cloud providers – can help you build highly responsive, highly scalable apps and services. We'll also see how easy it is to talk to these messaging services from your ColdFusion apps with the latest cloud integration features in ColdFusion 2021.

Machine Learning and AI are massive buzzwords but are they relevant for you? You might be surprised to know Machine Learning is available on Supercomputers, Smartphones, and tiny Internet of Things devices. No longer the domain of Artificial Intelligence PHDs, AI and ML have been democratized and are ready for your use. In this talk, I'll discuss the current state of ML, and AI, show you practical examples of both, and then give a demonstration of TinyML, a service to enable machine learning for all developers with an open source device SDK.

In the previous sessions of this series we have talked about aspect of using FusionReactor which were focused on what it could tell you while problems were happening or starting to happen. But what if your monitored instance or server has crashed/restarted? FusionReactor tracks up to 1 week's worth of information in the core metric graphs if the server crashed or restarts, this information is no longer available (as it's stored in memory). But FR still has the information in the logs and it's still available in the Archive metrics. In this final session introducing troubleshooting, we will focus on the aspects of FusionReactor which can be used AFTER a crash/restart of your monitored instance. In addition to two features which have long existed in FR (alerts and logs), we will especially focus on two newer features that can dramatically ease the process of post-crash troubleshooting: - Archived metrics - Alerts and logs - FR cloud: alerts and profiles

In the previous session of this series, we looked at the features of FusionReactor that generally make it easy to see why a request or transaction is slow, but we acknowledged that sometimes those features don't identify the reason. In this session we will look at a few of the features of FusionReactor that can be used to understand some less obvious reasons for slowness: - Stack tracing requests - Profiling requests - CPU sampler - Memory profiler As useful as these features can be, they do all require that FR be running at the time of the hangup. What can you do when you are not able to get to FR during a hangup? Or if you are looking at it after a restart? We will cover that in the final part of this series.

In the previous session of this series, we took a broad view at how FusionReactor can help you understanding what is or has been going on recently in your server/instance, especially in terms of request or transaction processing. In this session, we will delve into using aspects of FusionReactor to help understand WHY requests or transactions are running slowly. There are some aspects which stand out quite clearly to explain a slow request, if you know where to look. As such, we will cover FR features like: - Request details - JDBC processing within requests - Other monitored relations/transaction types within requests - JDBC history over all requests and applications (recent, slow, longest, and errors) That said, some problems will remain elusive, because they have to do with a request doing something that is not so clearly identified with these features. In part 3, we will move on to using features of FR that can be used in such cases.

In this session, the first of 4 parts, we will focus on using the key aspects of FR related to finding what is or had been going on recently in a given server/instance. And whereas some folks tend to presume that problems are due to resource issues like high use of memory or CPU constraints, often it's more important to step back first and look at the overall state of request and transaction processing, which may give real insight into the nature of problems (or indeed to confirm where there IS a problem, even when users or other monitors are reporting problems). As such, this session will focus on making the most of these key features in FusionReactor: - Web Metrics - Request history (recent, slow, and longest) - Requests error history - CPU, memory and garbage collection information There can be many explanations for WHY requests are slow or WHY resource usage is high. We will delve into additional features to better understand that in later parts of the series. In this first session, the goal is to get a clear understanding of the overall nature of problems, before diving into their causes.

Have you ever wondered if database performance issues were killing your web applications? Whether running CFML or Java apps (FR can monitor both), did you know that FusionReactor lets you view the JDBC activity for every request? You can see the SQL in queries (select, insert, update, delete, etc.) as well as stored procedure calls, and the arguments to either of those types. You can also see JDBC activity you may not code yourself, such as the SQL underlying ORM calls, or the client variable database processing in ColdFusion or Lucee. In this webinar, veteran troubleshooter Charlie Arehart will guide you through the various aspects of how FR can watch every query, including how such monitoring is filtered by default and can be configured to suit your needs. He'll show you the various places JDBC activity is tracked in the FR web interface (including powerful aggregation across and within applications), as well as how it is tracked in Crash Protection alert emails, and how such activity is tracked in the FR logs (on an aggregate basis per request, or even logging individual slow queries). You can even optionally have FR track the query plan created by your DB server for each query! Armed with such information, you can better understand either hangups or slowdowns that may be caused by database activity. And while FusionReactor has no insight into what's going on IN your database or database server, specifically, it can arm you with evidence of when it detects slowness, so that you can present more factual information to work with DBAs, if indeed it helps clarify that a problem is in fact in the database.

In this webinar you'll learn about what's new in FusionReactor 7 and 7.1. Did you know there were 20+ completely new core features and 100+ major improvements and bug fixes? Obviously we can't chronicle them all, but if you are either moving to the latest release of FR or have been running on it, you'll learn about many of the key benefits. Among the new features covered will be the new CPU and heap profiling, thread visualization, JMX metric monitoring, AWS cloudwatch integration, support for more frameworks, and more. Among the enhancements we will discuss are enhanced tracking of request errors and calls to external resources, improvements to the interactive step debugger, auto detection of datasource names, and more. FusionReactor 7 also marked the production release of FusionReactor Cloud, and we will conclude with a brief introduction to that (covered already in another full webinar earlier in 2017).

In this presentation, we will show you the fundamental steps of getting the logs into Excel, and then we'll go further with several specific sorts of analysis which can be done against such log data via spreadsheets, the kinds of useful troubleshooting information we can obtain this way, and we will take time especially to leverage the unique value of pivot tables. You'll see how easy it is for you to use such spreadsheet features, by demonstration of the simple (but not always obvious) steps to follow. This is a follow-up to last month's webinar, "Making the Most of FusionReactor's Logs". In that one, we discussed the benefits of analyzing FR's logs (for post-mortem, trend, or spot troubleshooting), and we reviewed at a high level the many tools available to do such analysis. In this webinar, we will go deeper into using spreadsheet tools like Excel (though the concepts apply as well to OpenOffice Calc and Google Sheets).

Are you aware of all the ways that FusionReactor can help you troubleshoot memory problems? They're the bane of Java-based applications and application servers, right? Actually, sometimes what seems to be a "memory leak" actually has a root cause having nothing to do with JVM tuning or GC algorithm choices. Indeed, there are many tools and techniques that many turn to when trying to solve such problems, as well as tips and gotchas that may or may not really prove accurate or true for your own problem. There are also a fair share of (well-meaning) myths that swirl around resolving JVM memory problems. n this webinar, veteran troubleshooter Charlie Arehart will show the ways that FusionReactor can be used to understand (and indeed prove or disprove) JVM memory problems. Is there a problem with your heap, or might you be misunderstanding something you see? If memory use truly is high, what might be the cause? Or might you have a different kind of memory problem in another JVM memory space, like the code cache, or the metaspace (in Java 8 and above, or permgen in 7 and below)? Is garbage collection happening? Is it hurting? Would forcing one help clear up a misunderstanding? FusionReactor can show all this and more as we'll see in this webinar, and soon it will help even more!