Hi Rick,

We have a server with a heavy load of requests (30+ per second) which take approx. 0.7s to complete in average. In peak times that leads to many requests that fail to run on time. For some reason some of them are just left behind by the ISAPI controller. What I figure out as a root cause is the way the WWWC service picks up the requests. It uses SYS(2000) which gets the first TMP file in the folder sorted alphabetically. Is there a way we can change the way TMP files are being named to ensure FIFO method being used?

Dimitar Hristov

Dimitar,

It's been a long time since I had the wonderful opportunity to work with WebConnect, but we used file based mode and I had a 'farm' of two machines pointing at the folder on a server that had the request files and where, I believe, the return file would go. With a 'farm' of file based machines you might get better throughput. And keep in mind that you can have at least one web connection file based instance running on each farm machine. And when there was an error in an instance the error handler can do it's thing and then launch another fresh instance of itself.

That said, maybe Rick can speak of using COM as a better methodology.

If you're using a reasonably recent version of Web Connection you should have no left over files - WWWC cleans up expired files on regular background loops.

Also you probably should be running the .NET Module rather than ISAPI if at all possible which includes many enhancements to the overall processing pipeline.

Finally if you're running a high volume site you really should not be running in File based mode, but use COM instead. There are no files in COM mode and throughput tends to be significantly faster. The problem with file mode is that the Windows OS has problems with large numbers of files in a folder and then lookup gettings slow. Even a few hundred files in a folder can signficantly slow down a simple directory look up where the lookup takes longer than your entire rest of the request.

+++ Rick ---

I'm using WWWC for more than 10 years for different companies. I would say VFP would never die with a product like this. It just rocks!

I have used it in COM mode in the past (plus the ability to switch between COM and File based mode) but right now COM is not an option - no EXE can be build (don't ask why). So only option we have is File based mode.

Also we use 10 separate servers but due to limitation of the product that we try to overcome we still can't do web-farming the way it should be done. We plan to do it until end of the year. So fingers crossed...

But in the mean time I would like to focus on the ability to have a FIFO method implemented for picking up requests. Its not done this way because :

• usage of SYS(2000)
• randomized file names created for each request received

I want to keep the speed while maintaining FIFO method as it is essential in peek times. Any ideas how to implement it?

Dimitar

So first there won't be any changes to the ISAPI handler. That is done and will not see any more updates save security fixes... Any changes and improvements going forward are only made in the .NET Module.

As to the load issues - file based mode was never intended to handle large loads - it's intended to be used as a development time engine so if you are running in a very high volume environment, you're really using it beyond the scope for which it was designed in the first place. The file issue is normally addressed by using COM mode which is the proper way to run an application in production.

The use of SYS(2000) is the most efficient way to retrieve a file name in Windows (ie it maps to the FindFileFirstEx() Win32 API) without getting a full directory listing. All other mechanisms require full directory look ups. The unique ids generated for the request IDs have to be unique due to the multi-threaded nature and that's why they are using hashed Guid Values which are random.

After some more thought I can probably generate sortable ids using some updated code:

// Generate a new RequestId            
//RequestId = Thread.CurrentThread.ManagedThreadId + "_" +
//            Guid.NewGuid().GetHashCode().ToString("x");

Interlocked.Increment(ref RequestIdIncrementer);
RequestId = DateTime.Now.Ticks.ToString().Substring(7) +
            RequestIdIncrementer +
            "_" + Thread.CurrentThread.ManagedThreadId;

The new ID uses the changing part of timer ticks plus a static increment counter that's incremented per request, plus the thread id which should still produce a unique ID, but that is sequenced.

One downside is that the ID length is a bit longer and it'll probably require some additional changes in the log tables.

This will get addressed only in the .NET Module...

+++ Rick ---

We are using the .NET module of v5.62 and if we could have an update as the suggested approach that would be more than awesome!

Dimitar

I won't be updating version 5.x. The only versions that will see updates are the latest versions (v7.x).

+++ Rick ---

Thanks Rick,

We can probably upgrade to 7.x then. When can we expect the patch fix for this update?

Kind Regards Dimitar

It's already in version 7.08.

+++ Rick ---