The JMeter GUI is great for creating and debugging test plans, however, as I have mentioned in a previous post it is not recommended for running your actual test plan. JMeter is simply not designed to produce high loads in GUI mode, as it can consume a lot of resources and potential produce unreliable load test results. While it is recommended you run your actual test in CLI mode, this means you have to wait until the test is complete before you can see the results. While this might be okay for short tests but for longer running soak tests you might want to examine the results while the test is running. In this post, I will show you how this can be achieved using InfluxDB and Grafana.
InfluxDB is a time-series database built for high-performance handling of time-stamped data. JMeter provides a backend listener InfluxdbBackendListenerClient to write the data to InfluxDB. Grafana is an open-source metric analytics and visualization suite. It is most commonly used for visualizing time series data for infrastructure and application analytics. Continue reading
Okay, so we all love and appreciate something that has been packaged up nicely. There are some really useful features built into Sitecore package designer that can make a huge difference in the packages we create and even save us time.
Saving & Opening Existing Packages
If you have spent time creating a package you should save it so that if you need to modify it later, you can. After you have generated and installed the package but discover you have forgotten to include something rather than go through the pain of creating a new package you can simply open the existing package. Opening a package allows you to modify the items contained in the package or add new items. This is a no-brainer. Continue reading
Often while working on projects, a team member may ask you to share your local Sitecore instance with them. Or you might even want to expose your local site to an external service for performance testing/analysis. There is a handy dandy tool that makes this really easy, ngrok. Using secure tunnels ngrok exposes local sites behind NATs and firewalls to the public internet. By connecting to the ngrok cloud service which accepts traffic on a public address and relays that traffic through to the ngrok process running on your machine and then on to the local address you specify.
There are various plans available including a free plan which supports:
- HTTP/TCP tunnels on random URLs/ports
- 1 online ngrok process
- 4 tunnels/ngrok process
- 40 connections / minute
With support for Sitecore 8.2 coming to an end 31st Dec 2019, several clients are planning their migration to Sitecore 9 if they have not done so already. This post describes the process and some of the tasks involved in upgrading from Sitecore 8x.
There are two main approaches when upgrading you might consider:
1. Upgrade existing instances – the upgrade is performed against the existing instances and rolled out to all environments.
- Additional infrastructure is not required for the upgrade
- Usually Requires a code freeze while the upgrade is rolled out to all environments.
- Unanticipated Issues can arise during the upgrade that can cause delays in the development lifecycle.
2. Clean Approach – setup a clean environment and clean Sitecore instances, migrate data.
- Upgraded and tested in isolation of the current production instance.
- Provides an opportunity to upgrade the OS & SQL.
- Easily rollback if issues occur.
- Code freeze to existing solution not required for the entire duration of the upgrade and bug fixes and new features can be rolled out and worked on in parallel to the upgrade.
- Additional Infrastructure is required for the new environments to run in parallel. We would need to spin up new servers to support the new environment as these would be running on different versions of the operating system and version of software to meeting the requirements of Sitecore 9.
- We will have the additional overhead of managing two sets of environments for a period of time while.
The clean approach effectively means you a Sitecore 8x environment – current site and a brand new Sitecore 9 environment – for the upgraded site.
Once you have switched over to 9 you can decommission the old environment. Continue reading
In my previous post in this series on load testing I provided an introduction to JMeter to help get you started in this post I’ll explore the following topics and provide solutions to some challenges you may come across while creating your load tests.
I discovered an issue with the Resolve Sitecore Pipeline step in DEF 1.4.1 on Sitecore 8.2 where my Pipeline Batch process would occasionally return and attempt to update the wrong item. In this post, I will explore how that is possible and provide a simple solution to prevent it from occurring.
In my previous post, I looked at the importance of load testing. In this next post in this series on load testing, I will show you how to use JMeter to create a simple load test, take a look at the various JMeter’s components and some features you should familiarize yourself with to help make load testing easy.
- JMeter is a Java application as a pre-requisite you will need to install the latest 64bit JDK or JRE.
- Download the latest binaries and unzip to a directory, for example, c:\jmeter.
- To run navigate to the \bin directory and run Jmeter.bat or if you are on a mac jmeter.sh.
JMeter UI overview
The UI is divided into three main functional areas:
- Menu bar – provides access to a lot of the main functions and provides relevant information to current running tests.
- Left panel – contains a hierarchical tree view of one or more test plans and the various components contained in the plans.
- Right Panel – this is where you will spend most of your time configuring various components or viewing any associated output from components contained in plans.
I ran into an issue with Sitecore’s Data Exchange Framework v1.4.1 where my pipeline batches would intermittently create thousands of duplicate Sitecore items. This caused a bit of management overhead having to clean out the duplicates. Following some investigation, I decided to add some defensive coding by introducing a Custom Resolve Sitecore Item Processor to replace Sitecore’s OOTB pipeline step and prevent duplicates from being created.
Load testing allows you to gather metrics on the performance and behavior of your application under normal or anticipated peak load conditions. This not only helps you make educated decisions about your application and environment but provides a level of confidence your users should not experience a degradation in performance or worse an outage. By being proactive and making course corrections when issues are encountered during tests.
It involves putting sufficient load on an application while it remains up and running so you are able to gather metrics about the applications performance and the environment. These metrics should include things like throughput-rates, response times, memory consumption and CPU utilization.
Have you ever had to look at the Solr logs for potential issues? It’s not a fun task and the Solr logging UI doesn’t exactly make it easy. In fact, it’s easier to crack open the logs using your favorite text editor. But even that can be challenging.
I’m sure there are plenty of tools out there to help make this task easier like Splunk but what if you don’t have Splunk? I found this handy dandy tool to be pretty quick and useful for parsing Solr logs when troubleshooting issues.