Phone800.366.3472 SupportGet Support DocumentationDocumentation Resource CenterResource Center
search
close
Open Menu

Synergex Blog


Announcing SDI 11.1.1d-2763

By Steve Ives, Posted on July 2, 2020 at 1:01 pm

Steve Ives

Shortly after the recent release of SDI build 2755 we discovered an issue that we wanted to address as soon as possible, so today we are announcing the release of build 2763, which we recommend for everyone using Visual Studio for Synergy development.

We are not aware of any customers being affected by the issue, and we have removed the download link for the previous build.

For additional information please refer to the release notes.


No More SDI “Developer” Builds – Just Releases

By Steve Ives, Posted on June 29, 2020 at 3:12 pm

Steve Ives

I wanted to make you aware of a small change that we have recently made to the way that we refer to “interim” releases of the SDI (Synergy DBL Integration for Visual Studio) product.

A few years ago, it became clear that we needed to be able to release our Visual Studio Integration tools on a more frequent cadence than the main Synergy/DE product. So we started doing interim releases that we referred to as “Developer Builds.” Each developer build was identified both by a version number and a build number.

Initially, these builds were often not subject to the same levels of stringent testing that a build for a full release would be, and we made that clear to customers. But now, thanks to considerable improvements in our automated testing processes, these interim builds are now subject to the same levels of inspection and testing as a build for a full release, and it is no longer necessary to discriminate between developer- and full-builds.

For this reason, we have decided to stop referring to these releases as “Developer Builds,” they are now all just “SDI Releases,” which will continue to occur on a much more frequent cadence than Synergy/DE.



Unit Testing in Traditional Synergy

By Steve Ives, Posted on June 12, 2020 at 9:00 am

Steve Ives

One of the most significant new features introduced in Synergy/DE 11.1.1d is a unit testing framework for traditional Synergy. The framework is based on the MSTest framework that we have supported in Synergy .NET for some time and is delivered as a component of our Synergy DBL Integration for Visual Studio product.

Introduction

Unit testing is a method of testing software at a low level, usually at the level of individual subroutines, functions, and methods. Unit tests are frequently written by the same software developers that write the code being tested, and sometimes, in the case of test-driven development, even before the actual code being tested.

The idea is to exercise each routine in as many different scenarios as you can think of, passing various combinations of parameters, both correct and incorrect, and perhaps by altering the execution environment. The goal is to prove that the routine responds correctly in all cases when used correctly, and also to prove that it fails appropriately in all cases when it should fail.

Unit tests are generally small and fast to run individually, but numerous. It is not uncommon to have hundreds or even thousands of unit tests, and, ideally, those tests execute quickly enough to make it feasible to run them frequently.

In some environments, unit tests are configured to run each time the developer builds a new version. In other environments, tests might run as part of a “continuous integration / continuous deployment (CI/CD) pipeline that runs each time developers attempt to check code into a central repository, and the failure of a unit test might cause the check-in of the code to fail.

Adding Unit Tests to a Solution

To make adding unit tests easy, we have provided a new Visual Studio project template named “Unit Test (Traditional).” It adds a traditional Synergy ELB project to your solution, and that project contains some sample unit test code.

Adding Test Classes and Test Methods

Unit test projects contain unit test classes, and a unit test class is simply a class that is decorated with a {TestClass} attribute. Here is an example:

Unit Test Class

A unit test project can include any number of unit test classes. Generally, a test class groups together a related set of tests. In the case of the code above, notice the name of the class is CustomerApiTests. Presumably, tests that exercise a Customer API are to be added later.

Each test class contains one or more test methods, which are, once again, decorated with an attribute. In this case the {TestMetod} attribute. Here is an example of a test class containing several test methods:

Unit Test Methods

The code above declares three test methods, each of which tests a particular piece of functionality of the API. But this is just a simple example. In an actual test class, there may be several test methods to test each of the API functions in different ways. The number of test methods per function is typically determined by how complicated the function is, how many parameters it has, how many different things it can do based on those parameters, etc.

Coding Test Methods

Each test method typically contains a small amount of code, sufficient to test a particular scenario. The operating environment must be the same each time a particular test runs; we’ll talk more about that later. Here is an example of a test method that contains some simple code.

Unit Test Code Example

When writing unit tests, many developers follow what is known as the “AAA Pattern,” which stands for “Arrange, Act and Assert.” First, you arrange (or prepare) whatever is needed to execute the test, then you “Act” by executing the test, and finally, you “Assert” the result of the test. The name of this final phase is interesting because, in MSTest, Assert is the name of the actual class used to notify the framework of the results of a test.

In the example above, the arrange phase involves creating a new instance of the CustomerAPI to use for the test. The Act phase then uses that object to make a call to the API function to be tested. And in the Assert phase, the code checks that the expected customer record was returned.

The Assert Class

The Assert class has many different static methods used to signal success or failure based on various scenarios. The method you choose to use depends on the nature of the tests that you need to execute to determine the success or failure of the test. Some examples of Assert methods are:

Assert.AreEqual(expectedObj, actualObj)
Assert.AreNotEqual(notExpectedObj, actualObj)
Assert.AreSame(expectedObj, actualObj)
Assert.AreNotSame(notExpectedObj, actualObj)
Assert.Fail()
Assert.Inconclusive()
Assert.IsTrue(condition)
Assert.IsFalse(condition)
Assert.IsNull(object)
Assert.IsNotNull(object)

Most of these methods also have several overloads with different combinations of parameters. For example, most also have a variant that allows an error message to be recorded in the case of a failing test, and more. In traditional Synergy, the Assert class is located in the Synergex.TestFramework namespace, along with the various attributes mentioned earlier.

By the way, I should mention that if any test method fails with an error, or throws an exception, then the test framework catches those errors and exceptions and reports them as test failures in the Test Explorer window.

Building Tests

When you build a solution that includes a unit test project, that project builds just like any other traditional Synergy ELB. It is likely that the code being tested by your unit tests exists in one or more other projects in your solution, so to give your unit tests access to that code, you simply add references to the other projects. Also, if you are using a Synergy repository project, and your unit tests require repository data definitions, then also add a reference to the repository project in the usual way. And like other Synergy projects in Visual Studio, if your development environment and code rely on the values of environment variables that are defined using the “Common Properties” method, you may need to opt- into those common properties via the project properties dialog in the usual way.

The Test Explorer Window

Visual Studio includes a piece of UI called the Test Explorer. If you don’t see it already displayed, you can display it by using the menu commands Test> Test Explorer.

Empty Test Explorer

When the Test Explorer window it first displayed, it often starts out empty, but notice the instructions that are displayed in the window, which says, “Build your solution to discover available tests.”

Once you build a project that contains unit test classes and methods, the Test Explorer window will discover and display your tests:

Discovered Tests

By default, your tests are displayed in a hierarchy based on your project name, namespace, and class, and then the individual methods are displayed below each class.

Notice the two green buttons to the left side of the Test Explorer toolbar. These are the Run All Tests and Run Test buttons. In my sample scenario, only one of the tests contains any code; the other two test methods are configured to throw an exception that says “Not implemented.” Here’s what happens when the Run All button is clicked:

Test Results

As you can see, Test Explorer is presenting a summary of what happened when it attempted to run each of the three methods. One test passed, and two failed. Notice the color-coded icons, green is good, red is bad, and notice that all of the parent folders are also red. For a parent folder to show a green icon, all tests below must pass.

Also, notice how the Group Summary pane is displaying a summary of the pass/fail information. This is because we have a folder node selected in the tree. If we select an individual test, then the pane displays the details of the result of that specific test:

Individual Test Results

In addition to executing all tests or a single test, you can also select a number of tests, and use the right-click menu to execute just that set of tests:

Selected Tests Run

In the above screenshot, you can see that the third test was not executed, which is indicated by the light color of its icons background.

Debugging Tests and Tested Code

In addition to merely running tests, it is also possible to use the Test Explorer to launch debugging sessions for specific tests. To do so, right-click on the test and select Debug. A debugger session will start, and the debugger will break in the test method. You can debug the test method, and as long as you have the source code available, you can also step through into the underlying code being tested.

Organizing Tests

As the number of tests in your environment grows, it is likely that the sorting and filtering methods provided by the Test Explorer may not be enough to allow you to work efficiently. For this reason, it is also possible for you to apply custom categorizations to your tests in code.

This is done by decorating your test methods with an additional attribute named {TestCategory}. Here is an example:

Categorizing Test Methods

And having done so, there are options in the Test Explorer toolbar to modify the display hierarchy to include “Traits,” which are the custom attributes that you have applied to your test methods. Here is an example of that:

Test Explorer Traits View

Environment Initialization and Cleanup

As you start to really get into writing unit tests, you will quickly realize that a big part of the road to success lies with your ability to always run your tests in a consistent and known state. For example, if your tests are reading and writing data files, those data files need to be in a known good state.

To help with that, the framework provides some special functionality that can be used to establish and reset the environment, if necessary. In MSTest, there are six such mechanisms; in traditional Synergy, we currently support four of them. These are:

  • ClassInitialize – runs once, BEFORE any test in the class runs
  • TestInitialize – runs BEFORE EVERY TEST in the class
  • TestCleanup – runs AFTER EVERY TEST in the class
  • ClassCleanup – runs once, AFTER all tests have completed

You can optionally add methods to your test class to provide each of the functions that you require. To do so, you simply add public void methods, decorated with an appropriate attribute, like this:

Special Test Class Methods

For example, if you are testing an API, and that API is completely stateless, then instead of creating an instance of the API in each method, then using it and discarding it, you could use a ClassInitialize method to create an instance of the API, code all of your test methods to use that same instance, then delete the instance in the ClassCleanup method.

If your API is not stateless and you do require a new instance for each test, you could simplify the code in each test by defining the code to instantiate the API in a TestInitialize method and discard it in a TestCleanup method. The runtime overhead is the same, but you only have to code the APU creation one time instead of potentially hundreds of times.

In MSTest, there is a third level of Initialization and Cleanup that happens at the “Assembly” (ELB in this case) level. This is implemented the exact same way, via the attributes {AssemblyInitialize} and {AssemblyCleanup}. We do plan to add that support; it just didn’t make it into the initial release.

Summing Up

This post is not intended to be a complete guide to the subject of unit testing in Traditional Synergy, and indeed there are other features that have not been discussed here. Instead, the intention was to provide enough information to pique your interest, and hopefully, that goal was achieved.

I encourage you to refer to the Synergy documentation for additional information, and we are looking forward to receiving your feedback on this important new technology for traditional Synergy.


Codegen 5.5.5 is Released

By Steve Ives, Posted on June 5, 2020 at 6:07 pm

Steve Ives

We are pleased to announce the release of a new version of CodeGen.

The primary reason for this release is that we realized that the installations for the last several releases were incorrectly signed, resulting in Windows SmartScreen reporting the installation as risky, and doing its level best to discourage you from proceeding.

The affected versions of the installer were versions V5.5.1 to V5.5.4. But apparently people don’t pay too much attention to Windows SmartScreen warnings, because I know there have been lots of CodeGen installations of the affected versions, and not a single person reported the issue! That’s pretty scary, and as software developers, we really should know better! With one exception (Jeff Greene), I don’t know who you are, but YOU know who you are!

The issue turned out to be related to the fact that we have been working from home for the last three months, thanks to COVID-19, and the code-signing process on my home development system was silently selecting the wrong signing certificate! Sorry about that! But rest assured, we restored normality with the 5.5.5 installer, which is, once again, signed with the correct code-signing certificate.

Oh, and if you are looking for new features, we also made all method loop expansion tokens available in parameter loops.

This version of CodeGen is built with Synergy/DE 11.1.1c, needs a minimum of version 10.1.1 to operate, and can be downloaded here.


Improved Visual Studio Developer Tools – Available Now!

By Steve Ives, Posted on April 29, 2020 at 5:29 pm

Steve Ives

We are delighted to announce the immediate availability of a new Synergy DBL Integration for Visual Studio Developer Build and to recommend it for use by all Synergy developers. This new release is versioned 11.1.1c-2714, and it can be downloaded from the Synergy Resource Center now.

For the last few development sprints, we decided to focus on addressing quality issues, some reported by customers, and this new release represents the culmination of a lot of hard work on the part of our dedicated developers, testers, and many others.

There are many improvements and enhancements included in this release, but for now, I’ll highlight just two that are of particular importance to customers, and will significantly enhance developer experience and satisfaction overall:

  • We resolved an issue with deep dependency checking that would cause files from built dependencies to not get correctly copied to referencing projects. This mostly impacted .NET.
  • We resolved an issue that was causing debugger “DataTips” for class fields and properties to not show up.

The release includes many more improvements and enhancements, both in the Visual Studio Integration product, as well as both the Traditional Synergy and Synergy .NET compilers that ship with SDI. For complete information I will refer you to the release notes, you will find a link right next to the download link in the resource center.

If you are already using Visual Studio for your Synergy development then upgrade today, and if not, it’s time to give it a try. The developer experience and productivity in the Visual Studio environment really is second-to-none, and remember, you can always use the runtime version targeting features if you need to produce software that will run with older versions of the Synergy runtime on your customer sites.



Synergy/DE 11.1.1c Released

By Steve Ives, Posted on January 29, 2020 at 6:23 pm

Steve Ives

Important quality improvements for REV11 licensing

A new patch release for Windows and Unix is now available to download on the Synergex website. All customers are encouraged to update to 11.1.1c for important quality improvements.

This update includes new versions of the following products:

  • Synergy/DE (32- and 64-bit)
  • REV11 licensing upgrade package (32- and 64-bit, delivered in one installer on Windows)
  • Synergy DBL Integration for Visual Studio
11.1.1c includes quality improvements for the following issues:
  • IMPORTANT: Previously, in REV11 licensing environments, an expired license error could occur if a license allocated by a program expired while the program was running. Even if new keys had been delivered and installed, if the license server had not been restarted since the new keys were installed, the error could occur.

    It is important that all customers using subscription licensing in a REV11 environment install the 11.1.1c patch (for version 11 systems) or apply the 11.1.1c version of the licensing upgrade package (for version 9 or 10 systems).

    If for any reason you are not able to do so, you should ensure that your license server is restarted as soon as possible after your new subscription keys are delivered. Long-running processes are resilient to a license server restart.

  • In versions 11.1.1a and 11.1.1b, if an attempt to rename a remote file (via xfServer) resulted in an error being generated, in some cases xfServer could fail with a segmentation fault.
  • In versions 11.1.1 through 11.1.1b, using the isutl utility to re-index a large multi-key ISAM file with an index exceeding 4,294,967,295 bytes caused a corrupted index to be created.
  • In versions 11.1.1 through 11.1.1b, when running xfServer in Secure or Trusted mode, a client using the RUSER mechanism to provide login credentials to the server experienced a “Bad username, login rejected” error.
  • In versions 11.1.1 through 11.1.1b, in some circumstances when opening a remote file via xfServer when that server did not already have other files open, the xfServer process could fail.
The patch also includes the following enhancements to Synergy DBL Integration for Visual Studio:
  • We significantly enhanced the Visual Studio build system for Synergy .NET projects by improving the dependency-checking algorithms. Previously, any change in the code of, for example, a class library caused all projects that reference that library to be rebuilt. With these changes in place, dependent projects will only be rebuilt if changes in the dependency library result in the signatures of externally visible items being added, changed, or removed. This will result in a significant reduction in elapsed build times in many cases.

  • We improved the hover-over information (QuickInfo) displayed for type declarations for variables, fields, properties, etc. We added simple colorization and documentation comments (when available), and in some cases, type names are now fully qualified.

See the release notes for a complete list of 11.1.1c changes. See the Synergy/DE 11 page for information about the latest Synergy/DE features.

Visual Studio Adaptive Formatting

By Steve Ives, Posted on January 24, 2020 at 4:32 pm

Steve Ives

In Microsoft Visual Studio version 16.4 a new feature was, I was going to say introduced, but snuck in might be more appropriate way of describing things. There was no mention of the new feature in any release notes that we can find, and an internet search for the name of the new feature currently returns no useful matches!

The feature is called Adaptive Formatting and apparently what it does is allows code editor windows to “heuristically determine if the current file should use tabs or spaces for indentation”. Previously this behavior was determined by a language specific setting, and those settings are still present, but if Adaptive Formatting is enabled (which it is by default by the way), then it wins!

So if your code is indented with tabs, and suddenly Visual Studio decides to start using spaces instead (or vice-versa) then it’s probably Adaptive Formatting getting it wrong! Thankfully this new feature can be disabled by going into Tools > Options > Text Editor > Advanced and un-checking the Use adaptive formatting option.

Happy coding everyone!


SQL Replication – Significant New Features

By Steve Ives, Posted on January 16, 2020 at 8:10 pm

Steve Ives

In recent weeks we have been working on making improvements to our SQL Replication environment, which demonstrates how to easily replicate your Synergy data to a SQL Server database. Some of these changes were undertaken in collaboration with a customer that uses the environment extensively, and we thank them for their input and support. Other changes have been on our road-map for some time and we think you’ll be excited about what has been achieved. Here’s a summary of the changes:

  • Synergy 11 introduced a new SQL Connection API capability which calls the ODBC API function SQLDescribeParam behind the scenes to improve performance and avoid excessive cache memory thrashing for SQL statements that have I/O parameters when accessing SQL Server (VTX12_SQLNATIVE). Synergex recommend setting SSQL_PERFORMANCE_SQL to yes (or setting the SQLPERFORMANCESQL environment variable. We have updated the environment to do this, which should result in improved performance when running in Synergy 11 or higher environments.
  • We have added the ability to run multiple instances of the replicator process side-by-side, within a single data set, and to divide up the replication of different files between these multiple replicator instances. Each instance is assigned a unique instance name and has its own associated instruction queue file, the name of which includes the instance name, as does the log file produced by each instance. In a multi-instance environment developers can chose on a file-by-file bases which data files are replicated via which queue file, and therefor via which replicator instance. It is important to understand that in this scenario there is no synchronization of the sequence in which changes are applied to the underlying SQL database between the multiple instances of the replicator.
  • We have added the ability to exclude certain fields in a record from being appearing in and being replicated to the associated SQL Server database table. It is important that fields associated with keys not be excluded, unless those keys are also excluded (see the next item). Generally the fewer fields/columns that are replicated the faster the replication will be.
  • We have added the ability to exclude certain keys from processing, so that matching database indexes will not be created in the associated database tables. Generally the fewer indexes that exist on a table the faster the replication will be.
  • We have added the ability for the replicator to detect some kinds of database failure, caused by network errors, or the database being shut down or otherwise unavailable, and allow it to gracefully disconnect, and then attempt to reconnect, with a configurable number of retries and retry interval. This should make the replicator processes more robust.
  • We have added the ability to change the database datatypes of fields. The main use case envisaged is transforming decimal fields into implied decimal fields (adding decimal places in the database data), but there may be other use cases, such as transforming Y/N fields into Boolean true/false fields, etc.
  • We have also corrected an issue that could occur if replicator encountered an unexpected error and was configured to use BATCH COMMIT mode. Is some circumstances, if there were uncommitted changes at the time on an error any uncommitted changes could be lost because the change records were deleted from the instruction queue one by one before the batch was committed. Now any instructions related to uncommitted changes remain in the queue file until the batch is committed, and are then all deleted. When the replicator is restarted it will then attempt to reply the changes to the database again. This should help prevent the database getting out of sync if there is a replicator failure.

We’re excited about these new features in our SQL Replication offering and looking forward to hearing your feedback. By the way, many of these new features rely on using the latest and greatest version of CodeGen (5.4.8) which was also released today. If you’re already using an earlier version of the SQL Replication environment, or if you are interested in getting started and would like some assistance, don’t hesitate to contact us through your Synergex Account Representative.


Synergy DBL and Visual Studio Code

By Steve Ives, Posted on October 10, 2019 at 2:52 pm

Steve Ives

Some time ago a customer posted in the Synergy/DE Ideas forum suggesting that a Synergy DBL language plug-in should be created for the increasingly popular Visual Studio Code editor. Over course of the next few months the post received a significant number of votes, and we also started hearing the same request from others.

Later we heard from the original customer that they had started to define some basic language integration themselves, offered to share that initial code, and agreed that it could be open sourced.

At this time we are pleased to announce that initial support for DBL in VS Code is live! We have developed this functionality as an open source project on GitHub (https://github.com/Synergex/vscode-synergydbl) and welcome your feedback and your contributions.

If you just want to try the extension you can search for “Synergy” in the extension marketplace inside of VS Code, or download and install the VSIX from the GitHub Releases page. If you do try the extension out, and have questions or problems, please use the GitHub Issues page to let us know.

The initial scope of the extension is fairly limited, but we have been using the colorization locally for a while now and it makes a huge difference when you just need to do a quick edit to a source file. We are looking forward to seeing what everyone else has to contribute.


Synergy/DE 11 and REV11 licensing are released

By Roger Andrews, Posted on October 1, 2019 at 2:51 pm

Avatar

We’re very pleased to announce the release of Synergy/DE 11. Version 11 delivers many features, including important security updates, exciting ISAM resilience features, and runtime performance improvements. It also includes new Synergy DBL and Visual Studio integration features. See our Synergy/DE 11 page for a full list of features.

Synergy/DE 11 also includes our new REV11 licensing, which automates your product key updates. REV11 licensing is used with Synergy/DE 11, and it also supports Synergy/DE 9.3 – 10.3 with a licensing upgrade package. See our REV11 licensing page for more information.

Many of the new features in Synergy/DE 11 were suggested on our Ideas site. We would like to thank everyone for their input, and we encourage you to continue to post, comment, and vote on that site to let us know what features are most important to you.

Be sure to review the new requirements before you upgrade to Synergy/DE 11. For example, version 11 doesn’t support Windows 7, Windows Server 2008 R2, or Visual Studio 2015.

We strongly encourage you to upgrade to Synergy/DE 11 for enhanced application security, resilience, and performance; a better developer experience; and a much easier process for managing product keys. Take a look, and let us know if you have any questions or if you need any assistance.


Enhanced CodeGen CreateFile utility

By Steve Ives, Posted on August 26, 2019 at 9:58 pm

Steve Ives

For some time CodeGen has shipped with a utility called CreateFile that (given an appropriately configured repository) could be used to create an ISAM file based on a repository FILE or STRUCTURE definition.

A customer recently asked me to create a mechanism that they could use to create multiple files, load data into those files, and also support creating both RELATIVE and ISAM files. Rather than writing something completely new I decided to extend the CreateFile utility, and that new feature has now been released along with the latest version of CodeGen (5.4.2).

Briefly, there is a new command line option -in that allows you to specify an input file containing the details of one or more files to be created and and populated. The file uses a JSON format. If you’re interested in finding out more you can find additional information in the CodeGen documentation.


CodeGen 5.4.0 Released

By Steve Ives, Posted on July 3, 2019 at 9:59 am

Steve Ives

It’s been a while since a GodeGen release was announced on this BLOG, but rest assured they have been coming thick and fast; in fact there have been 9 interim releases since we last announced here.

So why all the frenetic activity in CodeGen land? Well the primary driving force for so many releases and so many new features is to provide support for the ever evolving Harmony Core RESTful Web Services framework. If you’re not familiar with Harmony Core then you should check it out. More and more Synergy developers are starting to take advantage of it as a way to expose their applications data and business logic in whole new ways and to support a myriad of use cases.

So what’s new in CodeGen 5.4.0? Well the answer to that question is … a LOT! I won’t list all the new features here but if you want to check out the specifics then you can head over to the CodeGen Releases page where you’ll find a detailed change log for this and previous versions. And if you need more information than that then check out the CodeGen Documentation.

We recommend that all developers who are using CodeGen upgrade to this latest version, but particularly if you’re developing with Harmony Core.

Happy 4th Everyone!


Performance troubleshooting

By Phil Bratt, Posted on May 14, 2018 at 10:22 am

Avatar

In the 1984 movie classic Ghostbusters, we are introduced to Bill Murray’s character Dr. Peter Venkman, a professor of paranormal studies, testing subjects for the gift of clairvoyance—the ability to gain information about an object, person, location, or event through extrasensory perception. While it is clear Dr. Venkman does not take such things very seriously, we can see the advantage of such an ability, particularly for developers.

Stop me if you’ve heard this before: “We upgraded X and now Y is happening.” In this case, Y is usually associated with a negative behavior like slow performance, a slew of errors, or a bad user experience. Events like these may induce weariness, nausea, dry mouth, and other various side effects that are usually listed in American pharmaceutical commercials. In summary, they’re unpleasant. If only there were some means to predict these events and avoid them in the future…

Unfortunately, most developers are not gifted with the power of clairvoyance to anticipate problems with upgrades before they happen. But maybe instead of a crystal ball, there are tools that can help us avoid upgrade failure. Let’s look at some things that can help anticipate and/or prevent such issues from happening.

A relatively recent addition to the Synergy documentation is the Configuring for performance and resiliency topic in the Installation Configuration Guide. This topic discusses things that one should take into consideration when running Synergy on any system, and it’s based on years of experience from the Synergex Development staff and the results of their testing. If you haven’t read this section yet, I highly recommend doing so. If you’ve already read it, I recommend a quick refresher the next time you’re looking at major system or software changes.

In Support, we often see issues when developers virtualize systems that run Synergy or when data is migrated and then accessed across a network rather than being stored locally. Both scenarios are discussed in this topic. And as part of Synergy’s web-based documentation set, it’s updated regularly with the latest information. Make sure you take a look before any major upgrade in case there are changes.

Other useful tools for avoiding problems are the Synergex Blog, the Synergy migration guides, KnowledgeBase articles like Guideline for debugging performance issues, and the release notes that come with each version of Synergy. Remember that even if you are just changing the operating system and/or hardware and not your version of Synergy, you should re-review these materials. Some of the considerations they outline may now be relevant, even if they didn’t affect you previously. Also, when testing, remember to take load testing or a process running over time into account. We commonly see pitfalls  when developers neglect these two factors in testing.

Taking Action

Now let’s say that despite your excellent planning, you do see a performance issue. What can you do? Here are some steps I’ve found helpful that might get overlooked. Most have to do with simply eliminating factors that affect performance.

  • Establish a baseline

If you’re going to diagnose a problem in performance, the first thing to do is isolate code or create a piece of code that demonstrates the problem. Make this your baseline test for all of the various configurations you’re going to test. This will make your tests consistent as well as eliminate code changes as a factor.

  • Use a metric

Establish a program you’re going to use to measure the difference in performance. If you’re using a traditional Synergy program as your baseline, you can use the Synergy DBL Profiler, which will count CPU time for you. Just make sure you pick the same metric for your testing—CPU time is not the same as real time. This step will enable you to get measurable results to test what is actually making a difference.

  • One by one, test all the things

I’ve found that the easiest way to plan and visualize testing is to make a tree. Each layer is one aspect you’re testing that continues to branch with every different aspect. For example, I had a situation where a production machine migrated Synergy version, operating system, and hardware and virtualized the OS, all in one move. We picked one thing to change (the virtualization of the OS) and tested it.

VirtualizedNon-Virtualized

 

By doing this, we established that virtualization was a factor, because a virtualized environment was slower than a non-virtualized one. We then compared those to the old and new Windows versions, but continued with virtualized and non-virtualized environments using the same virtualization software.

Windows 8Windows 10
VirtualizedNon-VirtualizedVirtualizedNon-Virtualized
In previous tableIn previous table

 

On average, this produced the same result. (It was I/O processing, so we did an average of 10-20 runs based on how volatile the results could be.) Next, we compared the Synergy 10 runtime with the Synergy 9 one.

Windows 8Windows 10
VirtualizedNon-VirtualizedVirtualizedNon-Virtualized
Syn 9Syn 10Syn9Syn 10Syn 9Syn10Syn 9Syn 10
In previousIn previousIn previousIn previous

 

The tree continued growing until all of the factors were considered and tested.

Closing Thoughts

It can be tedious to test one change at a time, but without that kind of granularity, you can’t establish which change affected performance and by how much. In the example I mentioned above, we established that virtualizing the hardware was causing a problem because of the way the virtual machine software emulated separate cores. We never would have come to such a conclusion without carefully eliminating the many different changes one at a time.

After you’re able to establish exactly which changes caused the performance issue(s) and by how much, you can work on a fix or provide a solid case to whichever software support representative you need to contact to get a fix.

You might know most of this already. You might even know of some methods, tips, etc., for performance issues that I didn’t discuss. Maybe you are clairvoyant and you already knew the contents of this post before I did. Either way, I hope you find this information helpful when you look at performance in the future, in both preventative measures and problem diagnosis.


Don't miss a post!

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Recent Posts Categories Tag Cloud Archives