I've tested database access using ODBC connections through other application software, and the performance is just fine.
Also, there are a dozen database tables in various locations across the HD. I'm having extremely poor performance access times regardless of the database accessed, so bad sectors is being ruled out. No HD or other HW errors. I can open a huge log file in from a client browser on the server, and the throughput approaches 100k/sec. CGI access is very fast as well. It is only database access that I am experiencing very poor performance. Throughput is gets up to 3.5k/sec for a 300 row table call. Like I said, I set up Sambar on another W2K box (with much less resources) with the same database tables and ODBC settings. The response times are lighting fast. I'm thinking that all have left is some W2K problem. Michael >>> [EMAIL PROTECTED] 07/17/02 10:45PM >>> To test both of these: #1. Do you have some method other than Sambar to test your odbc to test database reponse time. If you have Microsoft access you can simply link a table within it through ODBC to your database. Then let access run a few queries and see if you have the same response time issues. If so I would take the next step as Peter mentioned and check your ODBC drivers / settings out. #2. Compact and repair your database.. Maybe some corruption there that your not seeing. Not sure what direct database testing you have done. If you think it might be an IO problem with your HD you might try copying your database to another location on your harddrive and relink your odbc connection there.. This would be a quick and dirty method to ruling out a bad sector or 2. Danny On 17/Jul/2002 12:50:21, Melexa Ltda. wrote: > 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(<A >HREF="http://www.dbtools.com.br";>www.dbtools.com.br</A>) 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 <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> > > -- > Arturo Rodr�guez Mutis > Director de Inform�tica > Melexa Ltda. > PBX (571) 360 3055 <A >HREF="mailto:[EMAIL PROTECTED]";>mailto:[EMAIL PROTECTED]</A> > FAX (571) 360 2562 <A TARGET="_blank" >HREF="http://www.melexa.com";>http://www.melexa.com</A> > Cll 10 # 29 - 31 > Bogot�, Colombia > ------------------------------------------------------- > 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/
