May be you should check for HW errors. I would run tests on the HD to check any i/o errors.
Michael Cook wrote: > Thanks for that input. I'm beginning to feel that there is something terribly wrong >with the W2K box that Sambar is sitting on. When I run STM scripts that return >database queries, things have been slowing down about ten fold over the last few >weeks. Here is my set up: > > Sambar 5.1 March 31 build (w/registered pro key) > Windows 2000 Professional w/SP2 > Dell Poweredge SCSI drives, 130 Megs RAM > > I have a 300 row DBF table that takes nearly 30 seconds to load into the browser, >even if done on the server using localhost. > > Oddly, CGI database stuff works without any problems. > > I then installed the same version/build of Sambar on a lowly P90 with 80 megs RAM. >The same DBF table loads within a few seconds. > > Here is an entry in the dbconfig.ini: > > [test] > Description = > Datasource = test > Username = admin > Password = > Maximum Column Length = 8192 > Maximum Used Connections = 5 > Minimum Free Connections = 1 > Maximum Idle Period = 10 > Single Thread = true > Trace SQL = false > Trace Performance = true > > I've ruled out the Network and Sambar as the problem, and I am now focusing on a W2K >problem. I'm still scratching my head as to why things are slowing down on the W2K >box (and yes I've re-started and re-booted several times). > > I'm about to re-install everything on the Dell box, including a clean re-install of >Windows. If anyone has any ideas for troubleshooting a W2K problem that may be >causing this slowing database behavior through STM scripts, I would appreciate >hearing form you. > > Thanks. > > >>> [EMAIL PROTECTED] 07/16/02 11:30PM >>> > I wouldn't rule out any sambar scripting.. Scripting is scripting in my book.. All >preference to which is easiest for you to operate in and which one has the features >that you are needing.. Mind you that php / mysql has a bit more control and >manipulation of data / table design but for the everyday application, any REAL SQL >server will be difficult to notice a difference unless your processing millions of >records. > > Here are some examples of very different usages of Sambar using scripting, dbms, >and basic odbc connections.. > 1) sambar hooked to access hooked to excel spreadsheet sitting on a novell file >server. Actually performs pretty fast.. Of course you can tell there is a bit of lag >between access and the spreadsheet as the novell box is hooked via NW Gateway >services over IPX. One of those read only jobs on this one. It works and under 1sec >response time. > 2) sambar hooked to access hooked to access database sitting on another microsoft >server.. This runs pretty good but on large queries you can feel a delay as the real >data is still having to pass over the network. > 3) sambar hooked to access on the same machine.. This smokes.. and all around >performs great.. Since everything is local to the machine, you won't notice much >slowdown from the servers perspective up to around 100,000 records or so, assuming >you write your queries properly, index and key everything. > 4) sambar hooked to SQL server.. Well I shouldn't brag too much on this box because >the server itself makes the difference with this guy.. Having 2gigs of memory on >board with 4gigs of CPU cache on 2 zeon processors kinda helps... Needless to say.. I >can't make this thing slowdown. For 500,000 records I think its a waste of money. > 5) sambar hooked to mysql on a really crappy processor.. Honestly, I think mysql >would outrun SQL server given that they were on the same box.. mysql smokes and is an >awesome true SQL server, php or no php.. I would only recommend using >dbtools(www.dbtools.com.br) to manage it.. Really take the headaces out of desiging >your tables and security.. Looking at MS SQL Enterprise manager, this dbtools team >must have worked for MS sometime :) > > All of these items are using basic sambar scripting with dbms / odbc and personally >with the traffic I see I couldn't image needing to jump to leaps and bounds to get >off of any of them. They all perform plenty fast enough for the bandwidth that they >are demanded to serve. As for my overall suggestion, I recommend taking the easiest >way out and of course ensuring that it will handle the amount of work you require >from it. > > My 10 cents. > Danny > > On 16/Jul/2002 10:09:38, Michael Cook wrote: > > Thanks Peter and Dave for your responses. > > > > The data sits in DBF tables. The tables are not that particularly large (the >largest has 78,000 records, and most others only have 1000 - 2000. > > > > I've been looking into DB2K <A TARGET="_blank" >HREF="http://www.dbase.com";>http://www.dbase.com</A> as it looks like a promising >toolset. > > > > I wanted to stay with stm scripting for now, but there is lots of support out >there for going to PHP and mySQL, as Peter mentioned. > > > > Michael > > > > >>> [EMAIL PROTECTED] 07/15/02 06:00PM >>> > > Hello Michael, > > > > What database are you using? > > > > I know alot of people use MS Access, but I'd advise against it. Yes, I > > do use it on my site, but only because it's the db used for a > > particular application (Legacy Family Tree) and I just publish that. > > > > The thing that most people do not realize about Access is that it's > > not really a relational database. It uses flat files, and to extract > > information the program must load the entire table into memory, get > > the info it wants, then throw away the rest. > > > > A true RDBMS only fetches the info you request. > > > > So switching to another DB will give you the biggest improvement. > > > > Monday, July 15, 2002, 12:11:58 PM, you wrote: > > > > MC> After reading how to increase Sambar performance in the docs (increasing web >performance and dbms performance), are there any other "tips" that would further >tweak dbms performance. I've got > > MC> Sambar 5.1 on W2K and I am using MS ODBC version 4.0.x DBF drivers. > > > > MC> Thanks. > > MC> ------------------------------------------------------- > > MC> To unsubscribe please go to <A TARGET="_blank" >HREF="http://www.sambar.ch/list/";>http://www.sambar.ch/list/</A> > > > > > > > > > > > > > > > > -- > > Best regards, > > Dave <A >HREF="mailto:[EMAIL PROTECTED]";>mailto:[EMAIL PROTECTED]</A> > > ------------------------------------------------------- > > To unsubscribe please go to <A TARGET="_blank" >HREF="http://www.sambar.ch/list/";>http://www.sambar.ch/list/</A> > > ------------------------------------------------------- > > To unsubscribe please go to <A TARGET="_blank" >HREF="http://www.sambar.ch/list/";>http://www.sambar.ch/list/</A> > > > > > > > > > > > ------------------------------------------------------- > To unsubscribe please go to http://www.sambar.ch/list/ > ------------------------------------------------------- > To unsubscribe please go to http://www.sambar.ch/list/ -- Arturo Rodr�guez Mutis Director de Inform�tica Melexa Ltda. PBX (571) 360 3055 mailto:[EMAIL PROTECTED] FAX (571) 360 2562 http://www.melexa.com Cll 10 # 29 - 31 Bogot�, Colombia ------------------------------------------------------- To unsubscribe please go to http://www.sambar.ch/list/
