There is not much we can do in FoxWeb about the problem you describe. It seems that there is a memory leak in either VFP or in one of the 3rd party controls you are using. Running a FoxWeb script is no different than calling a procedure from a main VFP program every few seconds. Once the procedure ends, all non-public memory variables (including objects) that were declared in it are supposed to be released. Apparently one of your objects does not get totally released. Does the slow-down only occur when you call scripts that use this particular control, or does it even occur when you call simple scripts, such as show_sgi?
By the way, we just added another possible value to FW_Restart in the version that will be released later this month: If you set the variable to 2, the whole channel (the VFP process) will exit after the current request. This should definitely clear all accumulated garbage. If Restart Channels is enabled, then the channel will get re-started immediately.
Sent by Oleg Goncharuk on 12/03/2001 01:17:55 AM:
Thank you for the tip about FW_Restart variable, it helped us a lot.
But it had not solved the problem completelty.
Here an URL
http://www3.techsell.ru/velodrom of a site running under FoxWeb. Loading speed of first page of this site is monitored by separate Perl program. Here are results for about 24 hours (Sunday and Monday night)
http://www3.techsell.ru/velodrom/statistic.jpgLone peaks are daily backaups. Increase of speed at about 11 a.m. on Monday - is manual restart of Foxweb
Channels where cleared after 100 runs or after SYS(1016) rised to 1500000 using FW_Restart=1 in FW_exit program.
Here is part of log of "restarts", corresponding picture above:
2001.12.02 02:02 Channel: 1 Occupied: 1501040 LoadCount 44
2001.12.02 03:30 Channel: 1 Occupied: 1513784 LoadCount 37
2001.12.02 06:06 Channel: 1 Occupied: 1517024 LoadCount 44
2001.12.02 08:40 Channel: 1 Occupied: 1506508 LoadCount 46
2001.12.02 12:05 Channel: 1 Occupied: 1508956 LoadCount 50
2001.12.02 14:15 Channel: 1 Occupied: 1515496 LoadCount 41
2001.12.02 15:20 Channel: 1 Occupied: 1533028 LoadCount 33
2001.12.02 16:03 Channel: 1 Occupied: 1526864 LoadCount 29
2001.12.02 18:45 Channel: 1 Occupied: 1505348 LoadCount 54
2001.12.02 20:05 Channel: 1 Occupied: 1510148 LoadCount 42
2001.12.02 21:50 Channel: 1 Occupied: 1511828 LoadCount 42
2001.12.03 00:10 Channel: 1 Occupied: 1515596 LoadCount 47
2001.12.03 01:30 Channel: 1 Occupied: 1516672 LoadCount 34
2001.12.03 04:15 Channel: 1 Occupied: 1507984 LoadCount 39
2001.12.03 06:30 Channel: 1 Occupied: 1500256 LoadCount 40
2001.12.03 08:10 Channel: 1 Occupied: 1509124 LoadCount 68
2001.12.03 08:43 Channel: 1 Occupied: 1578700 LoadCount 35
Qusestion: Could there be some other means to prevent gradual decrease of FoxWeb speed?
Sent by FoxWeb Support on 11/29/2001 06:15:06 PM:
Oleg,
You seem to be referring to a different problem. Dan's problem was that he could not modify a FoxPro class once it was used by FoxWeb until FoxWeb was restarted. The solution to this problem is to make sure that:
1. The object is released (RELEASE OBJECT ObjectName).
2. The procedure containing the class is not locked (SET PROCEDURE TO).
3. The class is released (CLEAR CLASS ClassName).
Your particular problem seems to be related to a bug in either VFP or the XML control, which prevents resources from being cleared after DOMDocument objects are released. One thing you can try is to set the variable FW_Restart to 1 in your script if you detect a problem. This variable is normally used by the FoxWeb error handler and will cause the channel to be reset (but not restarted), after the request is finished executing. The channel reset code executes the following commands and re-creates all internal FoxWeb objects:
CLEAR DLLS
SET PROCEDURE TO
SET LIBRARY TO
CLEAR ALL
CLOSE ALL
CLEAR PROGRAM
This should work in most cases. If the VFP process must actually exit in order to completely clear the resources held by previously declared DOMDocument objects then the only way to achieve this is to include the QUIT command in your script. If Restart Channels is enabled, the channel will be restarted immediately by the channel broker. The only problem is that the request being served when the QUIT command took place will never complete.
FoxWeb Support Team
support@foxweb.com
Sent by Oleg Goncharuk on 11/29/2001 06:19:16 AM:
I had encountered exactly the same problem and CLEAR CLASS does not save the situation.
When running script containing multiple creation of MSXML2.DOMDocument objects response time of channel increases from 1000 msec to 8000 msec after 16 hours of testing (CLEAR CLASS used in FW_EXIT and all class instances assigned to local variables within script). VFP function SYS(1016) in FW_EXIT returns 470000 at the start of testing and 2800000 at the end.
Question:
Is it possible to restart current channel programmatically after returning response to caller when some condition is met? I believe, that would increase perfomance greatly.
Also: When we are running 3 channels and server load is low (at night) Foxweb almost always presents rare callers with first channel (filled with garbage) when two others (empty) are asleep. Maybe it would be better to present each call with channel that was long unused?
/Oleg
Sent by FoxWeb Support on 11/27/2001 03:55:43 PM:
Classes are not released after being instanciated, unless you issue a CLEAR CLASS command:
CLEAR CLASS ClassName
If you are instanciating a PUBLIC object in fw_enter.prg, you will need to destroy the object before clearing the class:
SET PROCEDURE TO
RELEASE ObjectName
CLEAR CLASS ClassName
Alternatively, if you only modify your user defined clases rarely, you can re-start FoxWeb whenever you want to recompile.
FoxWeb Support Team
support@foxweb.com
Sent by Dan Mory on 11/27/2001 02:26:13 PM:
I am using the Microsoft XML parser to process XML requests in a Foxweb 2.0 script. I am assigning the instance of the COM object to a property of a user-defined class using CREATEOBJECT("MSXML2.DOMDocument"). The class that contains the COM object is instantiated in the body of the script. This appears to work fine, but it seems that the object is not getting released after the script is run, because when I recompile the script, it gives a "cannot create file" message because the .fxp file is still open. Is there additional housekeeping that needs to be done in such a case? Is there a better way to accomplish the same results?
