Phone800.366.3472 SupportGet Support DocumentationDocumentation Resource CenterResource Center
Open Menu

Synergex Blog

Moving to Windows Server 2008, Windows Vista SP1

By Roger Andrews, Posted on April 16, 2008 at 8:50 pm

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:

  1. Throughput as the number of users increases
  2. Time taken to write large log files
  3. Time taken to create work files and rebuild Synergy DBMS databases
  4. 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).

Leave a Reply

Your email address will not be published.


Recent Posts Categories Tag Cloud Archives