Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Who really uses the VFPOleDB.1 provider?
Message
From
04/10/2006 03:09:43
Thomas Ganss (Online)
Main Trend
Frankfurt, Germany
 
 
To
04/10/2006 01:09:42
General information
Forum:
ASP.NET
Category:
Databases
Environment versions
Environment:
VB 8.0
OS:
Windows XP SP2
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01158763
Message ID:
01159235
Views:
28
>>YOur situation (complex read queries) might be one of them - for instance if many OLEDB queries are running on dbf-file-data cached in many gigabytes of RAM running on multiple CPU's. Asking about your HW is a roundabout way to get an estimate for my mental picture...
>
>We have a 3.2 GHZ dual core double CPU with 2 GIG of RAM. This is a brand new server. It has been installed on Friday. This machine is extremely fast.

ENVY....

>We will have about 200000 hits a day for the first 3 to 4 months and up to one million when we will reach the first year.
We expect to add a new server in a three month interval for a certain period. I wasn't planning to move to SQL Server yet. But, I may be forced to move asap because of the situation we are facing now.

ASSUMING (Hint: verify with MS) Express licensing is per *cpu* and not *core*, I'ld guess you have nothing to worry about for the first year. As this new machine is relatively RAM starved (512 MB per core) anyhow, giving the maximum weight to Express by splitting between Express (2 cores and 1 GB) and other tasks IIS/ASP.net will probably give enough power to Express.

As you plan to add other HW, adding a quad core data server should give you about 80% more CPU-bound processing power if you are cpu-bottlenecked. The main question probably is if 1 Gig of RAM for Express is enough to serve all queries. As long as the data is clearly less than that (leaving some RAM for Express itself and temp data) and you only run simple filtered selects or inner joins it should be no problem. If the data is larger than 1 GB and since the example you showed is heavily joined, as long as the relevant index data is kept in RAM, performance will probably be adequate. Hitting the disk before the last small step is the thing to avoid.

If I remember Rick's statistics from a few years ago correctly, he ran similar amount of hits against much weaker HW also on SQL server. But perhaps his queries were simpler.

regards

thomas
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform