Associated Data Developments Ltd.Home | Database & Software | Website design | eCommerce | Web Servers | Web Services | Internet Apps | Broadband | Technologies | Site map | Links | Contact us
Load/speed testing VFP to Internet Options
In order to compare various ways of connecting VFP to the Internet we created a number of very simple 'Helloworld' applications; it simply adds one to a counter in table and displays this counter along with the current date and time in a Web page.
For these tests the Web Server software is running on a Win2k Server (1.4Ghz Athlon). This is connected to an NT4 workstation (450Mhz AMD) which is running Microsoft 'WAS' stress testing tool. Neither machine is particularly carefully configured, both have hade their operating systems installed and in use for a couple of years, about the only comprimise to performance that has been made is that both machines have their antivirus services turned off.
We tested both the VFP 8 version and the older VFP6 version but found virtually no difference between the two, unfortunately both seemed equally unstable.
FoxISAPI - Pooled executable
For the first test we built an (out of process) executable and pooled various instances of this using the FoxISAPI, the number of pooled objects was varied but made very little difference. The number of hits achieved varied from 25 per second to a maximum of 50 hits per second but we have no idea what made the results this variable apart form the direction of the prevailing wind.
FoxISAPI - Non-pooled Multithreaded dll
For the next FoxISAPI test we built the app as a multithreaded dll (single use), this produced much better results averaging around 140 hits per second with the server at 95% cpu and the client at 50% cpu. However, when pushed hard for an extended period of time this locked-up IIS which then consumed 100% cpu for ten minutes before clearing itself, it also did not serve any further hits during this time.
Bear in mind that here we are simply using ASP as a vehicle to call our COM object, we are not actually asking ASP to run any code although we do pass the ASP Request and Response objects to our COM object because they exist anyway and cannot be turned off. All other go-faster ASP options (sessions etc) were turned off.
ASP instantiate object each hit
Our first test was a Multithreaded dll (single use) which was created using ASP's Createobject() on each page hit. Our Helloworld() method was then referenced in this object, this returned a surprisingly respectable 30 hits per second and was reliable too.
ASP instantiate object once only
We then moved the instantiation of the COM object out to the application level by putting an <Object> tag in the Global.asa and referencing it's Helloworld() method on each hit without recreating the object each time. Here is where the real surprise came in; this method returned an average of 250 hits per second with the client maxed out at 100% cpu and the server at 70%. Therefore if the client had been a bit more beefy it could have reached a theoretical maximum of 360 hits per second.
Thanks to Claude Fuchs for pointing out one quite important drawback:
Bespoke Web Server
The final test was avoiding IIS completely by using our own Web Server; this is written mainly in VFP with calls out to a few C routines. Not surprisingly this maxed out the client cpu 100% again and returned 390 hits per second with the server running at 50%. Again assuming a faster client this gives us a theroretical maximum of 780 hits per second.
This ISAPI is certainly more stable than the basic FoxISAPI. We didn't bother speed testing in file mode but went straight for COM mode. The result were very dependent upon how many instances were running, with only one instance it returned 150 hits per second while two instances increased this to 225 hits per second while the server was running at 90% cpu and the client at 80%. We saw a maximum of 250 hits per second when running twenty instances of the server.
Active FoxPro Pages
Took a bit more to get runing than some of the other methods but that might be because I have not used AFP before and don't really unsderstand it's architecture. The first test we did was with just one 'Isolated AFP Engine' this returned 45 hits per second with the client at 20% and the server at 70%. Next we tried using one instance of AFP's multithreaded engine this returned only slightly better at 50 hits per second. We then started testing various numbers of instances of both the Isolated Engine and the multithreaded engine (not much speed difference between them). We did achieve a maximum of 65 hits per second but couldn't be sure how many threads were running when we got that result and, unfortunately, couldn't repeat the same again.
Draw your own but it looks to me like ASP calling a COM object instantiated from a Global.asa is surprisingly efficient and perfectly adequate for many purposes.