Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 5 of 5 total |
Server hardware specs |
Tue, Sep 22 2015 8:16 PM | Permanent Link |
Colin Wood VirtualTec P/L | Hi all,
I found a thread ( http://www.elevatesoft.com/forums?action=view&category=dbisam&id=dbisam_cs&msg=7569&start=1&keywords=server%20specifications&searchbody=True&forum=DBISAM_General&forum=DBISAM_CS#7569 ) which mentions minimum hardware specs but it was written in 2010 and technology has obviously changed since then. My client (a large hospital) has asked me for minimum specs for a new server which they will install since their current servers are heavily loaded and my database application is highlighting a number of bottleneck problems. The application records info about equipment and maintenance service frequencies, the main data entry volume would be created by around 6 concurrent users. I'm running the DBISAM database in local mode which has been fine for most of my other clients, but I am contemplating separating some aspects of the application and making them c/s. Any suggestions would be welcomed. Colin |
Wed, Sep 23 2015 3:28 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Colin
The hardware may have changed a lot since 2010 but DBISAM hasn't. There have been improvements but its still pretty much the same engine so the advice <<3-5 user C/S setup almost any hardware should run just fine (possibly even a desktop system you have laying around).>> is still going to be OK. What's more likely to have changed is data volumes if your application has been collecting data for a long time and using DBISAM in f/s mode could well bottleneck the network. If you're currently using mainly table access rather than queries you'll not see much in the way of benefit from moving to c/s, especially if your app is "chatty" (at least that's what my testing using ElevateDB showed). Before you start to extensively modify your application its probably worth looking at the network traffic and trying to work out where most of it comes from. Roy Lambert |
Wed, Sep 23 2015 8:33 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Colin,
<< My client (a large hospital) has asked me for minimum specs for a new server which they will install since their current servers are heavily loaded and my database application is highlighting a number of bottleneck problems. >> Do you know *where* the performance problems reside ? IOW, are they network-related, disk-related, etc. ? That will help determine how much moving to C/S would help. Going to C/S will primarily help with network I/O: things like queries will no longer have to ship over entire portions of the .dat, .idx, and .blb files in order to allow the client application to execute the query. If a network is already saturated, then this could result in a very large increase in performance. But, as Roy indicates, there can be issues with "chattiness" if your application tries to do a lot of while not EOF do....next type of batch processing over a large number of records. In such cases, your application performance can suffer (the underlying network won't suffer or be saturated) due to the aggregate amount of latency in all of the request/response calls to/from the DBISAM Database Server. However, there are ways to mitigate this in DBISAM, namely this property: http://www.elevatesoft.com/manual?action=viewprop&id=dbisam4&product=rsdelphi&version=XE&comp=TDBISAMDataSet&prop=RemoteReadSize You would just set this at the top of a loop, and then instead of thousands of "next record" calls, there will only be X div RemoteReadSize number of next calls. Tim Young Elevate Software www.elevatesoft.com |
Wed, Sep 23 2015 7:20 PM | Permanent Link |
Colin Wood VirtualTec P/L | Roy & Tim
Thanks for your advice. I will have the IT guys do a bit of analysis to see where the problems are as per your suggestions. With the mention of using RemoteReadSize, which is something that I hadn’t come across before, searching the forum using that as a key word has bought up a whole lot of other topics that have been very helpful. Thanks again. Colin |
Thu, Sep 24 2015 11:49 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Colin,
<< With the mention of using RemoteReadSize, which is something that I hadn’t come across before, searching the forum using that as a key word has bought up a whole lot of other topics that have been very helpful. Thanks again. >> I forgot to mention: you can also move batch processing code directly into the DBISAM Database Server via server-side procedures, but that's a little more involved and requires re-compiling the server. Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Thursday, March 28, 2024 at 06:05 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |