Maybe try reinstalling the ODBC drivers.
----- Original Message -----
From: "Michael Cook" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 17, 2002 12:47 PM
Subject: [sambar] Increasing dbms Performance {05}
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 per
sonally 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/
-------------------------------------------------------
To unsubscribe please go to http://www.sambar.ch/list/
