It’s been some time since I posted. We’ve been busy with our 9.1.3 release, which has some great new .NET interop features and more flexible xfNetLink .NET client capabilities. I’ve also had some international travel.
Windows Server 2008 and Windows Vista SP1 have now shipped. (9.1.3 was tested with both). Both use an identical code base and identical DLL and kernel versions – which is great for maintainability.
Unfortunately it appears that these operating systems are 40% slower at file write operations than Server 2003. This means that writing out a log file or update/insert/delete operations to Synergy databases is therefore 40% slower than Server 2003. This can only be seen when using large files because the average commercial application does small blocks of random I/O. One of our customers provided a Synergy test program and a C# .NET test program that showed significant differences in time taken. We looked into the differences and re-coded the C# program to use the same WriteFile() win32 API that the Synergy Runtime uses, and the C# program also shows the same degradation that the Synergy Runtime shows. The issue has been logged with Microsoft support to get a resolution.
Why does this matter? Well, several things are affected on a large file server:
- Throughput as the number of users increases
- Time taken to write large log files
- Time taken to create work files and rebuild Synergy DBMS databases
- Time taken to sort files
At this time I would recommend not moving to the new servers until Microsoft has had time to fix the performance degradation.
Now you might ask why the initial C# program ran faster. Synergy/DE has never buffered files opened with “O:S” mode, because on VMS we can’t (each record is a separate RMS record) and on Unix and prior Windows operating systems, buffering has had minimal if any performance gain – that was the job of the operating system. It turns out the newer Windows operating systems have significant overhead, so we will look into some buffering for a future release for both the runtime and the compiler. (The linker and librarian and isutl all perform large block I/O).
As applications move forward, they support only newer versions of third-party software and remove support for older versions. It’s not really surprising; it’s all to do with QA and being able to take advantage of newer functionality.
There is one area in particular of the Synergy/DE toolset that is constantly moving forward to support newer 3rd party tools, with extended functionality and in some cases bug fixes – and that’s xfODBC. With the newer technologies like ADO.NET and new client tools that use it, we had to enhance many parts of the whole stack to support ADO .NET properly. This means that if you try to use years old versions of Synergy/DE with current 3rd party tools, it most likely won’t work, or at the very least performance won’t be great. If you expect current technologies such as SQL Server reporting tools, Visual Studio 2008, or Office 2007 (Excel) to work with xfODBC, you/your customers really must be using the latest versions of Synergy/DE. Synergex is really no different than Oracle or SQLServer in this regard. We make constant improvements to our optimizer, just like the other database vendors – and these changes can provide dramatic improvements in ad hoc query performance with Synergy databases.
Vista support is another area that requires you to stay current. Just like most 3rd party software was enhanced to work with Windows Vista, so was Synergy/DE. We had significant work to do to ensure we worked well with Vista and its whole UAC mechanism and to ensure both install and uninstall worked well. I don’t really understand why someone would try to run an older 8.3.1 or 8.1.7e version of Synergy on this newer platform – I understand that there is testing to do with application compatibility, but now that Service PAK 1 is ready to roll, businesses will start to move over more quickly. Our customers have been successful using 9.1.1b as the deployment platform for Server and Vista, with the clients and the .dbr files still using 8.3.1. Any fixes required to allow 8.3.1/9.1.1 co-existence can be made to be compatible with both while compiling under 8.3.1; however, unless there are bugs in original code, this is extremely rare.
In conclusion, if a company (or an ISV’S customers) wants to keep current with newer, rapidly changing technology, the base technology (Visual Studio, Synergy/DE) must be current as well.