Before we cover some of the most important application performance metrics you should be tracking, let’s speak briefly about what application performance metrics is.

What is Application Performance Metrics?

Application Performance Metrics are the indicators used to measure and track the performance of software applications. Performance here includes and is not limited to availability, end-user experience, resource utilization, reliability, and responsiveness of your software application.

The act of continuously monitoring your application’s metrics is called Application Performance Monitoring. 

But why is this important?

Why do you Need Application Performance Metrics?

For starters, application performance metrics allow you and your team to address issues affecting your application proactively. This is particularly important in situations when the application is the business itself.

Monitoring application performance metrics allows helps your team:

• Avoid downtime.
• Identify anomalies, troubleshoot, and remediate issues early and before they impact the end users.
• Ensure the application’s performance is always optimal.
• Keep your end users satisfied.
• Drive business growth and better scale your business.

However, as important as it is to monitor application performance metrics, trying to monitor everything will be a time-consuming, ineffective, and unproductive use of resources. Thus, tracking the right metrics is much more important as this will provide better insights and understanding of the technical functionality of your application.

Key Application Performance Metrics

Here are some of the most important application performance metrics you should be tracking.

1. User Satisfaction / Apdex Scores

The application performance index, or Apdex score, has become an industry standard for tracking the relative performance of an application.

It works by specifying a goal for how long a specific web request or transaction should take.

Those transactions are then bucketed into satisfied (fast), tolerating (sluggish), too slow, and failed requests. A simple math formula is then applied to provide a score from 0 to 1.

Retrace automatically tracks satisfaction scores for every one of your applications and web requests. We convert the number to a 0-100 instead of 0-1 representation to make it easier to understand.

2. Average Response Time

Let me start by saying that averages suck. I highly recommend using the aforementioned user satisfaction Apdex scores as a preferred way to track overall performance. That said, averages are still a useful application performance metric.

3. Error Rates

The last thing you want your users to see are errors. Monitoring error rates is a critical application performance metric.

There are potentially 3 different ways to track application errors:

• HTTP Error % – Number of web requests that ended in an error
• Logged Exceptions – Number of unhandled and logged errors from your application
• Thrown Exceptions – Number of all exceptions that have been thrown

It is common to see thousands of exceptions being thrown and ignored within an application. Hidden application exceptions can cause a lot of performance problems.

4. Count of Application Instances

If your application scales up and down in the cloud, it is important to know how many server/application instances you have running. Auto-scaling can help ensure your application scales to meet demand and saves you money during off-peak times. This also creates some unique monitoring challenges.

For example, if your application automatically scales up based on CPU usage, you may never see your CPU get high. You would instead see the number of server instances get high. (Not to mention your hosting bill going way up!)

5. Request Rate

Understanding how much traffic your application receives will impact the success of your application. Potentially all other application performance metrics are affected by increases or decreases in traffic.

Request rates can be useful to correlate to other application performance metrics to understand the dynamics of how your application scales.

Monitoring the request rate can also be good to watch for spikes or even inactivity. If you have a busy API that suddenly gets no traffic at all, that could be a really bad thing to watch out for.

A similar but slightly different metric to track is the number of concurrent users. This is another interesting metric to track to see how it correlates.

6. Application & Server CPU

If the CPU usage on your server is extremely high, you can guarantee you will have application performance problems. Monitoring the CPU usage of your server and applications is a basic and critical metric.

Virtually all server and application monitoring tools can track your CPU usage and provide monitoring alerts. It is important to track them per server but also as an aggregate across all the individually deployed instances of your application.

7. Application Availability

Monitoring and measuring if your application is online and available is a key metric you should be tracking. Most companies use this as a way to measure uptime for service level agreements (SLA).

If you have a web application, the easiest way to monitor application availability is via a simple scheduled HTTP check.

Retrace can run these types of HTTP “ping” checks every minute for you. It can monitor response times, status codes, and even look for specific content on the page.

8. Garbage Collection

If your application is written in .NET, C#, or other programming languages that use garbage collection, you are probably aware of the performance problems that can arise from it.

When garbage collection occurs, it can cause your process to suspend and can use a lot of CPU.

Garbage collection metrics may not be one of the first things you think about key application performance metrics. It can be a hidden performance problem that is always a good idea to keep an eye on.

For .NET, you can monitor this via the Performance Counter of “% GC Time”. Java has similar capabilities via JMX metrics. Retrace can monitor these via its application metrics capabilities.

9. Memory Usage

Memory usage is vital because it helps one gauge how an application manages and consumes resources during execution. However, it’s important to recognize that memory usage has technical and financial implications.

From a technical standpoint, high memory usage, memory leaks, or insufficient memory significantly affect application performance and scalability. This will result in slower response time, increased latency, frequent crashes, and potential downtime. However, on a financial front, high memory usage might require additional infrastructure costs like hardware upgrades, cloud service expenses, or additional resources to accommodate your needs.

Thus, monitoring memory effectively is crucial to ensure optimal application performance while minimizing financial impacts.

10. Throughput

Throughput measures the number of transactions or requests an application can process within a given timeframe. It indicates how well an application handles a high volume of workloads. Thus a high throughput generally shows better performance and scalability.

It is, however, important to know that various factors like memory, disk I/O, and network bandwidth influence throughput. Regardless, it is an interesting metric to track, especially since you can use it for benchmarking, identifying resource limitations, and ensuring optimal resource utilization. It is also a decision-maker as it is great for accessing and making performance comparisons of systems and applications on different loads.

Summary

Application performance measurement is necessary for all types of applications. Depending on your type of application, there could be many other monitoring needs.

Retrace can help you monitor a broad range of web application performance metrics. Retrace collects critical metrics about your applications, servers, code level performance, application errors, logs, and more. These can be used for measuring and monitoring the performance of your application.

React Native tries to provide everything that is needed to develop a high performing application. But, there are occasions when you may feel the need to optimize your app. You may opt for professional React Native Development Services for improving the performance of your app. Or, you can learn and implement best practices on your own.

Even though React Native is one of the top app development technologies, performance issues with your app may arise occasionally. Therefore, it’s important to pay attention to best practices and performance enhancements for your React Native app while it’s being developed.

In this blog, we will discuss some best practices for improving the performance of React Native apps.

Tips for Improving Performance in a React Native App

Let’s take a dive deep into some of the best practices for effectively improving the performance of a React Native app.

Use Appropriate Navigation Strategies

There are occasions when developers have trouble navigating React Native apps. Navigation issues occasionally prevent apps from giving users a flawless experience. Thanks to an active and large React Native developer community, many navigational problems have already been resolved. However, you may run into some problems that you still need to resolve on your own. Fortunately, there are a number of solutions to these problems, including React Navigation, iOS Navigator, Navigator and Navigation Experiment. React Navigation is preferred by developers for a wide number of apps regardless of size. iOS Navigator is only used for iOS navigation development and can only be used to fix navigation issues with small applications and prototype development.

Also Read-https://stackify.com/how-to-troubleshoot-performance-with-a-visual-studio-profiler/

Avoid Using Scroll View to Render Huge Lists

When it comes to displaying items in React Native with scrollable lists, there are two ways to do it using ScrollView and FlatList components. Displaying a scrollable list by using ScrollView is simple, but on the other hand, it can directly affect the overall performance of the React Native app. This is especially true when there are a large number of items in the list. To fix this issue, experts recommend listing the items with FlatList.

Avoid Passing Functions Inline as Props

When it comes to passing a function as a property to a component, it is better to avoid passing that function inline. At times when the parent re-renders a new reference, which creates another function. Simply put, the child component re-renders even when the props did not change at all. But, there is a solution. Best practices recommend you declare the function as a class method or as a function inside a functional component. In this way, you can remove any possibility of removing references across re-renders.

Go for Resizing & Scaling Images

Make sure you focus on optimizing images, including graphical content, when improving the performance of your React Native app. When you render multiple images in your React Native app, it may lead to high memory usage on a device. Here comes the importance of optimizing images appropriately in terms of resolution and size. If not properly done, your app is likely to crash due to memory overload. Some best React Native app image practices include using PNG format instead of JPG format and smaller-resolution images. You may also utilize WEBP format for reducing the binary size of your images on iOS and Android by almost a third of the original size.

Cache Images

Images are the core component of React Native. This component is used for displaying images, but it does not provide an out-of-the-box solution for resolving several issues, like rendering a large number of images on a single screen, cache loading performance issues, low overall app performance, image flickering, etc. However, there are still ways to deal with these issues. Using third-party libraries like react-native-fast-image is definitely one way. This library works like magic for both iOS app development and Android.

Avoid Unnecessary Renders

When it comes to avoiding unnecessary renders on the main thread of React Native apps, there is an effective optimization technique. You can do it simply by using React .memo() which can handle memorization. Simply put, when a component receives the same set of properties more than once, it will use the previously cached properties and render the JSX view returned by the functional component only once. This reduces overall rendering overhead.

Use Hermes

Hermes is nothing but an open-source JavaScript engine that is mainly optimized for mobile applications. The main function of Hermes is to reduce the download size of the APK, the memory footprint and consumption, along with the time needed for the app to become interactive. If you opt for professional Native App Development Services from an experienced company, it will help you enable Hermes for both iOS and Android.

Conclusion

There are several other optimization techniques for improving performance, so don’t stop learning your best practices here! Using native Driver with the animated library, for example, helps you avoid arrow functions. You’ll also want to avoid excessive use of higher-order components and implementing bulk reducers, while ensuring you use style reference correctly. Though React Native is a popular and high-performing framework, building apps with performance in mind from the very beginning will always improve your results.

Also Read-https://stackify.com/stackify-joins-the-2020-inc-5000-list-of-fastest-growing-companies/

Part of diligent software development is making sure all system applications work well individually and as a whole. Alongside functionality tests and quality assurance procedures, it’s imperative to establish application performance monitoring to track integral software performance metrics. 

In essence, application performance management encompasses activities concerned with sufficient and functional application performance. One of these activities is application performance monitoring, a process by which developers are able to:

• Track the software application behavior
• Detect errors and trace where they occur
• Gather application performance data and provide analysis
• Apply appropriate fixes so issues encountered will not persist

Because of such importance, application performance monitoring (APM) tools have become a necessity in every developer’s toolbox. Some examples of APM tools include Netreo Retrace and Microsoft Systems Center Operations Manager (SCOM). While most tools offer the same functionality, they differ in compatibility.

In the Node.js development environment, the same principles apply. However, there are certain intricacies that need consideration for environment-specific monitoring. In here, we will learn about:

• Node.js Performance Monitoring
• Metrics for Node.js Performance Monitoring
• Top Node.js APM tools

Also Read-https://stackify.com/windows-server-performance-monitoring-best-practices/

Node.js Performance Monitoring

We should know that Node.js is an open-source and cross-platform runtime environment. This environment is used to develop server-side and networking applications. Developers and businesses use Node.js for its numerous advantages. For one, its runtime environment allows for fast delivery of scalable network applications. Other advantages include:

• Lightweight, event-driven, non-blocking I/O model fit for data-sensitive and real-time processes
• Hosts a rich pool of JavaScript libraries and modules
• Compatible with multiple platforms and operating systems such as OS X, Windows and Linux

Aside from these advantages, the Node.js platform is popular among software architects and developers for its distinguished features.

1. Very fast. Code execution of its libraries is fast since it is built on Google Chrome’s V8 JavaScript Engine
2. Asynchronous and event-driven. All APIs developed in the Node.js environment do not block any event. For multiple API calls, the servers distribute them to the concerned APIs and the Events mechanism collects the responses
3. Does not buffer data. Simply, the Node.js environment does not delay any data, and sends out responses in bulk as soon as they’re available
4. Highly-scalable. Despite being single-threaded, the event looping mechanism allows for much more scalable server responses. The single-threaded program accommodates the number of requests made between servers
5. High performance. Because Google Chrome’s V8 and Node.js regularly update the environment, you’re sure to produce optimal application performance. Moreover, this applies to the multiple operating systems Node.js is compatible with
6. Allows cross-platform development. Node.js libraries and components allow developers to build cross-platform applications

Given the above-mentioned features, Node.js provides an established runtime environment for innovative application development. That said, an application is only as good as the developers that build it. To ensure optimal Node.js application performance, you need to employ performance monitoring measures in your application development.

Also Read-https://stackify.com/rails-geocoder-a-guide-to-managing-locations-in-your-apps/

Metrics for Node.js Performance Monitoring

Following QA and testing procedures is not the only way to see if your application works well. Beyond these procedures you can guarantee that there would be minimal issues encountered during the testing phase when your application servers work smoothly. That said, you need to monitor relevant application performance metrics. 

In this article we will discuss the following metrics:

• CPU usage
• Memory usage
• Garbage Collection
• Event loops
• User-facing latencies
• System health and downtime

1. CPU Usage

Being single-threaded means that Node.js is using one core of the system’s CPU per instance. Additionally, because Node.js is asynchronous and non-blocking it really does not utilize much CPU.

However, monitoring CPU usage is essential to assess how to optimize this particular metric. By tracking the CPU load and usage, you can find out which processes are CPU-intensive. Then, you’ll be able to resolve any potential risks by creating child processes or forks to minimize bottlenecks.

2. Memory Usage and Leaks

Memory leaks are common in Node.js development and occur if values are stored longer than needed. With the V8 engine used to run Javascript, Node.js performs garbage collection. If you don’t monitor released memory from the garbage collection cycle, you’re bound to encounter memory leaks. To focus on preventing this scenario before it happens, monitor the released memory, process heap size and process heap usage.

3. Garbage Collection

By monitoring the garbage collection cycles, you can determine the time consumed during the collection cycle. Moreover, you’ll see how much memory was released. Given this information, you’ll be able to compare the released memory from the overall heap size, giving you an idea on your application’s memory status and making it easier to forecast possible memory leaks.

4. Event Loops

Node.js processes are fast because its events are performed asynchronously with event loops and prevent requests from blocking one another – thus non-blocking I/O. Requests processed outside the main thread come back as responses. However, certain processes may cause the event loop to lag, such as long-running synchronous events and incremental increases in tasks per single loop. Make sure to monitor event handling speed and average speed of overall loop latency.

5. User-facing latencies

In application performance monitoring, one must always be mindful of the user-facing components of the application. This is also known as HTTP Request/Response Latency. Make sure that pages are optimized and load fast for improving the user experience and customer retention. You’ll need to monitor request/response size, response times, request rates and error rates.

6. System Health and Downtime

Sudden application downtime is very costly, negatively impacting customer relations and opening systems to data security issues. It’s important to monitor your Node.js application’s behavior at all times to ensure that all servers are up and running, event loops are optimized and memory is released regularly. You can use APM tools to keep track of your system behavior to avoid system crashes and downtimes.

Top Node.js Performance Monitoring Tools

As mentioned in the first part of this article, Node.js APM tools are essential in a developer’s toolbox. Software developers and architects can trace the above metrics by using these APM tools, which also yield efficiency when monitoring Node.js application performance. 

Here are 5 popular Node.js application performance monitoring tools:

1. Retrace by Netreo is a popular cloud-based APM tool that offers centralized logs and basic server metrics plus error and log integration. Ideal for pre-production and production applications, Retrace proactively identifies issues before applications are launched into production, traces changes done after deployment and provides feedback on the deployment status. Retrace monitoring components provide actionable insights, helping developers quickly identify, assess and fix problems.
2. PM2 is a process management tool that ensures your applications are always running. Also a user-friendly Node.js performance monitoring tool, PM2 is for deploying and monitoring live production workloads from a web interface and includes log management, container integration and other features.
3. Express Status Monitor is an open-source tool for monitoring ExpressJS, a framework that exists within the Node.js environment. Express Status Monitor tracks response time, CPU and memory usage, status codes and more.
4. App Metrics is an open-source performance monitoring tool managed by IBM. This tool focuses on providing raw data measurements from various application processes, including garbage collection and database query performance metrics.
5. Prometheus is one of the most popular tools for Node.js performance management and a huge community powers it. Among its key features are crisp visualization, availability and integrations, wide client libraries and optimal storage.

Get the best out of Node.js performance monitoring

Be proactive when it comes to Node.js application development. By employing application performance monitoring tools around your development, you can avoid potential risks and downtimes with irreversible consequences.

Retrace is a robust APM solution that covers performance and availability monitoring and one of the most used Node.js performance management tools by developers. Aside from monitoring your application, Retrace also provides code profiling, deployment tracking, error tracking, transaction tracing, centralized logging and user monitoring.

Get your FREE 14-DAY TRIAL with Stackify Retrace today.

Also Read-https://stackify.com/implementing-cache-tagging-redis/

In this article, we will focus on the specific Visual Studio profiling tools for memory and CPU usage.

Visual Studio Performance Profiler: Memory and CPU Usage

Visual Studio (VS) is an integrated development environment (IDE) used for many software development aspects and includes a suite of profiling tools. The VS performance profiler is like a world of its own with multiple performance profiling tools for troubleshooting issues and improving application performance. 

If you want to learn more about the different VS performance profiling tools, read about the Top Visual Studio Profiling Tools.

Two of the most commonly used tools within the suite are Memory Usage and CPU Usage tools, because a slow application typically results from memory and CPU issues. Though it does not apply at all times, these two are the most common culprits.

Memory Usage  

Memory profiling tools are essential when profiling application performance. For the VS performance profiler, the Memory Usage tool is your go-to tool. The Memory Usage tool runs smoothly with .NET Core-managed scenarios and is best in locating memory leaks, code pathways allocating a lot of memory and many other issues.

CPU Usage  

The CPU Usage tool is another staple for VS and measures two basic things. First is the percentage of CPU utilization over time or the percentage of your total CPU usage. The second is the number of times a call to action function appears on the call stack over time.

How to Troubleshoot Performance with VS Performance Profiler

Within the Visual Studio performance profiler you will find profiling tools such as CPU Usage, Database, Events Viewer, Memory Usage, dotNET Object Allocation Tracking, .NET Async, .NET Counter and GPU Usage. Let’s take a closer look at troubleshooting with our two key usage tools.

Troubleshooting Memory Usage  

The Memory Usage tool runs with or without a debugger. When using the Visual Studio performance profiler, you will run without a debugger. Profiling and troubleshooting with the Memory Usage tool is recommended mostly for release builds.

Memory Usage Diagnostics

1. Set solution to Release. Select Local Windows Debugger (Local Machine). Since Memory Usage in the VS Performance Profiler runs without a debugger, you need to switch to a Release configuration. You will see a warning sign under Analysis Target, signaling that you need to switch to Release mode
2. Select Debug > Performance Profiler. Or you can simply click Alt + F2
3. You will see the summary page. Under Available Tools, select Memory Usage
4. Click Start

5. The diagnostic session starts and the window displays a graph indicating your application’s memory use
6. Take snapshots during the session to capture the memory usage for particular moments, such as large spikes. Take snapshots before a memory issue appears and another image after the occurrence of the problem. These provide concrete data for comparison to help identify the possible source of problems
7. After collecting snapshots and appropriate data, select Stop Collection

8. The page will display Memory Usage reports

Troubleshoot CPU Usage  

There are two main actions to take when troubleshooting using the CPU Usage tool: data collecting and analyzing.

Collecting CPU Usage Data

1. Select Debug > Performance Profiler. Or, you can simply click Alt + F2
2. Now, you will see the summary page. Under Available Tools, select CPU Usage
3. Click Start

4. The diagnostic session begins, and you will see a graph similar to what appears below. This displays the CPU usage data. Once data collection is complete, select Stop Collection at the upper left corner of the page

5. Afterward, the CPU Usage tool analyzes the data and displays the report. The report shows bottlenecks or potential CPU issues that affect application performance

Analyzing CPU Usage report

The above image shows the CPU Usage data report. You can see two groups: Top Functions and Hot Path. Under Top Functions are application functions that are taking up a lot of the CPU. The Hot Path shows areas of the code that also use a lot of the CPU’s resources. Through these reports, developers can pinpoint which areas should be optimized.

Call Tree Structure

When you click on one of the functions under the functions table, it displays a flat list of called functions but does not show the path of each function. To view the call tree of the report, navigate the Current View dropdown at the upper left corner of the page, select Call Tree.

The flat list instantly changes to the image above. When you click on a function, it shows you the path and views of what transpired during the system execution. You can see the cause of performance issues and whether they stem from the native code, external code or other scenario.

Performance Profiling with Prefix

Memory Usage and CPU Usage tools are essential for basic performance profiling. However, these are not the only tools for performance profiling. You can find more in-depth tools that will give you more granular data for troubleshooting application performance. 

Besides Visual Studio tools, you can also find other reliable code profiling tools that can efficiently help you, including the developer’s most reliable sidekick, Prefix.

Prefix is one of the world’s most dynamic code analysis tools. Profiling with Prefix can help even the most experienced developers when it comes to optimizing slow SQL queries, hidden exceptions and a host of other code issues. What’s better is that it works for PHP, .NET Core, Python, Node.js, Java and Ruby. 
You don’t have to face another coding nightmare because Prefix can quickly back you up. DOWNLOAD PREFIX FOR FREE TODAY!

• Availability
• Server operations
• Performance
• Security
• And other procedures

Web server monitoring and optimization helps you to troubleshoot bottlenecks as they emerge and optimize server performance. 

In this post, we will discuss how to optimize performance and why it is important.

What is server optimization?

Web server optimization is a specific technical process used to improve data processing efficiency and application configuration alongside overall performance. 

Best practices of server optimization include physical hardware stabilization inside a data centre with the method of server virtualization.

Windows server optimization is necessary as a company depends on the availability and functionality of its interface for business growth. 

Why is optimization necessary?

Web server optimization allows for improved performance and speed required for end-user satisfaction.  When a web server is not optimized:

• Your website will get 11% fewer page views compared to your competitors
  And a 16% reduction in customer satisfaction
• Your website conversions will decrease by 7%
  

These facts show how a few extra seconds have an impact on your business’s bottom line. 

So, in order to  increase your business’s ROI, it is necessary to optimize web servers.  

By implementing a server stabilisation solution, companies can take advantage of under-utilized servers by consolidating the company’s processing workload with separate servers. 

Companies are able to preserve operational resources by using a combination of various servers’ procedures into an efficiently running server. There is another way to accomplish server optimization — virtualization. 

Virtualization builds layers within a single server, which helps it to serve as several servers. This technique can support multiple applications and operating systems with a single server for several users. 

Let’s learn how to optimize server performance with these essential 5 tips. 

Top 5 Points to Optimize the Server Performance

By optimizing your server performance, understand whether your server’s resources and settings are optimal for your business’s needs.  Our 5 essential tips can help you tune your server to fix or avoid common problems, like bottlenecks and overutilization, that cause disruptive downtime.

1) Select the Right Application for Server Optimization

Sometimes “by default” applications are not the best choice for the efficient server performance.  Instead, you need  a different application to increase efficiency of your web server. 

For instance,

CentOS servers work with PHP 5.4 instead of the latest PHP 7.4, including FastCGI Process Manager (FPM) that gives gigantic agility advantages.

The main reason why VPS, Cloud or Dedicated server purchasers’ optimization methods are failing is that they are unaware of  the differences between their default applications and other apps.  Instead, they continue to optimize their code with the same apps without employing other techniques to fix issues.

Merely altering the application server, modifying the settings to fit the site load, and enabling cache, you can improve performance.  

If you’re still stuck to default application settings, then it’s time to try using other options.. 

2) Setup a Quick Reverse Proxy

What happens if other visitors ask for the same HTML files that your server sends to a visitor’s browser?   How will your server send the similar one again? 

Usually, your server retrieves the scripts from the disk, performs the scripts, and then loads the data and assembles the HTML file.  This is a tremendous amount of work, so it is easier for the server to send those files directly from the memory instead of repeating the whole process again. hat could be done by HTTP reverse proxy.HTTP reverse proxy serves as a link  between server and visitors.  When the second customers request the same file, the server will fetch the file from the memory without any delay. 

For optimization, most of the web servers are configured as a reverse proxy. These are the top 3 reverse proxies:

• Varnish – Varnish is a bit more complex compared to other reverse proxies.  However, it perfectly aligns with heavy traffic and high-quality and quantity content to significant improve server speed.
  
• Nginx – Nginx is one of the most popular proxies for high traffic websites, according to a Netcraft survey. Use Nginx for small to large content-heavy sites. It is the most reliable  against traffic spikes due to stability and customizability.
  
• Lighttpd – Lighttpd is best for large sites as it offers support for usage spikes.  It’s lightweight and doesn’t drag down the server.
  

Apart from these,  other proxies that you could use include  Tinyproxy, Squid, Apache, Freeproxy, Wingate, IIS, etc. 

In order todecide which reverse proxy  is best for your server optimization, evaluate the  complexity of your application, its site load, and web configuration.

3) Enable Caching

Caching is one of the best ways to improve server speed when optimizing  server performance optimizatio. With caching, you can cut site load time by more than 50%.

Caching helps  servers save time  fetching the files from disks, retrieving the database, executing application codes, and assembling results into the HTML page whenever a new userrefreshes pages. 

Instead, the server will take already processed results, and forward them to the new visitor. 

Here are the locations to enable cache for web server optimization:

• OpCode cache – This one is composed of results from previous page requests. It saves time for applications like  Magento or Drupal.
  
• Memory cache – Memory cache stores parts of data created by applications in system memory.  When visitors request those parts, the server can provide the data  without any processing. This one is faster than OpCode cache and is best for large load-balanced websites.
  
• HTTP cache – This one doesn’t go with parts of data.  Instead, HTTP cache stores the whole HTML page.  When the page is requested once again, it is easy and fast to serve. This is  ideal for high traffic web applications.
  
• Application cache – When applications, like Magento or Drupal, storee prepared template files in the form of pages, it can significantly reduce process time.  With this,you can use application cache in conjunction with any of the earlier mentioned caches.
  

These caches improve your server speed and optimize the whole performance. 

4) Defragment Database Tables & Optimize Server Settings

Defragmentation in Database Tables

Websites commonly use databases to store product data and content, such as texts, images and media files.

However, developers have to modify or remove pages, change listed products, and add new pages from time to time.  These activities leave “holes” in the database tables. 

These little gaps are in the place of the deleted data, but it never gets loaded again.  This is commonly known as “fragmentation” and causes the application to fetch data  for a longer time and decrease server performance. 

To optimize server performance, you need to fix the fragmentation every month in Database tables if more than 5% of its size. 

To defragment, check your database tables for fragmentation regularly and operate an optimization query. This way you can keep your site from performing slowly.

Optimize Your Database Settings

When  updating your web application or adding the latest plugin or module, it is important to optimize your database settings. 

This means the traffic to your site increases alongside the number of queries executed on the database, resulting in the database load becoming older and more complicated. 

To optimize the application you need to adjust your database settings to optimize server memory and CPU. Also, monitoring server performance is one way to optimize the display.

Monitor Server Performance

Utilizing an Application Performance Management tool, such as Stackify Retrace, can help developers find potential server bottlenecks.  Retrace supports monitoring physical, virtual, and cloud Linux and Windows servers as well as serverless applications. Track changes by configuring server monitoring templates including server uptime, CPU, memory, network utilization, disk space and utilization, and more.  Try your free, 14 day Retrace trial today! 

5) Fix DNS Query Response Time

DNS query response time is a major factor in loading speed.  

The ideal number for a site’s DNS response should be 30 ms or less.  However, many sites go beyond the 200 ms mark for DNS resolution. This happens because of traffic from outside their hosted country.

The main problem here is the distance. The greater distance between a browser and DNS server increases, the more time it will take to execute.

The only way to fix this issue is to use a distributed DNS cluster. cquire 3 low-cost VPS servers from the different regions of the world, and  configure master-slave DNS servers in those 3 VPS servers.

Final Thoughts

Speeding up your page load times has a significant impact on your web server performance.

First, go through your site’s speed test results and analyze the issues that leave a negative impact on your website. Once you figure out the problem then focus on high-impact factors and take the essential steps to optimize server performance.

This experience is all too common for developers and software team managers. What can we do to prevent poor performing code from reaching our production environment and bringing our “guaranteed 0% downtime” platform to its knees under the load of production volume? The answer lies in proper pre-production processes that validate our changes have not had substantial negative performance impacts.

In this article, I propose a workflow for optimizing .Net performance—measuring performance, diagnosing potential issues, and validating the efficacy of improvements. It’s an iterative process of discovery, profiling, refactoring, testing, benchmarking, and monitoring.

The sample application used in this article can be found on GitHub.

Code Reviews

Performing code reviews is an essential part of maintaining some quality control over code before it reaches production. Code reviews allow your team members to read through your changes and, using their best judgment, approve or suggest changes to your work. This also helps the entire team keep abreast of all changes that are important to them.

However, code reviews take up the time of other engineers and can sometimes be less thorough than desired. The thoroughness of a review is rarely communicated to the team and so an approval can provide a false sense of security that the code is indeed production-ready.

Another failure point is that code reviews rarely include any kind of quantitative feedback. In other words, I can suggest method A will be faster or allocate less than method B, but I am unlikely to take the time to prove the quantitative impact of my assertion.

Finally, things simply get missed. Changes can be made in isolation from the consuming code and a reviewer may not be aware of the context in which a particular set of changes is being executed. For example, adding a simple one-time string concatenation may be fine, but if the consuming code is iterating over the changed code millions of times, then we may have just introduced some significant performance bottleneck.

In summary, code review is an indispensable part of the development process. It aids in maintaining style consistency, knowledge transfer, developer education and overall quality control. But, it should not be viewed as a method for ensuring that the implementation does not have any adverse or out-of-bounds performance impact.

The Application

The example application used in this blog post can be found on GitHub. It is a simple .NET Core web API application. The focus of this post is on the /people?name={name} route. This request will search our database of People and perform a fuzzy string match on the name, returning the entire list sorted from most to least similar. For the sake of simplicity, we will only implement one matching algorithm: Levenshtein Distance.

I recommend taking a quick look at the GitHub project. The call stack we’ll be focused on looks like:

• PeopleController.GetAsync
  • PersonService.SearchAsync
    • Enumerable.OrderBy
      • FuzzyComparer.Compare
        • LevenshteinFuzzySearch.ComputeSimilarity

Discovery

Application Performance Management (APM) tools, such as Prefix and Retrace, can be used to identify poorly performing applications at a high level. This investigation enables local discovery of performance issues, and helps us narrow our focus before using a more detailed profiling utility.

Local Development Environment

In this example, I will use Prefix (a free tool from Stackify) to evaluate the distribution of work. This will help me understand what operations contribute the most to overall response time in the request. Perform these steps to get started.

1. Install Prefix on Windows
2. Launch Prefix in your browser by clicking the tray icon
3. Start the application
4. Send a request with the search filter applied

As you can see from the above screenshot, the majority of the work is consumed by our .NET application code while a minor portion is consumed by I/O. From this I can quickly tell that this particular request has a risk of running as slow as 2.2 seconds on the first request and around 900 ms for subsequent requests. This is beyond the threshold of perceived user control. According to Jakob Nielson:

“new pages must display within 1 second for users to feel like they’re navigating freely”.

And it is significantly beyond the 0.1 second threshold of perceived instantaneity.

Staging Environment

Prefix is a great tool for uncovering errors or performance issues in your local dev environment, but it can be difficult or impractical to reproduce production scenarios locally. Tools like Retrace are excellent at providing these same kinds of insights in remotely deployed environments.

Retrace will not only help detect production issues, but can also be used to discover issues in a staging environment so that bugs and performance problems are discovered early in the release cycle. Through log management, application monitoring, metrics and alerts you can quickly improve the quality of your release process. Retrace’s deployment tracking features also enable you to identify performance issues caused by recent changes to application code.

Profiling

Now that we’ve identified—at a high level—an execution code path of interest, we can dive a little deeper by using a profiler. There are several different profiling options, most of which are personal preference. Visual Studio comes with a Performance Profiler, but there are alternatives such as JetBrains dotTrace and dotMemory. I should mention that the only profiler I was able to get to consistently work with .NET Core was Visual Studio Performance Profiler while debugging. In addition to the debugging profiler, Visual Studio comes with several other options, most of which do not yet work with .NET Core.

For a quick overview of the Visual Studio Profiler, I will defer to the official documentation.

Your approach to profiling should probably depend on the application type. For long-running applications with a constant and stable workload, you can sometimes get quick behavioral insights from just the CPU and memory charts. Before I dive into profiling the sample application, I’ll cover two common scenarios you may encounter while profiling.

Memory leaks

The first example shows an app that executes a job every few seconds. You can see the memory being consumed by our application is continuing to grow and doesn’t appear to have any correlation to CPU usage. In this particular case, we’re seeing a memory leak where each unit of work in the application is leaking references and so they are not being cleaned up.

Overworked services

The next example shows an unbound and unthrottled event processing application. In other words, it processes real-time events as they occur.

We can see that while memory is increasing, so is CPU. This may be an indication that the application is just doing too much work, possibly in parallel. We may need to implement some kind of throttling. That could be an out-of-process mechanism—such as limiting the number of unacknowledged messages that should be delivered to a queue (in the case of AMQP). Or it could be an in-process mechanism—such as using a Semaphore. Or maybe we just need to scale our services to handle the load. But without diving in, there’s not much else we can infer from the graphs.

Sample application results

In our example application, there’s not much we can learn from the graphs themselves. However, since we’ve already identified a particular route of interest, we can set breakpoints to record memory and CPU usage around areas of interest. For this application, I set breakpoints in the service layer to capture the resource consumption of our search service.

Below are the results from profiling the sample application. We can quickly see that we’re spending most of our CPU time in our fuzzy comparison function. This should not surprise us. Looking a little bit deeper we can see that 30% of the time spent within this function is spent in System.String.Substring(/*…*/).

Historically, this wouldn’t have been our first choice for optimization. However, since the introduction of System.Span in C# 7.2, we now have a tool for improving some of these string parsing operations. Now that we have a candidate for optimization, the next step is to write benchmarks against the current implementation so that we can accurately quantify our improvements.

Benchmarking

Benchmarking is a critical step when making performance improvements. Without it, we have no way to validate the impact of our changes.

Writing benchmarks

I don’t think there is any argument that the best tool for writing benchmarks for .NET today is BenchmarkDotNet. Lots of people are using this tool today including the AspNetCore team.

I like to approach benchmarking in a very similar fashion to unit testing. For every project in the solution, I will create a corresponding benchmark project. The benchmark project will mirror the organization of the classes in the project under test. Each benchmark gets prefixed with the name of the system under test (e.g. Foo_Benchmarks.cs). This makes them easier to find later and distinguishable when locating types by name.

Running benchmarks

A benchmark application is just a console app that calls the benchmark runner. There are two approaches you can use in this entrypoint. The first is by explicitly listing the benchmarks you’d like to run:

class Program {
    static void Main(string[] args) {
        BenchmarkRunner.Run<Foo_Benchmarks>();
        BenchmarkRunner.Run<Bar_Benchmarks>();
    }
}

The second is a command line switcher that will provide you a prompt to specify the benchmark you’d like to run, assuming one was not provided as an argument. This is particularly useful if your project has a lot of benchmarks since running benchmarks can consume a great deal of time.

class Program {
    static void Main(string[] args) {
        var switcher = new BenchmarkSwitcher(new[] {
            typeof(Foo_Benchmarks),
            typeof(Bar_Benchmarks)
        });
        switcher.Run(args);
    }
}

Using diagnosers

Diagnosers are one example of customizations you can use to improve your benchmarks. They can be attached to your benchmarks by decorating benchmark classes with attributes. My personal favorite is the MemoryDiagnoser, which provides cross-platform allocation and garbage collection detail.

Using test data

The setup, teardown and parameter specification for benchmarks has a pretty similar interface to NUnit. You can create Global and Iterative Setup/Cleanup methods. You can also define compile-time constant parameters as members of the benchmark class or as an enumerable ParamsSource. For non compile-time constants, you will need to implement the IParam interface, which I have done in the example.

There are many more features in BenchmarkDotNet and I highly recommend reading through their documentation.

Example output

The example benchmark uses non compile-time constant parameters to create some random string data to be passed into our distance function. In the example, I generate random strings of lengths 10, 100, 1000, and 10000, and compare each of them against a randomly-generated string of length 100. You can take a look at the generated Markdown results here.

The first observation I would make is that the function’s execution time and allocations are linearly proportional to the size of the query parameter we are provided. What this means is that we have inadvertently created an attack vector for a bad actor. By not truncating the query string value, clients could invoke our API with long query strings in rapid succession. Based on the data, this would likely cause large CPU and memory spikes, potentially degrading our service or forcing us to scale.

The next observation is the memory allocation. In the case of a 1k character string, we will allocate over 6.6 MB just for comparing strings and 66 MB if we get a 10k character string!

Fixing the Problem: Optimizing .NET Performance

Now that we understand the problem, we can implement a solution and validate the improvement with refactoring, unit tests, and benchmarking.

The process

Before we start making optimizations, we need to make sure that we have unit tests around the system we intend to affect. Without tests, we may improve performance but we also risk breaking existing functionality. So the iterative process for making performance improvements should look like:

The solution

In our example application, I’m going to replace the use of string.Substring with the new Span<T> introduced in C# 7.2. For a great introductory on this new type, check out Jared Parson’s video on Channel 9. For a more in-depth look at Span and how you can use it today, check out this post by Adam Sitnik.

Span<T> allows us to work with contiguous memory in a type safe way. In the case of string parsing, this means we can iterate over the characters of a string and use an indexer to access characters without allocating a new string – string.Substring allocates new strings everytime.

I recommend taking a look at the commit to see the updated implementation using Span instead of Substring. The significant change was from this:

var a = str2.Substring(j - 1, 1);
var b = str1.Substring(i - 1, 1);
var cost = (a == b ? 0 : 1);

To this:

var a = str2.AsSpan().Slice(j - 1, 1)[0];
var b = str1.AsSpan().Slice(i - 1, 1)[0];
var cost = (a == b ? 0 : 1);

Benchmark results

In order to evaluate the efficacy of our changes, we need to re-run our benchmarks against the new implementations, comparing them against the old. To do this, we can temporarily expose the old methods and tell BenchmarkDotNet that it should be our baseline for comparison:

[Benchmark]
public int LevenshteinDistance()
=> _levenshteinFuzzySearch.ComputeSimilarity(String1.Value, String2.Value);

[Benchmark(Baseline = true)]
public int LevenshteinDistanceBaseline()
=> _levenshteinFuzzySearch.ComputeSimilarity_Baseline(String1.Value, String2.Value);

Now, running our benchmarks against the new and improved code gives us the following results:

This shows that across the board, execution time decreased approximately 77% and allocations decreased by 94%. So, what does that mean in terms of user response time? Well, let’s take another look at our application in Prefix.

Prefix and Profiler results

Here you can see both implementations running against the same dataset. We can see a slight improvement over the initial request, but what’s interesting is the 318 ms response time for subsequent requests. We’re now much closer to Nielson’s 0.1s target for perceived instantaneity on a fuzzy search across 5000 people records.

If we take a look at the profiler output for the new implementation, we can see how the breakdown has changed.

Common Performance Problems

Here is a short list of a few common application performance problems I’ve encountered in the past:

• Unnecessary collection enumeration and allocation (.ToList())
• Any kind of string manipulation in loops
  • Using string.Substring() instead of Span
  • Using string.Format (or C# 6 interpolation) instead of string.Concat for small operations
• Not using async for I/O operations that can be executed in parallel
• Wrapping synchronous operations in async wrappers and executing them synchronously
• Using List instead of Dictionary for key/id-based access
• Unnecessary boxing (var i = 0; object a = i; var j = (int)a;)
• Large lock blocks or locking types. Use locks on static instance variables as close as possible to the synchronous operation. Consider the use of ThreadStatic or LocalAsync.

Conclusion

At the end of the day, the quality of large-scale applications is limited by the quality of the processes that govern their development. Without proper pre-production processes, we will inevitably release poor-performing code to our users.

Through the use of pre-production tooling such as Prefix and Retrace on staging environments, we can gain quick insights into the performance impact of changes. Once we have identified possible issues, we can follow the procedure outlined above to correct performance problems before they bring down critical systems.

Additional Resources

• BenchmarkDotNet
• Profile application performance in Visual Studio
• dotMemory | dotTrace from JetBrains
• Microsoft PerfView
• Writing High-Performance .Net Code by Ben Watson
• Corestart 2.0: What’s new for performance in .NET Core 2.0 by Ben Adams

In this post, we’ll discuss some tips to identify what’s causing high CPU usage for your ASP.NET web applications.

There are a lot of reasons that your IIS worker process (w3wp.exe) could be using a lot of CPU. We’ll cover some of the top reasons and how to troubleshoot IIS performance problems.

To start, you should look at which web requests are currently executing with IIS to see if that helps you identify the issue to be able to troubleshoot IIS worker process.

How to View Running Web Requests in IIS

One of the first things you should do is see which web requests are currently executing. This may help you identify a specific URL that is causing the problem.

There’s a chance that you could recognize one of the URLs that’s known to take a very long time or cause high CPU issues.

Although, this may also show a bunch of web requests that are queued up and not directly lead you to the root cause.

Via the IIS User Interface

Via the IIS management console, you can view the running worker processes. You can view which IIS application pool is causing high CPU and view the currently running web requests.

After selecting “Worker Processes” from the main IIS menu, you can see the currently running IIS worker processes.

If you double-click on a worker process, you can see all of the currently executing requests.

Here’s an example from one of our servers. You can see that each request is in different parts of the ASP.NET pipeline and currently executing different HTTP modules.

Via Command Line

The appcmd.exe utility can be useful for a lot of things, including the currently running web requests.

C:\Windows\System32\inetsrv>appcmd list requests
REQUEST "f20000048000021c" (url:GET /nopcommerce, time:6312 msec, client:localhost, stage:BeginRequest, module:IIS Web Core)

Understanding The Results & Things to Look For

You can view the currently executing web requests via the IIS user interface or command line. Either way, it returns the same information.

• URL: the complete URL that was being executed.
• Time: the total amount of time, in milliseconds, the web request has been executing.
• Client: the address of the user that initiated the request.
• Stage: the stage of the IIS pipeline that the request is currently in.
• Module: the ASP.NET module that is currently executing.

There are a few things you want to pay attention to when looking at the requests.

• Are all of the requests for the same URL? Perhaps that URL is the source of the problem
• Is a high number of requests coming from the same client? Perhaps a specific user is slamming your web server with traffic.
• Are all the requests stuck in the same stage or module? There could be a problem with requests getting hung in that specific step of the IIS pipeline.

6 Common Causes and how to troubleshoot IIS Worker Process High CPU

There are a lot of reasons that you can be seeing w3wp.exe IIS Worker Process high CPU usage. I have selected six common causes to cover in this post:

• High error rates within your ASP.NET web application.
• Increase in web traffic causing high CPU.
• Problems with application dependencies.
• Garbage collection.
• Requests getting blocked or hung somewhere in the ASP.NET pipeline.
• Inefficient .NET code that needs to be optimized.

 1. High Error Rates Within Your ASP.NET Web Application

Application errors could be happening in your application, and you don’t even know it. Some errors will cause your users to receive an error message of some form. Other errors may happen, and nobody knows about it.

If you are using an error monitoring or application performance management tool, be sure to check those for high error rates.

There are a few places you can look for application error rates and actual errors, including Windows Event Viewer, IIS Logs, and more. Read this article to learn more: IIS Logs, Error Logs and More – 6 Ways to Find Failed ASP.NET Requests

Windows Performance Counters for Error Rates

There are two specific performance counters I would recommend reviewing for high error rates. You can check these by opening Performance Monitor within Windows and adding the counters to the chart view.

• .NET CLR Exceptions -> # of Exceps Thrown / sec: Check this to see if a lot of exceptions are being thrown by your application. It is possible for your application to have a lot of hidden errors that can cause big performance problems.  Any exceptions at all are bad, but some are unavoidable.
• W3SVC_W3WP -> % 500 HTTP Response Sent:  Any requests with a 500 status code are internal server errors. Make sure this percentage is very low. It should be 0-1%.

2. Increase in Web Traffic Causing IIS Worker Process High CPU

One of the simplest explanations for w3wp.exe high CPU usage is an increase in web traffic. However, if you don’t have any baseline for what your normal volume of traffic is, it can be hard to know if traffic has increased.

If you are using some application monitoring tool that tracks the traffic, be sure to check it and see if traffic levels have changed.

If you don’t have any way to know if traffic levels have changed, you could use your IIS log files to try and find out.

You can use VisualLogParser or Log Parser Lizard to query them.

Related tutorials:
Analyze your IIS Log Files – Favorite Log Parser Queries (VisualLogParser)
Tutorial for Log Parser Lizard GUI

There are also windows performance counters for Requests / Sec and Requests Current to see the current traffic rates in real time.

Possible Reasons for Higher Web Traffic

If traffic levels are up, you should evaluate if it should be or not. Here some things to think about in regards to increased traffic levels:

• Client or user: Is there a huge spike in traffic from a specific client, user, or source? Perhaps something that accesses your site is not working correctly. You may need to block a specific IP address.
• Bots: Similar to a specific user causing a lot of traffic, it could be a bot causing it. Look at the user agents being used to access your site in your IIS logs.
• Oprah effect: Did Oprah or somebody mention your products? Did you just go viral? Getting a lot of attention is awesome, but you may need to scale up to handle it.

If your site is receiving a lot more traffic, you may need to get a bigger server (scale up) or more servers (scale out).

But if your site doesn’t get very many requests per second, traffic may not be the problem.

Many ASP.NET applications have 10-30 requests per second. However, I have also seen lightweight web requests on busy apps doing over 100 requests per second. 

The volume of traffic from one web app to another and the related CPU usage varies wildly. It’s all about your specific application.

How to Identify Expensive Web Requests

Using an APM solution, like Retrace, can help you track performance over time of your entire application. It can also tell you which specific web requests take the longest.

APM tools use .NET profilers and other data collection techniques to understand the performance of your application down to the code level.

By identifying which web requests are taking the longest, you may be able to identify your high CPU issue or identify parts of your application that could use some performance review to improve.

Read more: Application Performance Management Solution with Retrace Code Profiling

3. Problems With Application Dependencies

Today’s web applications leverage a lot of different types of external services and dependencies. Including SQL, NoSQL, queuing, caching, and many external HTTP web services.

Slowdowns from any application dependency can cause performance problems with your application.The most common problems are slow SQL queries or problems with external HTTP web services.

Tracking the performance of your application to this level requires an APM tool, like Retrace. Retrace tracks the performance of your application down to the code level. It can help you quickly identify slow SQL queries, web service calls, and much more.

4. Garbage Collection

Microsoft .NET utilizes garbage collection to manage the allocation and release of memory.

Depending on what your application does, the allocation and cleanup of application memory can cause a lot of garbage collection activity. For example, the usage of lots of large string variables on the large object heap causes garbage collection problems.

To measure if garbage collection could be causing problems for your application, check this Windows Performance Counter:

.NET CLR Memory -> % Time in GC: This counter reflects what % of the time your application spends doing garbage collection. If this number spikes a lot above 5-10%, you want to investigate memory usage further.

Garbage collection also has two modes. You may need to enable server mode, which is not the default.

5. Requests Are Getting Blocked and Hang in the ASP.NET Pipeline

There are many steps in the lifecycle of an ASP.NET request. This includes basic steps like the start of the request, authentication, authorization, evaluating the correct HTTP handler and finishing the request. As part of this, there are many standard and custom HTTP modules that may be in use.

The first thing I showed you was how to view the currently executing web requests.

If you are having performance problems, I would suggest looking to see if all the requests seem to hang on a specific HTTP module.

HTTP modules can be native code or managed .NET code. They can be standard .NET modules like FormsAuthenticaion or SessionStateModule. Many applications also use 3rd party or custom HTTP modules.

Are You Using Sessions?

Most people don’t realize how much of a performance overhead ASP.NET sessions cause.

On every page load, they cause your IIS worker process to retrieve your session object, lock it, and then release it at the end of the request.

Sessions cause locking and can cause a bottleneck within your application.

If you are using a session provider like Redis or SQL, any performance slowdowns will impact the performance of your application.

6. Inefficient .NET Code That Needs to Be Optimized

If none of the other common causes was a problem, you might need to dig into the code to make improvements. You will need to use .NET code profilers to capture what methods are being called in your code and how long they take.

Profilers can help you identify specific methods in your code that are very slow.

Warning: Profilers do add overhead to your application. So if your application already has very high CPU usage (90+%), profiling will be very slow, and the performance of your application will get worse.

This could make your application unusable even depending on the detail level of profiling you are doing and the CPU usage before you started profiling.

My favorite .NET profiler is RedGate’s ANTS Performance Profiler. They do offer a free trial that you can take advantage of.

Check out these articles to learn more about ANTS and how to profile ASP.NET applications.

How to Troubleshoot High .NET App CPU in Production With ANTS and Process Hacker
Walkthrough: ASP.NET profiling with ANTS Performance Profiler

Good Luck With Your IIS Performance Problems!

Hopefully, you are reading this because you are trying to figure out how to improve performance. I hope your server isn’t at 100% and you are scrambling!

As a provider of APM solutions, we spend a lot of time working on and thinking about application performance problems. We hope this guide has been helpful to troubleshoot IIS Worker Process (w3wp.exe).

For years, people have been denouncing the Ruby programming language as slow. Is it? Sure, some people will spread a fair amount of FUD around. That’s the tech industry. But there’s no denying that, at least in its main implementations, performance isn’t the area where Ruby shines the most.

In today’s post, we will cover explanations for Ruby performance issues. Then we’ll cover practical tips on what to do to improve the performance of your Ruby apps. Let’s get started!

What can make Ruby code slow?

Ruby performance is sometimes slow, and since we’re not happy with that, we must learn how to speed it up. To do that, we have to understand the causes of Ruby’s slowness. And that’s what we will do in this section.

Ruby has a high memory consumption. It’s an inescapable feature of the language that stems from its design. Remember when I said earlier that one of the most often-celebrated aspects of Ruby is its loyalty to the object orientation paradigm? In Ruby, everything (or almost everything) is an object. This characteristic, in the opinion of many people including myself, makes for code that feels more predictable and consistent, causing fewer “what the heck” moments for the reader. They often call this “the principle of least astonishment,” or PLA.

But this characteristic is also one cause of poor Ruby performance. Programs need extra memory to represent data—even primitives like integers—as objects.

Finally, Ruby’s GC (garbage collector) isn’t that great—at least in versions before 2.1. The algorithm for Ruby’s GC is “mark and-sweep,” which is the slowest algorithm for a garbage collector. It also has to stop the application during garbage collection. Double performance penalty!

Ruby performance tuning: tips to fix common problems

Since you’re reading a post called “Ruby performance tuning,” I’m sure you’re looking forward to seeing performance tuning tips! That’s what we will see in this section. We’ll cover common Ruby performance problems a developer can face when writing Ruby code and what you can do to solve them—or avoid them altogether.

Read files line by line

Reading an entire file at once can take a heavy toll on memory. Sure, the larger the file you’re reading, the larger the amount of memory needed; even relatively small files can put a lot of pressure on your program’s performance. And why is that? Simple: more often than not, reading the file is just the first step. After that, you’ll most likely want to perform parsing to extract the data found in the file and do something useful with it. This will inevitably lead to the creation of additional objects, which takes more memory and exerts even more pressure on the GC.

Let’s see a quick example. Consider the following excerpt of code:

require 'Date'
content = File.open('dates.txt')
years = content.readlines.map {|line|line.split("/")[2].to_i}
leap_years = years.count{|y|Date.leap?(y)}
puts "The file contains #{leap_years} dates in leap years."

This is a silly example, but should suffice for our needs. We have this file called “dates.txt,” which contains—you guessed it!—lots of dates. And they’re in the “dd/mm/yyyy” format, even though this isn’t particularly relevant to the whole performance thing.

The code loads the whole file to memory. Then we use the “readlines” method, which returns all the lines in the file as an array. After that, we map through each line, executing a code block that splits each line using the “/” character as a separator. Then we retrieve the last part of the result—which refers to the year—and convert it to an integer number.

It assigns the result of all of this to the “years” variable. Finally, we use the “count” method to determine how many of the years are leap ones, and we print that information.

The code itself is simple, right? But think about it: why do we need to load the whole file in the memory before starting the process? The short answer is “we don’t.” Since we’re doing the parsing and leap year verification on a line basis, we could—and should—retrieve the lines in the file one by one and then perform the parsing:

file = File.open("dates.txt", "r")
while line = file.gets
    year = line.split('/')[2].to_i
    if Date.leap? year then
        leap_years += 1
    end
end

Even this version still has room for further Ruby performance tuning, but that can be an exercise for the reader.

Change in place whenever possible

You already know Ruby, because of its design, allocates more memory. You’ve also learned that Ruby’s GC, particularly in the older versions, isn’t that fast. To overcome this important roadblock to better Ruby performance, we must use strategies to save as much memory as possible.

One strategy at your disposal amounts to changing objects in place. For changing an object, it’s common for Ruby to have methods that come in two versions. One version returns a new object with the desired modification, keeping the original object unchanged. The other version changes the original object, thus avoiding the extra memory allocation. The method that changes the original object usually has the same name as the version that returns, plus an exclamation mark.

Let’s begin by covering strings. In scenarios where you won’t need the original string after the modification, consider using the versions that change in place. With strings, you should always be careful when concatenating them. To be honest, this is a common performance tuning tip for many languages, not just Ruby. The most used way of concatenating strings will create new objects in memory, which is what we’re trying to avoid:

message = "I like"
message += "Ruby"

In  situations like this, favor using the “<<” (append) method instead:

message = "I like"
message << "Ruby"

That way, Ruby won’t create a new string object, and you’ll avoid the extra memory allocation.

Strings aren’t the only objects that present this memory-saving opportunity. Arrays and hashes are also objects that you can modify in place. The reasoning here is the same as with strings: change the objects in place for situations where you’ll no longer need the original ones.

Tune code that deals with iterators

Ruby iterators can be a source of bad performance because of their intrinsic characteristics. First, the object being iterated won’t be garbage-collected until the iterator is done. The implications of this can be serious. Imagine you have a big list in memory and you’re iterating over it. The whole list will stay in memory. Have no use for the items already traversed in the list? Too bad. They’ll stay in memory just the same.

Here’s the second important point about iterators: they’re methods. This is so they can create temporary objects. What does that mean? You guessed it. It means more pressure on our friend the garbage collector.

Now we understand how iterators can harm Ruby performance, let’s see tips to counter that problem.

Free objects in collections while iterating over them

Suppose you have a large list of a certain object. You iterate over it and use each item in some calculation, discarding the list after you’re done. It would be better to use a while loop and remove elements from the list as soon as they’re processed.

There might be negative effects of list modification inside the loop, but you shouldn’t worry about them. GC time savings will outweigh those effects if you process lots of objects, which happens when your list is large and when you load linked data from these objects — for example, Rails associations.

Avoid using functions that don’t play well with iterators

When dealing with iterators, algorithmic complexity matters a lot. Each millisecond you can shave off counts. So when using iterators, you can avoid certain methods known to be slow. Instead, search for alternatives that can give you the same result without the performance penalty.

The Date#parse method is bad for performance, so avoid it. One solution is to specify the expected date format when parsing. So, suppose you’re waiting for dates in the “dd/mm/yyyy” format. You could do it like this:

Date.strptime(date, '%d/%m/%Y')

This will be considerably faster than what you’d get by using the Date#parse method.

Now let’s consider type checks.

The Object#class, Object#is_a?, and Object#kind_of? methods might present bad performance when used in loops. The checks can take about 20ms, in large-ish loops. That might not sound too awful, but those times add up. Imagine a web application that performs such a comparison millions of times per request. If it’s possible, it’s advisable to move the calls to those functions away from iterators or even methods that called a lot.

The Right Tool for the Job

I’ll finish this post of tips on how to tune Ruby performance by advising you to… not write Ruby code all the time. Yeah, I know this might sound weird and defeatist, but hear me out for a moment. Ruby is an awesome language, and it’s a general, multi-purpose language. This means that, yes, in theory, there’s nothing stopping you from using Ruby to solve any kind of problem. But just because you can, does not mean you necessarily should.

The essential point of this section is to say while Ruby is a great language, it doesn’t have to be the sole tool in your tool belt. It’s perfectly okay for you to mix and match and use other tools in areas where Ruby doesn’t shine.

With that out of the way, let’s stop talking abstractions. Instead, we’ll offer examples of realistic scenarios where maybe Ruby isn’t the greatest choice, performance-wise. We’ll also talk about better alternatives.

C to the rescue

Since the main implementation of Ruby is written in C, rewriting a slow part of your Ruby code in C is always an alternative when you’re facing performance issues. But there are better ways of leveraging the power of C’s raw performance than writing fixes yourself. How would you do that? Simple: by using gems written by third parties in C.

Some authors identify at least two types of those gems written in C. The first type would be gems that should replace slow parts of the Ruby language or even the Ruby on Rails framework. The other type refers to gems that implement specific tasks in C.

Database to the rescue

It’s not uncommon these days for developers—especially web developers—to ignore the most advanced capabilities of databases, using them essentially as glorified data storage tools. And that’s unfortunate since databases often have sophisticated ways of dealing with complex computations using large amounts of data. This shouldn’t be that surprising, but many developers miss out on those features.

They probably opt for the comfort of relying on abstractions such as ORMs in order to not have to deal with SQL and other complex and inconvenient facets of databases. But by doing that, those developers are renouncing the data processing capabilities offered by those database systems. Understanding how to best leverages SQL databases and ORMs is a key component to successful Ruby performance tuning.

Sometimes, when doing classification or ranking of data, you find yourself in a bad performance scenario, even after installing several gems and using them exactly as told. Maybe in this situation, the best solution would be to just perform the computation in SQL and be done with it.

Sometimes developers will struggle with their ORMs or other tools when often-neglected database features such as materialized views would be a better solution.

Tools at your disposal

Today’s post featured basic tips you can apply to optimize the performance of your Ruby application. The list isn’t exhaustive by any means; rather, treat it as a starting point to help you understand some of the most common Ruby performance problems.

Once you get the right mindset, you will identify and troubleshoot not only the problems covered in this post but also problems in other areas.

You don’t have to face that journey all alone though. There are tools available that can help you troubleshoot performance issues in your Ruby and Ruby on Rails applications.

One of these tools is Retrace, a leading APM tool by Stackify. Some of Retrace’s features include:

• App performance monitoring
• Code profiling
• Error management
• Error tracking
• Centralized logging

This might be just what you needed to take the performance of your Ruby apps to a whole new level.

The best way to understand how to performance test your application is to walk through an example.

You can use Node.js for many purposes: writing scripts for running tasks, running a web server, or serving static files, such as a website. Today, we’ll walk through the steps to test a Node.js HTTP web API. But if you’re building something else in Node, don’t worry—a lot of the principles will be similar.

The unique nature of Node.js performance

Before we begin, let’s take a quick look at one of the more unique characteristics of Node.js performance. We’ll need to have knowledge of these characteristics later when we run our performance tests.

What am I talking about?

The big consideration for Node.js applications is their single-threaded, run-to-completion behavior—facilitated by what’s known as the event loop. Now, I know what you’re thinking: that’s a lot. So let’s break this down a little so we understand what these mean.

Let’s start with single threading. Threading, as a concept, allows concurrent processing within an application. Node.js doesn’t have this capability, at least not in the traditional sense. Instead, to write applications that perform multiple tasks at once, we have the asynchronous code and the event loop.

The event loop

What is the event loop?

The event loop is Node.js’s way of breaking down long-running processes into small chunks. It works like a heartbeat: Every few milliseconds, Node.js will check a work queue to start new tasks. If there is work, it’ll bring these onto the call stack and then run them to completion (we’ll talk about run-to-completion soon).

By breaking tasks down, Node.js can multi-task, which is your substitute for threading. That means that while one task is waiting, another can start. So, rather than threading, we use async code, facilitated by programming styles like callbacks, promises, and async/await. Most of the out-of-the-box Node APIs have both a synchronous and asynchronous method of execution.

Okay, so maybe you’re wondering: what does all this techno-jargon have to do with performance?

Let me explain…

Node.js performance and the event loop

Imagine you’re building a Node.js application with two endpoints: one for file uploading, and one that fetches a user profile. The user profile API will probably be requested significantly more often than the file upload, and if it doesn’t respond quick enough, it’ll block every page load for every user—not good.

The user upload API is used infrequently. Also, users expect uploading of tasks to take time, but they’re a lot less forgiving with page load times. If we do not program with the event loop in mind, while the file is uploading, Node.js could end up hogging all the system resources and could block other users from using your application—uh-oh!

And that’s why you need to understand Node.js’s single-threaded nature. As we change our application, we need to consider this behavior. We want to avoid doing long-running tasks synchronously, such as making network requests, writing files, or performing a heavy computation.

Now we know about Node.js’s single-threaded nature, we can use it to our advantage. Let’s go step by step how you can set up, run, and analyze a performance test of your Node.js application to make sure you’re doing your best to leverage Node.js performance capabilities.

Step 1: Choosing Node.js performance test tooling

First, you’ll want to choose a tool that will allow you to run your performance tests. There are many tools out there, all with different pros and cons for Node.js performance tuning. One main thing to consider is that even though you’re testing a Node.js application if you’re going to performance test from the outside world across a network, it doesn’t matter if your performance test tooling is written in Node.js.

For basic HTTP performance testing, I like Artillery a straightforward performance testing tool written in Node.js. It’s also particularly good at running performance tests for API requests. Artillery works by writing a configuration file that defines your load profile. You tell Artillery which endpoints you want to request, at what rate, for what duration, etc.

A basic test script looks like this:

config:
  target: 'https://artillery.io'
  phases:
  - duration: 60
  arrivalRate: 20
  defaults:
    headers:
      x-my-service-auth: '987401838271002188298567'
scenarios:
- flow:
- get:
url: "/docs"

Here, you’re requesting Artillery’s website for a 60-second duration with 20 new users arriving at the URL.

Then, to run the test, you simply execute:

artillery run your_config.yml

Artillery will make as many requests to your application as you instructed it to. This is useful for building performance test profiles that mimic your production environment. What do I mean by performance test profile? Let’s cover that now.

Step 2: Create a Node.js performance test profile

A performance test profile, as above, is a definition of how your performance test will run. You’ll want to mimic how your production traffic does or is expected to, behave, if possible to do accurate Node.js performance tuning. For instance, if you’re building an event website, you’d expect lots of traffic around the time you release tickets, so you’d want to build a profile that mimics this behavior. You’d want to test your application’s ability to scale with large amounts of a load in a short amount of time. Alternatively, if you’re running an e-commerce site, you might expect even traffic. Here, your performance test profiles should reflect this behavior.

Leveraging multiple test profiles

A fun and interesting point to note is that you can create different test profiles and run them in an overlapping fashion. For instance, you could create a profile that mimics your base level of traffic—say, 100 requests per minute—and then mimic what could happen if you saw a lot of traffic to your site, say if you put out some search engine adverts. Testing multiple scenarios is important for thorough Node.js performance tuning.

Replicating large-scale distributed systems

I must take a second here to note something: When an application reaches a certain size, mimicking load in this fashion loses feasibility. The traffic volumes you may have could be so wild, unpredictable, or large in volume it’s hard to create a realistic like-for-like way of testing your application before release.

But what if this is the case? What do we do? We test in production.

You might think, “Woah, hold up! Aren’t we supposed to test before release?”

You can, but when a system gets to a certain size, it might make sense to leverage different performance test strategies. You can leverage concepts like canary releasing to put out your changes into production and test them only with a certain percentage of users. If you see a performance decrease, you can swap that traffic back to your previous implementation. This process really encourages experimentation, and the best part is that you’re testing on your real production application, so no worries about test results not mimicking production.

So far we’ve decided on our tooling, and we’ve created profiles that recreate our production, like traffic and workloads. What do we do next? We need to ensure that we’ve got the data we need to analyze our application, and we do that through Node.js performance monitoring and Application Performance Management (APM) tools. What’s an APM? Read on, and I’ll let you know!

Step 3: Set up your observability/monitoring

We don’t want to just run our performance test against our application and hope and pray. If we do, we won’t be able to understand how it’s performing and whether it’s doing what we think it should. So before we begin, we should ask ourselves questions like “For my application, what does good look like? What are my SLAs and KPIs? What metrics are needed to effectively debug a performance issue?”

If your app performs slowly, or different from what you expected, you’ll need data to understand why so you can improve it. All production applications worth their salt are using some form of observability and/or monitoring solution. These tools, often called APMs, allow you to view critical Node.js performance metrics about your running application.

Getting up and running with an APM

APMs come in different shapes and sizes, all with different features, price tags, security implications, performance, you name it. It pays to shop around a little to find the best tool for your needs. It’s these tools that are going to give us the insights and data we need when we run our Node.js performance tests.

So, if we know we should monitor our application—what exactly should we be monitoring?

Ideally, you want as much data as possible—but as much as we love data; we have to be realistic about where to start! The best place to start is with the following three areas:

• Aggregated logs—Application logs emit either implicitly by some libraries or explicitly by a developer for getting an insight into an application. Most aggregated log tools allow you to easily search and visualize your logged data. In our case, we could log out the performance of each of our APIs and plot them on a graph.
• Infrastructure insights—Your application will run on a host of sorts, so you’ll likely want to see all the data. If you’re running in the cloud, most providers give you this data (albeit in a crude form) out of the box. The data you’ll get from these tools will cover things like CPU and memory usage of your host, connection data, etc.
• Application monitoring—This type of tool usually sits within your application code and can draw insights about how functions are performing/being called, what errors we throw, etc.

Some APM tools, like Retrace, have all or most of these three features rolled into one, whereas others can be more specialized. Depending on your requirements, you might want one tool that does everything or a whole range of tools for different purposes.

Tooling tailored to Node.js

On top of tools, we can also include other Node.js-specific tools and profilers, like flame graphs, that look at our function execution or extract data about our event loop execution. As you get more well-versed in Node.js performance testing, your requirements for data will only grow. You’ll want to keep shopping around, experimenting, and updating your tooling to really understand your application.

Now we’ve set up our tooling, got realistic profiles for our performance, and understood our application performance, we’re nearly ready to run our tests. But before we do that, there’s one more step: creating test infrastructure.

Step 4: Create Node.js performance test infrastructure

You can run performance tests from your own machine if you wish, but there are problems with doing this. So far, we’ve tried really hard—with our test profiles, for instance—to ensure that our performance tests replicate. Another factor in replicating our tests is to ensure that we always run them on the same infrastructure (read: machine).

One of the easiest ways to achieve a consistent test infrastructure is to leverage cloud hosting. Choose a host/machine you want to launch your tests from and ensure that each time you run your tests it’s always from the same machine—and preferably from the same location, too—to avoid skewing your data based on request latency.

It’s a good idea to script this infrastructure, so you can create and tear it down as and when needed. They call this idea “infrastructure as code.” Most cloud providers support it natively, or you can use a tool like Terraform to help you out.

Phew! We’ve covered a lot of ground so far, and we’re at the final step: running our tests.

Step 5: Run your tests!

The last step is to actually run our tests. If we start our command line configuration (as we did in step 1), we’ll see requests to our Node.js application. With our monitoring solution, we can check to see how our event loop is performing, whether certain requests are taking longer than others, whether connections are timing out, etc.

The icing on the cake for your performance tests is to consider putting them into your build and test pipeline. One way to do this is to run your performance tests overnight so that you can review them every morning. Artillery provides a nice, simple way of creating these reports, which can help you spot any Node.js performance regressions.

Now you have lightning-fast Node.js

That’s a wrap.

Today, we covered the event loop’s relevance for the performance of your JavaScript application, how to choose your performance testing tooling, how to set up consistent performance test profiles with Artillery, what monitoring you’ll want to set up to diagnose Node.js performance issues, and, finally, how and when to run your performance tests to get the most value out for you and your team.

Experiment with monitoring tools, like Retrace APM for Node.js, make small changes so you can test the impact of changes, and review your test reports frequently so you can spot regressions. Now you have all you need to leverage Node.js performance capabilities and write a super performant application that your users love!

It’s Node.js vs. PHP… let’s get ready for the showdown!

Similarities

First, let’s take a deeper look at how Node.js and PHP are similar. Since they’re both common in software development, we can look at a few aspects of their similarities. We’ll see what similar types of applications they handle, the platforms they run on, and how they’re both extensible. Let’s start with the common application types.

Application types

Node.js and PHP are both used to serve web requests. They run on a server and handle requests that are routed to them. You can use either one to serve static content, dynamic web pages, and requests for data.

Node.js is a more popular option when it comes to serving web sockets—the go-to implementation is socket.io. But PHP has had sockets available for quite some time. You could have written a socket server or client in PHP in 2003. Since web sockets have become widely available, Ratchet gets you into web sockets quickly in PHP.

Both technologies can be used for serving up streams as well. However, Node.js has a very straightforward way of doing so with the stream API. PHP is a bit more complicated; you’ve got to do more of the low-level coding in order to get it to do something like streaming a video.

Where Node.js and PHP overlap, I’m going to give this one to Node.js for keeping things a bit more user-friendly. You generally don’t have to get too low-level to write modern web applications with Node.js. This translates to better productivity.

Node.js: 1
PHP: 0

Cross-platform

Node.js and PHP are both cross-platform. You can run Node.js on Linux, macOS, Windows, or even SunOS; you can target 32-bit, 64-bit, and ARM processor architectures. And, of course, there are official Docker images on Docker Hub. If compiling the source code is your thing, you can always do that, too.

PHP is available for Unix-based operating systems (including Linux and Sun), macOS, and Windows. Usually, you’re going to install PHP as a web server module or as a CGI component. You can run PHP directly from the command line—as some folks do—but generally, it’ll be run through your web server. There are pre-built packages for PHP, or you can compile it from source code.

So we have a tie when it comes to compatibility with platforms. Both Node.js and PHP can run on almost any platform.

Node.js: 2
PHP: 1

Extensibility

You might want to extend these technologies to fit your own circumstances. You can always fork the source code, modify it, and compile to extend. But there are also add-ons and package managers for both platforms, which we’ll talk about more a bit later. For now, it’s important to note that Node.js and PHP can be extended. They’re open source, and there is a rich ecosystem of add-ons from which to draw.

Node.js has a rich package registry at npmjs.com with strong community contributions. There are other Node.js package registries, but none are really in the forefront yet—although there are some resources about contenders on node-modules.io.

PHP has two popular package managers: PEAR and Composer. The Composer packages are listed on packagist.org. PHP has been around longer, so the community has had more time to build alternatives. We may see more options for Node.js coming to the forefront in the near future.

In terms of extensibility, we effectively have another tie. If you can code in C or C++, then you can extend. But you don’t even need that; you can install packages. If you don’t mind getting into matters of trust, you can also find pre-packaged versions that have already been extended.

Node.js: 3
PHP: 2

Performance

I’m mentioning performance here knowing it’s a loaded topic. After all, the bottom-line performance of an application depends on a lot of factors. Programming, environment, performance of dependencies such as databases, and usage will impact performance. Since Node.js and PHP generally aren’t used in the same way, it’s going to be tough to compare performance directly (some have tried and just look at the backlash in the comments).

Node.js will typically be used to serve up API requests, so it’s usually just a thin layer between a web client and a database. On the other hand, you might use PHP for the whole stack including the compilation and rendering of a webpage.

To avoid comparing apples to oranges, we have to consider many factors. It might not even be worth the effort. After all, your environment will behave differently than any benchmark. The best way to understand performance is to monitor it with something like Retrace. This way, you can keep your Node.js or PHP application performing under real-world circumstances—where performance really counts!

This one is a wash with no points awarded on either side.

Key differences

PHP and Node.js are probably more different than similar. If you look at the most popular websites in the world, most of them use more than one back-end language. PHP is among the most widely used. Know what isn’t? Node.js, that’s what. In fact, it isn’t even listed as a back-end language for any of the top websites.

There’s a reason for that.

Runtime vs. language

Node.js is a runtime environment that runs the JavaScript language on a server. JavaScript was originally designed to run in a browser. It gives the web the power to take action on the client without relying on something platform-specific like a Java applet or Flash. There were other JavaScript runtimes, but Node.js really came along in the right ways at the right time. It gave developers the power to use JavaScript beyond the browser.

PHP is a scripting language. Theoretically, you could run it in a browser if you had an interpreter. However, PHP was made to deliver web content to browsers from a server. It has to be interpreted by the Zend Engine in a web server module or a CGI.

Node.js is the winner here since it acts on its own. PHP relies on a separate web server and doesn’t really do anything that can’t be done by other popular languages.

Node.js: 4
PHP: 2

Desktop applications

Node.js really has come a long in way in terms of its applications. For a while, it was primarily used to serve web requests using something like Express. It’s also popular for communicating over sockets via socket.io. But nowadays, it’s used in so many other ways, such as in building web applications using popular build tools like grunt, gulp, or webpack. These build engines are responsible for compiling and optimizing all the front-end code in so many applications today. Plus, desktop applications such as Skype, Visual Studio Code, and Slack are being built on Node.js. And those are only a few of the most notable that use Electron alone.

PHP is primarily used to serve web applications. But don’t be fooled! It can be used to do almost anything since you can execute it directly via the CLI. You can even use it to build basic desktop apps with PHP-GTK or perhaps PHP-Desktop. Even still, those haven’t had nearly as much success as Node.js desktop apps.

In terms of desktop applications, Node.js is clearly the winner.

Node.js: 5
PHP: 2

Source code

Node.js is written in C++. Its GitHub has 25,000 commits, 131 branches, 522 releases, and 2,379 contributors as of this writing. There are 504 open issues and 222 pull requests. These are all tracked in one place—the public GitHub repo.

PHP is written in C. Its GitHub is a mirror of the official PHP git. It has 109,885 commits, 287 branches, 940 releases, and only 580 contributors. It’s a bit tougher with PHP to get to all the issues and feature requests since the feature requests are on php.net rather than on GitHub. There are 444 bugs and who knows how many RFCs; they don’t give you summaries on that page.

I’m giving PHP the win here since their numbers are better. They’ve been around a lot longer; you can probably attribute the win to that. But I have to hand it to Node.js for having better organization. It’s easier to get to the information as it’s all in one place and they’ve got fairly comprehensive documentation for contributors.

Node.js: 5
PHP: 3

Asynchronous/reactive/non-blocking

When it comes to non-blocking, reactive request handling, Node.js is your ticket. It was one of the first to do this—and it did it by default. It’s possible with PHP, too. However, you have to use an add-on like ReactPHP, Amp, or spatie/async to accomplish your goal. This means you have to adjust your programming model to the framework. Although you might find some pros in this, the cons stack up against PHP on this one. Node.js clobbers it by being first and by doing it natively.

Node.js: 6
PHP: 3

The winner

In the end, the win goes to Node.js. But the race was very close, so let’s see if we can push it just a bit further…

On StackOverflow, at the time of this writing, there are 244 jobs postings for Node.js compared to 153 for PHP. There are also 254,303 questions tagged with Node.js versus a whopping 1,248,725 questions tagged with PHP.

I don’t know if more tagged questions is a good or bad thing, but PHP has had more time to accumulate questions. Let’s presume more questions means more problems for users. If that’s the case, this can be an indication that PHP is harder to use. In light of this, I’m going to call the game for Node.js since it seems to be more in demand—and that’s definitely a good thing!

Whether you’re using Node.js or PHP, you can still use Retrace to diagnose, improve, and accelerate performance! It takes minimal effort to start collecting APM metrics from PHP and Node.js using lightweight profiling modules. Besides, the Retrace dashboard is super-intuitive!

Head over to the demo sandbox and see for yourself.