I meant to reply to this a while back :(, sorry...
It's not FoxWeb related, I've determined this much. No new files are added to the server, it's a mass copy in the other direction. However, the mass copy may be causing some weird page file behavior or buffer issue? There is a RAID configuration that stores tables in memory and it may be taking some time to rebuild all this perhaps? In any case, stand alone Foxpro itself becomes sluggish (although other static web services don't seem to be affected, which is strange) so it's not a FoxWeb issue.
New server in the works with triple the memory... :) Thank you for you response.
Sent by FoxWeb Support on 12/22/2014 02:29:55 PM:
Have you tried restarting FoxWeb immediately after the backup? Do you still get sluggish operations? If yes, then something is happening on your server for a few minutes after the backup. This should not be specific to FoxWeb. I bet that VFP would also be slow in accessing data during that period.
Does the affected system receive new files as a result of the backup operation, or is it the backup source? If new files are added to the server, you may want to check whether certain processes are slowing your system down as a result of these files (Windows Indexing service, or other processes that have to account for the new files).
FoxWeb Support Team
Sent by Steve Moore on 12/22/2014 11:28:02 AM:
I have a Foxweb installation that has been running for almost 15 years. It is a fairly large installation that manages literally hundreds of thousands of files. The site gets 100,000+ requests a day. Many of the routines manipulate dozens or even hundreds of databases and index files in a single request.
Every night the system performs a file by file backup, copying hundreds of thousands of files from one server to another. This takes about 15 minutes. During this time the Foxweb scripts themselves return a maintenance message and do not attempt to access the files being copied.
Immediately after finishing the backup, Foxweb becomes extremely sluggish. Scripts that normally take less than a second to complete eventually timeout even with a longer timeout period such as 60 seconds. Eventually after the timeout Foxweb will kill the channels and restart them. There are no errors returned. This goes on for approximately 5 minutes and a couple of hundred requests, after which everything returns to normal and Foxweb requests resume normally performance, executing in fractions of a second.
The exact same requests that timeout immediately after the backup run normally and there are no further problems until the following evening after the next backup. There are no errors or warning messages reported in Foxweb or in the server logs that I can find.
The problem seems to be isolated to Foxweb as other web server functions do not seem to be degraded.
I have experimented with any number of processes to try and determine what is causing the issue. I've tried stopping and restarting the service, pausing for some time after the backup completes before resuming FoxWeb processing, and other off-the-wall methods, but I've been unable to find a workaround. The only thing I can come up with is that the process of copying that many files is messing with server buffers and/or page files?
Anyone have any ideas?
Thanks in advance for any help. Have a Merry Christmas and a happy new year.