Wat is belangrijk voor snelle queries mdb-server?

[beesting]

Op het bedrijf waar ik werk, hadden we 2 nogal oude pc's staan die met z'n tweeen in netwerkje stonden. Deze pc's werden gebruikt voor snelstart (programma dat werkt met mdb databases), maar het opzoeken van een lijstje met artikelen duurde bijvoorbeeld alleen al 10 seconden oid. Veel te lang in dit geval. De database stond dus op 1 van de 2 pc's en kon via een windows netwerkje op de andere worden geopend. Nu hebben we inmiddels 2 nieuwe pc's gehaald (twijfel tussen celeron en P4, maar volgens verkoper was celeron waarschijnlijk beter), 2x dezelfde, 2x celeron 1700 met 40gb ide ata100 hd & 256mb ddr2100 geheugen.

Het was de bedoeling om zo snel mogelijk over te stappen, vandaar dat we "gewoon" 2 kant en klare pc's hebben opgehaald en niet zelf hebben samengesteld (ik was voor meer geheugen gegaan, definately, maar die stonden daar niet ).


THE POINT is: hoe verbeter ik de server prestaties (weet natuurlijk niet hoe snelstart intern werkt, maar gaat dus waarschijnlijk om simpele select queries in een ms database)? Op dit moment is de database ca. 30mb groot, maar zou in de toekomst best nog iets groter kunnen worden. Het grootste deel van die ruimte wordt ingenomen door de artikelen, en het is de bedoeling na een stuk of 5 tekens ingetikt te hebben en op enter te drukken, binnen 2 seconden alle gevonden artikelen op het scherm te hebben.
(Will 512mb extra do the trick??)


Alvast bedankt (voor de hopelijk spoedige & nuttige) reacties!

[Koffie]

Ik dat het best wel eens van belang zou kunnen zijn welke DB applicatie er gebruikt word, en waar je allemaal bij kan enzo

Ander tipje; ik proef nou niet echt dat je er veel verstand van hebt. Ik denk dat je het alleen maar erger kunt maken als je er een beetje in gaat zitten prutsen.

[beesting]

Op donderdag 11 juli 2002 21:22 schreef Koffie het volgende:
Ik dat het best wel eens van belang zou kunnen zijn welke DB applicatie er gebruikt word, en waar je allemaal bij kan enzo

Zie posting. Programma heet Snelstart, administratief programma, gebruikt access databases.

Ander tipje; ik proef nou niet echt dat je er veel verstand van hebt. Ik denk dat je het alleen maar erger kunt maken als je er een beetje in gaat zitten prutsen.

OK, soms kunnen m'n postings een beetje onduidelijk zijn, maar ik weet wel degelijk waar ik over praat. Moet toegeven, ben geen systeembeheerder, heb niet eerder server moeten beheren oid. Maar ik weet wel waar ik over praat, veel mensen gaan toch naar me toe met pc-problemen, aankoop advies, e.d. Programmeer zelf een beetje, maak websites en heb al vaak genoeg onderdelen vervangen, dus don't worry. As said, die pc's moesten er snel zijn en niet voor al te veel geld. Zonder onnodig te bezuinigen. (De winkel was al besloten, de prijs moest redelijk zijn en het moest op dat moment gehaald worden, anders had ik wel een andere keus gemaakt, maar dit was volgens mij beste keus daaro. En, as said, waren alleen maar pc's met 256mb geheugen te vinden, of onnodig dure bakken.)

[Boogie]

Die 2 oude pc's, wat waren dat? Ik weet niet wat jouw definitie van oud is, maar misschien zit er in die kast wel een DUAL PIII 500 Xeon plankje met -SCSI en toeters en bellen of iets dergelijks. Dan gaat een "topline personal computer" het nog best moeilijk mee krijgen v.w.b. performance. Ik kan me best voorstellen dat ze bij M$ de code een beetje server-performance geoptimaliseerd hebben.

Bovendien is er misschien meer winst te halen uit een stukje database optimalisatie. Zit er geen "opschoon modus" of "her-indexeerder" in dat pakketje? Of misschien een upgrade van het pakket met een "echte" database er onder?

[Femme]

Het lijkt me trouwens niet dat meer RAM gaat helpen als de database maar 30MB groot is. De db past nu al makkelijk in RAM.

[Verwijderd]

Hoi,

Ok, dus als ik het goed begrijp heb je het volgende:
compu1 met snelstart
compu2 met snelstart die wijst naar een share op compu1

En op dit moment neemt ie nog steeds 10seconden in beslag om een artikel op te zoeken? Extra geheugen zal niet echt veel helpen, tenzij je naar een echte db-server gaat, zoals bijvoorbeeld FrontBase, Oracle, SQL Server, etc..
Die zal namelijk "intelligent" cachen en de vraag die iemand anders al eerder heeft gesteld nog een keer beantwoorden.

Omdat processor en geheugen snel genoeg zijn, zal je het ergens anders moeten zoeken. Omdat je vanaf compu2 naar compu1 gaat via het netwerk (correct me if I'm wrong), zou je kunnen kijken wat je netwerk-performance is. Draait het netwerk lekker of valt dat wat tegen?
En nog een tipje, zorg ervoor dat optimistic locking uitstaat. Het is wel performance, maar daartegenover staat wel betrouwbaarheid. Met byte-range-locking systemen (access db doet dat ook) kan dat in een hoger-volume datacorruptie geven.
Ik heb een klant waar de access-db naar 800MB was gegroeid, corrupt ging, daarna gerepareerd en toen was ie ineens weer 30 meg, wat je mocht verwachten...

Ik zou dus even gaan zoeken in je network access. wat is je doorvoer als je een bestand kopieert/ftp-ed? En hoe zit het met "bursty" verkeer?

offtopic:
Dit is ongeveer wat er gebeurd wanneer je een file-access oriented db systeem benaderd. Zodra het programma iets wil opzoeken, gaat ie het hele bestand door voor gevonden records. Als er een index is, zal ie zoeken in een index. Ik weet niet of je een complete artikelcode invoert of een gedeelte. Als het een gedeelte is, dan kan het zijn dat een index niet gebruikt kan worden (afhankelijk van hoe access indexes maakt), en moet dus iedere keer het hele bestand doorlopen worden om te kijken of het artikel aan het criterium voldoet.
Aangezien je niet zelf bij het systeem kan komen (andermans software), kan je niet echt makkelijk extra indexes erbij zetten. Het lijkt erop dat er niet op een index, maar record-voor-record gekeken wordt. Vandaar hierboven de issue netwerk...

Hoop dat dit een beetje helpt..

pjnef

Op donderdag 11 juli 2002 21:01 schreef beesting het volgende:
Op het bedrijf waar ik werk, hadden we 2 nogal oude pc's staan die met z'n tweeen in netwerkje stonden. Deze pc's werden gebruikt voor snelstart (programma dat werkt met mdb databases), maar het opzoeken van een lijstje met artikelen duurde bijvoorbeeld alleen al 10 seconden oid. Veel te lang in dit geval. De database stond dus op 1 van de 2 pc's en kon via een windows netwerkje op de andere worden geopend. Nu hebben we inmiddels 2 nieuwe pc's gehaald (twijfel tussen celeron en P4, maar volgens verkoper was celeron waarschijnlijk beter), 2x dezelfde, 2x celeron 1700 met 40gb ide ata100 hd & 256mb ddr2100 geheugen.

Het was de bedoeling om zo snel mogelijk over te stappen, vandaar dat we "gewoon" 2 kant en klare pc's hebben opgehaald en niet zelf hebben samengesteld (ik was voor meer geheugen gegaan, definately, maar die stonden daar niet ).


THE POINT is: hoe verbeter ik de server prestaties (weet natuurlijk niet hoe snelstart intern werkt, maar gaat dus waarschijnlijk om simpele select queries in een ms database)? Op dit moment is de database ca. 30mb groot, maar zou in de toekomst best nog iets groter kunnen worden. Het grootste deel van die ruimte wordt ingenomen door de artikelen, en het is de bedoeling na een stuk of 5 tekens ingetikt te hebben en op enter te drukken, binnen 2 seconden alle gevonden artikelen op het scherm te hebben.
(Will 512mb extra do the trick??)


Alvast bedankt (voor de hopelijk spoedige & nuttige) reacties!

[beesting]

Op donderdag 11 juli 2002 21:48 schreef mboogie2 het volgende:
Die 2 oude pc's, wat waren dat? Ik weet niet wat jouw definitie van oud is, maar misschien zit er in die kast wel een DUAL PIII 500 Xeon plankje met -SCSI en toeters en bellen of iets dergelijks. Dan gaat een "topline personal computer" het nog best moeilijk mee krijgen v.w.b. performance. Ik kan me best voorstellen dat ze bij M$ de code een beetje server-performance geoptimaliseerd hebben.

Goede vraag, maar nee, dat is niet het probleem. OK, misschien was een definitie van oud idd op zijn plaats geweest. Oud in dit geval is: single proc pentium 1, 4GB hd. (Sorry, heb exacte specs hier niet bij de hand.)
Niet echt geschikt als server in dit geval.

Bovendien is er misschien meer winst te halen uit een stukje database optimalisatie. Zit er geen "opschoon modus" of "her-indexeerder" in dat pakketje?

Gezocht, maar zo niet gevonden (don't flame me if I'm wrong
Met access kan ik hem zo niet openen.

Of misschien een upgrade van het pakket met een "echte" database er onder?

Helaas niet echt mogelijk denk ik. Vrij nieuw bedrijf, ik denk niet dat ze alles nu willen omgooien naar een ander pakket.

[beesting]

Op donderdag 11 juli 2002 21:51 schreef Femme het volgende:
Het lijkt me trouwens niet dat meer RAM gaat helpen als de database maar 30MB groot is. De db past nu al makkelijk in RAM.

Ja, ik weet het. Hoopte (daarom ook de vraag), dat het toch zou helpen. Want op deze manier valt er ook niet echt makkelijk te werken.

offtopic:
Sorry, lijk op dit moment echt supernoob hier sigh

Moest vanmiddag vroeg weg, dus na installeren van pc's, niet echt veel tijd meer over om verder nog wat te proberen. Dacht, misschien dat iemand hier nog wat tips heeft.
Ben morgen wel van plan om ff tijdens een query cpu en memorygebruik te monitoren...

[beesting]

Op donderdag 11 juli 2002 22:10 schreef pjnef het volgende:
Hoi,

Ok, dus als ik het goed begrijp heb je het volgende:
compu1 met snelstart
compu2 met snelstart die wijst naar een share op compu1

Ja.

En op dit moment neemt ie nog steeds 10seconden in beslag om een artikel op te zoeken? Extra geheugen zal niet echt veel helpen, tenzij je naar een echte db-server gaat, zoals bijvoorbeeld FrontBase, Oracle, SQL Server, etc..
Die zal namelijk "intelligent" cachen en de vraag die iemand anders al eerder heeft gesteld nog een keer beantwoorden.

Ik hoop dat dit niet de enige mogelijke oplossing gaat zijn, zullen ze niet blij mee zijn iig

Omdat processor en geheugen snel genoeg zijn, zal je het ergens anders moeten zoeken. Omdat je vanaf compu2 naar compu1 gaat via het netwerk (correct me if I'm wrong), zou je kunnen kijken wat je netwerk-performance is. Draait het netwerk lekker of valt dat wat tegen?

Netwerkje is niet supersnel, 10mbit. Maar die 10 seconden (heb geen stopwatch gebruikt, maar te lang in iig als een klant belt en je moet ff snel een artikel opzoeken), is _niet_ over het netwerk. Das de tijd die nodig is, om de query op de pc waarop de db zelf staat te doen...

En nog een tipje, zorg ervoor dat optimistic locking uitstaat. Het is wel performance, maar daartegenover staat wel betrouwbaarheid. Met byte-range-locking systemen (access db doet dat ook) kan dat in een hoger-volume datacorruptie geven.
Ik heb een klant waar de access-db naar 800MB was gegroeid, corrupt ging, daarna gerepareerd en toen was ie ineens weer 30 meg, wat je mocht verwachten...

OK, thnx voor de tip. Zal morgen gelijk ff kijken iig.

Ik zou dus even gaan zoeken in je network access. wat is je doorvoer als je een bestand kopieert/ftp-ed? En hoe zit het met "bursty" verkeer?

Zie boven, is niet de bottleneck in dit geval.

offtopic:
Dit is ongeveer wat er gebeurd wanneer je een file-access oriented db systeem benaderd. Zodra het programma iets wil opzoeken, gaat ie het hele bestand door voor gevonden records. Als er een index is, zal ie zoeken in een index. Ik weet niet of je een complete artikelcode invoert of een gedeelte. Als het een gedeelte is, dan kan het zijn dat een index niet gebruikt kan worden (afhankelijk van hoe access indexes maakt), en moet dus iedere keer het hele bestand doorlopen worden om te kijken of het artikel aan het criterium voldoet.
Aangezien je niet zelf bij het systeem kan komen (andermans software), kan je niet echt makkelijk extra indexes erbij zetten. Het lijkt erop dat er niet op een index, maar record-voor-record gekeken wordt. Vandaar hierboven de issue netwerk...

Het zijn idd delen van de artikelcodes die ingevoerd worden. Op zich goed punt, ik denk dat de pc zich daarin "verslikt" en dus idd geen gebruik van een index maakt. Kan'k helaas denk ik weinig aan veranderen. Zoals gezegd, zal morgen alles nog ff checken. Toch maar vast hier gepost om een mogelijke oplossing te vinden en die ook te kunnen proberen...

Hoop dat dit een beetje helpt..

pjnef
[..]

Thanks iig

[ripexx]

Mischien een gekke opmerking maar heb je al eens geprobeert om de leverancier te benaderen met het probleem. Als een db van +/- 30 MB er nog een aantal seconden over doet om te openen en of te updaten dan is er niet echt iets lekker. Zie bijv fok waarbij het databeest toch nog snel is. En waarschijnlijk is de extensie van het bestand mdb, en wil access de file niet openen. Maar neem eens contact op met je leveancier.

edit:

ff gezocht op inet (http://www.snelstart.nl/) en daar was aardig wat info over problemen etc te vinden, daaenaast kun je ze mailen en bellen

Op donderdag 11 juli 2002 21:39 schreef beesting het volgende:
Moet toegeven, ben geen systeembeheerder, heb niet eerder server moeten beheren oid. Maar ik weet wel waar ik over praat, veel mensen gaan toch naar me toe met pc-problemen, aankoop advies, e.d. Programmeer zelf een beetje, maak websites en heb al vaak genoeg onderdelen vervangen, dus don't worry.

Oke je typeerd hier een beetje gemiddelde tweaker...

[iceme]

Ik vind het toch een beetje raar, je hebt ook op de lokale machine dat het 10 seconden duurt om een artikel op te zoeken, wij draaien hier op het werk ook met snelstart, we zitter er met 7 machines in en onze db is 70 mb groot, draait op onze server (w2k server) en als wij een artikel opzoeken is deze er gelijk. Heb je misschien iets anders draaien waardoor het fout kan gaan wat veel preformance kost zoals bv. een virusscanner ed.?

Wouter

[Verwijderd]

zeker weten dat je een client-programma hebt?

Met Access bv op pc1 de database op pc2 openen en dan zoeken heeft weinig zin natuurlijk.

Kun je eens proberen op 1 pc je zoekprogramma en DB te draaien?

die indexen ook nakijken zoals men suggereert.

[beesting]

UPDATE: inmiddels nog een aantal instellingen geprobeerd te wijzigen, voorzover die in Snelstart aanwezig zijn
De optie database "controleren" bleek het meeste effect te hebben. (Nog steeds vreemde naamgeving imho, maar goed.)
Op dit moment duurt de query die eerst zo'n 10 seconden in beslag nam, nog zo'n 3 seconden ongeveer. Dus op zich al een aardige verbetering. Zou nog net iets sneller moeten kunnen imho, misschien nog een beetje puzzelen en "tweaken"

[Sidenote] Mochten mensen ook Snelstart gebruiken en ook de optie controleren willen proberen. Let dan op, ik had (op Windows XP) er in ieder geval last van dat de database na het controleren niet meer op de 2e pc te openenen was. Deze gaf de melding dat het bestand op alleen lezen stond of dat er iets met rechten oid was.
Oplossing: ga naar de map waar de administraties staan, kopieer de administratie in verkenner en plak hem in dezelfde map, verwijder de oude db en rename evt de nieuwe kopie.[/sidenote]

Mischien een gekke opmerking maar heb je al eens geprobeert om de leverancier te benaderen met het probleem. Als een db van +/- 30 MB er nog een aantal seconden over doet om te openen en of te updaten dan is er niet echt iets lekker. Zie bijv fok waarbij het databeest toch nog snel is.

Yup, het is al beter. Zie boven, maar moet nog iets beter kunnen. Bel misschien ook nog wel ff.

En waarschijnlijk is de extensie van het bestand mdb, en wil access de file niet openen. Maar neem eens contact op met je leveancier.

Het is een access database, maar er zit een pass op.

edit:

ff gezocht op inet (http://www.snelstart.nl/) en daar was aardig wat info over problemen etc te vinden, daaenaast kun je ze mailen en bellen

Ja, had na m'n laatste reply ook nog ff gekeken, daar kwam ik ook database controleren tegen. Thanks iig.

Oke je typeerd hier een beetje gemiddelde tweaker...

ty

Ik vind het toch een beetje raar, je hebt ook op de lokale machine dat het 10 seconden duurt om een artikel op te zoeken, wij draaien hier op het werk ook met snelstart, we zitter er met 7 machines in en onze db is 70 mb groot, draait op onze server (w2k server) en als wij een artikel opzoeken is deze er gelijk. Heb je misschien iets anders draaien waardoor het fout kan gaan wat veel preformance kost zoals bv. een virusscanner ed.?
Wouter

Idd. Het zou dus wel moeten kunnen. Er staat verder niks aan eigenlijk. Net nieuwe pc, nagenoeg nog niks geinstalleerd, draait ook geen virusscanner oid.
Misschien heb je nog wat tips, aangezien je hetzelfde pakket gebruikt? Wat voor server is het?

zeker weten dat je een client-programma hebt?
Met Access bv op pc1 de database op pc2 openen en dan zoeken heeft weinig zin natuurlijk.

Kun je eens proberen op 1 pc je zoekprogramma en DB te draaien?

DB en snelstart staan op pc1. Op pc2 staat alleen snelstart. Het probleem is dat het op beide pc's eigenlijk evenlang (te lang) duurt. Ook op pc1 dus.

die indexen ook nakijken zoals men suggereert.

In het instellingen menu staan niet echt veel opties. Tot nu toe het enige echt significante wat ik heb gevonden is het controleren van de database...

[iceme]

Idd. Het zou dus wel moeten kunnen. Er staat verder niks aan eigenlijk. Net nieuwe pc, nagenoeg nog niks geinstalleerd, draait ook geen virusscanner oid.
Misschien heb je nog wat tips, aangezien je hetzelfde pakket gebruikt? Wat voor server is het?
[..]

Wij hebben een server met daarin
Tyan MP mamaplank
2x athlon MP 1500+
adaptec raid controler
1024 MB
3 x seagate 10.000 rpm SCSI HDD's
op onze server draait het volgende

Snelstart en Exchange en terminal services maar daar word bijna geen gebruik van gemaakt
verder doet tie niet meer dan file en print sharing
we draaien met een 100mbit netwerk.

niet echt te vergelijken denk ik , maar als ik het pakket lokaal draai, draait het altijd nog sneller dan op de server.

[Verwijderd]

De volgende optie kun je ook nog proberen uit te schakelen in SnelStart

'Programma, Algemeen, Instellingen, Orders' en dan de optie 'Voorraad tonen in zoekvenster'.

Door deze optie uit te schakelen wordt er een lichtere query gebruikt wat het zoeken in het orderscherm sneller maakt.

Verder wordt er bij SnelStart aan gewerkt om de gegevens in een andere database op te slaan, dit zal Microsoft SQL Server worden. Dit zal bij de grotere databases voor meer snelheid zorgen.

[igmar]

Op donderdag 11 juli 2002 21:01 schreef beesting het volgende:
<snip>

'Snel' en 'Access' in een topic ??

Access is nooit bedoeld om snel te wezen, en veel sneller zul je het niet krijgen. Dus totdat je de mogelijkheid hebt om de zaken in een echte DB te gooien vrees ik dat je vast zit.

Je kan kijken hoe de locking staat (table / row), maar zover ik weet staat dit standaard op row locking.

[iceme]

Verder wordt er bij SnelStart aan gewerkt om de gegevens in een andere database op te slaan, dit zal Microsoft SQL Server worden. Dit zal bij de grotere databases voor meer snelheid zorgen.

Heb je misschien ook enig idee wanneer dit klaar is? lijk me een hele vooruitgang

[Verwijderd]

Op dinsdag 16 juli 2002 11:53 schreef iceme het volgende:

[..]

Heb je misschien ook enig idee wanneer dit klaar is? lijk me een hele vooruitgang

verwachting is het einde van dit jaar maar dit kan wat uitlopen natuurlijk.

er wordt iedergeval hard aan gewerkt