Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VFP9: Heavy traffic/transaction

Status
Not open for further replies.

Kurtwood

Programmer
Sep 7, 2002
39
BS
A potential client wishes an app to handle 50,000 transactions in 30 minutes with 20 remote users/sessions using TS over broadband.

If all is well with the server, communications, etc, can VFP9 handle this amount of transactions and the short time? The program has not performed well in Access and SQL server is not desired because of the cost.

Data integrity is a must in that short time-frame.

Any thoughts would be appreciated.


Kurtwood L Greene
The Bahamas
 
Not a thing. I ran it first on my P3 900MHz ThinkPad and got even worse results. Both machines have VFP 9 SP1.
 
yert33,

There are a lot of determining factors for this (CPU speed, Cache size, HD speed, Bus speed, amount of RAM, speed of RAM, PC load, etc.... too many to list). Running this code on a P4 (3.06 Ghz) laptop with 1 GB of Ram (set talk off, set status bar off, set development off, other windows like datasession closed, etc.) I get 26+ million for non-buffered, and around 17 million for buffered. So, given the few machine specs you've given, I'd say it's probably right.

I have yet to see a VFP application that requires 833+ transactions a second so I think even your 1.5 million would be viewed by most users as more than fast enough.

I'd like to see the benchmarks for a .NET application using ADO.NET attempting the same thing for an SQL Server backend. I think it would be interesting to compare the two.

boyd.gif

SweetPotato Software Website
My Blog
 

Mike Yearwood,

Did you try with SET TALK OFF and SET STATUS BAR OFF?

I got slightly better results with
SET TALK OFF and SET STATUS BAR ON
than with
SET TALK OFF and SET STATUS BAR OFF.
 
You got it, Mr. Boyd: what would be meaningful is a comparison against other systems. I would like to nominate the LAMP stack for comparison, if that makes sense.
As for Access, is it a given that VFP would cream Access in a shootout?

 
Woo! On an AMD Athlon64 3700+ (~2.2Ghz) with 1Gb RAM, nothing else running, TALK OFF, STATUS BAR ON:

Unbuffered: 64.9Million in 30mins.
Buffered: 39.1Million in 30mins.

I'm really happy with my choice of AMD over Intel..
<<happy dance>>

-- frank~

PS.- With TALK ON, STATUS BAR ON:
Unbuffered: 21.48Million in 30mins.
Buffered: 17.18Million in 30mins.
 
Hmm, is all this benchmarking realistic?

20 remote "users" or processes accessing the same database should make it much slower. Citrix or not. I'd also test in a small network with at least 2 clients and the file server.

On what experience are these 50,000 transactions based? Or is that only an assumption? In any normal application you also have times whith access peaks and normally no transactions over night. So I'd ask the customer for much more figures, eg minimum, maximum and average transactions per minute and standard deviation. And the same figures for the size of those transactions. Transactions can be very small or change vast amounts of data.

If there is much time with few transaction per time interval you can queue requests and thereby cut off the need to guarantee peak performance. The same goes for small and big transactions.

Last not least if reliability of the database is important you need to at least have decent logging of data changes, better yet replication to a mirror database, that could replace the database in case of failures. And if security is important then it may make even more sense to use an sql server.

Bye, Olaf.
 

Olaf,

Hmm, is all this benchmarking realistic?

No. But then again, it's not meant to be benchmarking. Kurtwood's original question was whether VFP could handle his required hit rate of 50,000 transactions in 30 minutes. There's no way that this test can confirm or deny that, but it does at least put it into perspective.

Also, it's worth knowing about the the differences with TALK and STATUS BAR off. These aren't related to the original question, but are sure to be of interest to some developers.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk
 
Hi Mikes,

Mike Lewis said:
There's no way that this test can confirm or deny that, but it does at least put it into perspective.

I even doubt that. Although creating Millions of records within 30 minutes compared to the needed 50,000 transactions in that time period seems to be overwhelmingly, it's too early to say that this will fit the needs.

I would be shocked that people would attempt such a thing with SET TALK ON.

Yepp, although it's only a short text displayed at the statusbar per added record or recordpointer movement and several other events: It's windows, a graphical OS, so it's not simply copying some bytes to DOS screen memory - one for each character - it's drawing text characters from a font, nowadays normally 3 byte RGB color information per pixel, even if it's only black on gray...

That is so much nonsense overhead, as you can't follow all the stuff that is written to the status bar, that it's really hard to understand why someone does not turn this off for tweaking performance.

YEPP!

Bye, Olaf.
 
Hi All,

Just my penny worth, I found the code (with status bar and talk off) indicated that about 62 mln transactions of this type were possible in 30 minutes in VFP9 (on a 3.2 GHz machine with 1 GB or RAM) if you extended the test time to 60 seconds.

This is on a table with no index files, if you create three indexes (I just used the first three fields concatenated, then the second three and the last three) the transaction count over a one minute suggests that 52mln could be completed in 30 minutes.

If you change the replace transaction to an append blank and replace in each case you get the following predictions based on a 60 sec test sample:

Without indexes 23.8 mln
With indexes 5.6 mln

That still augurs pretty well for a real world application!



Regards

Griff
Keep [Smile]ing
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top