Serveradvies

[Verwijderd]

Het bedrijf waarvoor ik werkzaam ben is van zins een nieuwe server aan te schaffen.
De huidige server, een Compaq ProLiant ML350 (w2k server) wordt gebuikt als all-round werkpaard. De hoofdtaken zijn:

1. Exchange server (30 gebruikers)
2. Database server voor Info@cces (25 pc's)
3. Administratie programma (3 gebruikers)
4. Domeincontroller (active directory)
5. Printerserver
6. Fileserver (installatie, etc)

Met name Info@cces loopt niet overal soepel. Info@cces heeft als basis Access 2000 van microsoft en is in principe een inkoop/verkoop programma. Je kunt alle orders bekijken, contactpersonen opzoeken, productstatus opvragen, realtime magazijnvoorraad bekijken, etc, etc. De database van dit programma is ongeveer 500 mb maar die database zal zeker groter worden. Vooral op oude pc's (intel celeron, 256mb, win2k pro) is info@ccess niet vooruit te branden. Een simpele order opvragen kost al 15 seconden en een order invoeren nog veel langer.

Men wil in de toekomst ook medewerkers in laten bellen om zo gegevens te kunnen raadplegen, orders in te voeren, etc dus ook dat betekend ook weer extra belasting.

Is het verstandig een nieuwe, 'zwaardere', server aan te schaffen voor één programma of kan men de taken beter verdelen over twee servers? Dus voor het databasegedeelte één server met MS Access en voor de rest de oude server gebruiken?

Overigens loopt infoaccess op 'nieuwe' pc's wat vlotter. (dus ipv 15 seconden 3 seconden om een order op te vragen)

[_-= Erikje =-_]

Het feit dat je zelf al aangeeft dan info@ccess op nieuwe systemen al vlotter loopt geeft aan dat de bottleneck in dit geval niet helemaal bij de server ligt maar juist bij de clients, als je server de beperkende factor zou zijn zou het op iedere client ongeveer evenlang moeten duren.

Wat betreft de aanschaf van een zwaardere server, houd eens een paar dagen dingen als HDD gebruik, netwerkverkeer, geheugen gebruik en cpu belasting in de gaten, zit dat continue erg hoog is het inderdaag misschien verstandig om of een zwaardere machine neer te zetten of taken te verdelen over 2 machines, hiervoor zul je dan uiteraard eerst moeten kijken welke taak het meest van de machine gebruikt en of het verplaatsen van die taak naar een 2e machine een beter werkbare situatie opleverd

[the_stickie]

verdeel de load over 2 of zelfs drie servers; das groeibestendiger, en kosten-efficiënter ( en dat zijn 2 begrippen die ze in het management graag horen )

[raymonvdm]

Lijkt mij dat dit een taak is voor zelf meer dan 2 servers.

Dat info accis is dus 1 applicatie die best zwaar is ? Lijkt me dat je dit beter op een ml350 kan zetten.

Mail op een 2e server

En file en printer sharing op 3e server

[SoNoS]

Ik denk trouwens dat een access database van 500MB ook wel eens voor heel veel vertraging zorgt.

[Arnout]

MS Access? 500MB over een netwerk? 25 users, hoeveel tegelijk (access kan al traag worden bij 5 users tegelijk, om het maar niet te hebben over het locking gedrag).

[mutsje]

misschien inderdaad beter om te kijken of je die acces database niet over kunt zetten op bijvoorbeeld MySql wat gratis is of MSSql wat duur is. Dit zijn professionele databases.

Verder is het verstandig Exchange2000 niet op een Domain Controller te draaien Microsoft raad dit ook af.

Dus je zou in de nieuwe situatie al op 2+ servers uitkomen. En inderdaad neem steekwoorden als groei en dergelijke mee naar het management.

[Boss]

Probeer die database eens te comprimeren om hem wat kleiner te maken, dat wil nog wel eens helpen.

En verder hoef je voor die database geen aparte server te hebben. Het is gewoon een bestand, dat door veel gebruikers tegelijkertijd wordt gebruikt. Moet opzich goed kunnen, ook met een Access bestand.

Is er eventueel bij de leverancier van dat Info@cces niet een versie te krijgen die op een database server kan draaien?

(weet je overigens wie de maker/leverancier is van dat programma? Ben wel benieuws naar wat het doet en waarom ze Access gebruiken als database... )

[Grolsch]

volgens mij hebben de meesten hier nogal moeite met lezen (NOFI)

het is alleen op de wat oudere pc's langzaam.

Met andere woorden (zoals eerder gezegt) is de server dus NIET de bottleneck, maar de clients.

Dit zal oa te maken hebben met de grote access database over het netwerk.

Waar je aan "KUNT" denken is aan een Terminal server oplossing.
Dus een extra server kopen, installeren/configureren als Terminal server.
Alleen heb ik ook wel eens gehoord dat terminal server icm access dikke bagger is, maar dit weet ik niet.

Het is inderdaad aan te raden Exchange op een apparte server te zetten, maar als je zo tevreden bent, en je hebt het geld er niet voor, dan moet je het maar zo laten.

[Verwijderd]

Ik zou je ook adviseren om van de access database de tabellen en de interface te ontkoppelen, mocht dit nog niet gedaan zijn.
Ook dat scheelt tijd en bandbreedte.

[sniper20]

Een Access-database van 500 mb is inderdaad al aardig groot. Af en toe comprimeren is zeker een goede tip. De snelheid zal dan toenemen.
Je kunt overwegen om deze over te laten zetten naar SQL. Ik denk dat je dan het best contact op kunt nemen met de leverancier van het programma. Die zal je er wel meer over kunnen vertellen.

De snelheid van benaderen van de access-database ligt vaak gewoon aan de PC.
Ik het het vaak genoeg mee gemaakt dat als je een nieuwe server neerzet en
de PC's laat staan de gebruikers niet of nauwelijks snelheidswinst ervaren.\

Als je veel groei verwacht kun je beter proberen de werklast te verdelen. Ik zou wel eerst kijken of de server het nu werkelijk zo zwaar heeft.

[Verwijderd]

mutsje schreef op 27 October 2003 @ 13:02:
Verder is het verstandig Exchange2000 niet op een Domain Controller te draaien Microsoft raad dit ook af.

Zal wel kloppen, maar waarom hebben ze dan in hemelsnaam de SBS versies??

Als het enige wat echt slecht loopt die inf@access applicatie is, moet je 's ff kijken waar het probleem precies ligt.

- Server load ?.
- Vollopen netwerk ?.
- Query's worden clientside verwerkt ? (dus alle data moet eerst over het lijntje).

Verder is de netwerk aansluiting wel belangrijk, als de serverload niet hoog is, zal het waarschijnlijk een netwerk probleem zijn (te veel data over het netwerk). Wat ook daarmee gepaard kan gaan, is een slechte/volgelopen netwerk verbinding v/d server.

[tc982]

het lijkt mij gewoon logisch als alleen het programma trager loopt en je denkt dat dit kan liggen aan overload van de server dat je gewoon een ml350 erbij neemt met gewoon genoeg ram.

Aangezien het een MS ACCESS db is zou ik niet te zwaar in processor kracht gaan, heet weinig nut indien alle queries client side lopen.

Ook : Verwijder alle Windows 95/98 en ME clients! Mijn ervaring zegt dat de meeste "custom-made" programs traag lopen op een Windows 9x ( waarschijnlijk omdat de programmeur alles test op hun Windows 2000 of XP machine )

Terminal server is een alternatief maar te duur indien je geen Windows 2000 clients hebt, de zogenaamde CAL licenses maakt het heel duur!

Het beste is dat je even uitlegt wat er traag loopt ( een rapport opvragen of een record opvragen , lijsten of print-outs? ) en op welk OS dat deze draaien.

Ik ben er wel zeker van dat je best zoveel mogelijk load wegneemt van de exchange server. Er word enorm veel ge-emailed en iedereen houd alles bij ( de zogenaamde "Cover-your-ass Technology" ), waardoor de server in de toekomst het alleen maar zwaarder te evrduren krijgt.

Eens een tweede server gezet maak je deze gewoon "DC" of beter gezegd Active Directory Integrated!!

Voila bezie het eens.

[Arfman]

Umg .. ik zie een netwerkje van 30 man, en mensen komen met 2 of zelfs 3 servers op de proppen ?!

Stappenplan zoals ik het zou doen (niet dat ik alwetend ben, maar wel bijna )

-inventariseren wat de load is van de huidige server, en WAAR deze dan precies druk mee is

-kijken of je 1 nieuwe server aan kunt schaffen (ML370 G3 ofzo)

-enkele taken van de oude naar de nieuwe verhuizen (welke dat precies zijn hangt af van je inventarisatie)

-overleggen met de leverancier van dat Inter@ccess programma of hun programma niet op een echte database kan draaien, Access is en blijft hobbywerk.

Je hoeft op deze manier maar 1 server aan te schaffen (een zeer goed uitgeruste en redundante ML370G3 kost je zo'n 10.000 euro) en verdeelt toch de load. Ook redundancy is fijn om te hebben.

[Verwijderd]

Ik heb inmiddels (mede dankzij goede opmerkingen hier) contact opgenomen met infomeester, de leverancier van Info@ccess. (www.infomeester.nl)
Volgens hun technische helpdesk is een accessdatabase van 500 mb niet zo heel groot en moet hun programma over een 100mbit netwerk makkelijk draaien. De technischehelpdeskmedewerker vertelde mij verder dat áls er snelheidsproblemen zijn dit meestal aan een slecht geconfigureerd netwerk ligt. Hij merkte tevens op dat de server geen databaseserver rol heeft, meer een soort fileshareserver. Je werkt dus met alle medewerkers aan het zelfde file... (Op zich vreemd want een database - mits goed opgesteld - leent zich toch júist voor multi-client omgevingen?) Dus we gaan nu vrijdagmiddag 'down' en alle netwerkbekabeling en netwerkkaarten controleren...

De meneer van infomeester vertelde ook dat info@ccess op een celeron snel moet lopen mits het netwerk maar goed is. Hij haalde zelfs een voorbeeld aan waarin één slechte netwerkkabel (van een PC naar een patch) het netwerkverkeer dusdanig ontregelde dat Info@ccess zeer traag werkte. Of dat uberhaupt mogelijk is weet ik niet. Het lijkt me eerlijk gezegd een beetje sterk!

Het vervelende aan het hele geval is dat infomeester voor ons bedrijf een - zoals dat dan zo mooi heet - stukje 'maatwerk' heeft geleverd. Dit programma gebruiken we nu 3 kwart jaar. Overstappen naar een ander programma (of naar bijvoorbeeld SQL) zal er dus niet inzitten.

Overigens net met een stopwatch gekeken naar het snelheidsverschil met 'oude' pc's (celeron) en nieuwe pc's (pentium 4)...

een order opvragen duurt respectievelijk 13 en 9 seconden
een order invoeren (10 artikelen) duurt respectievelijk 8 en 7 minuten(!)
een verkooprapport genereren duurt respectievelijk 5 en 5 seconden.

het lijkt me dus dat de verschillende pc's niet het probleem zijn (wat infomeester overigens zelf ook aangeeft)

[Verwijderd]

Verwijderd schreef op 28 October 2003 @ 12:24:
Ik heb inmiddels (mede dankzij goede opmerkingen hier) contact opgenomen met infomeester, de leverancier van Info@ccess. (www.infomeester.nl)
Volgens hun technische helpdesk is een accessdatabase van 500 mb niet zo heel groot en moet hun programma over een 100mbit netwerk makkelijk draaien. De technischehelpdeskmedewerker vertelde mij verder dat áls er snelheidsproblemen zijn dit meestal aan een slecht geconfigureerd netwerk ligt. Hij merkte tevens op dat de server geen databaseserver rol heeft, meer een soort fileshareserver. Je werkt dus met alle medewerkers aan het zelfde file... (Op zich vreemd want een database - mits goed opgesteld - leent zich toch júist voor multi-client omgevingen?) Dus we gaan nu vrijdagmiddag 'down' en alle netwerkbekabeling en netwerkkaarten controleren...

Check even de echte snelheid van de aangesloten kaarten, vooral de server, wees er zeker van dat die op 100mbit staat en werkt.

Let vooral op het gebruik van de wat oudere hubs, als deze er zijn vervang ze dan sowieso door een goede switch.

Ik heb ooit een performance onderzoek gedaan naar een applicatie die niet goed performde. Het netwerk was al doorgelicht en goed bevonden. Nadat ik zowat alles
aan de applicatie had verbeterd wat mogelijk was, was de performance nog slecht.
Toen ben ik zelf maar ;s vragen gaan stellen, wat bleek, er werkten 20 tot 40 clients op 100mbit naar een server die met 10mbit verbonden was. Dit was daar dus het struikelpunt.

[Verwijderd]

Naar de netwerksnelheid had ik al eens gekeken en het hele bedrijf staat op 100mbit. Ik zie echter nu pas dat er geen 2 24 poort switches zijn maar hubs! De enige 10mbit connecties (oranje ipv groen lampje) zijn printers. De hub(-s) is een 3com superstack II Dual Speed Super Hub. Het netwerk zal mijns inziens beter presteren als deze worden vervangen door switches.

[Verwijderd]

Verwijderd schreef op 28 October 2003 @ 13:38:
Naar de netwerksnelheid had ik al eens gekeken en het hele bedrijf staat op 100mbit. Ik zie echter nu pas dat er geen 2 24 poort switches zijn maar hubs! De enige 10mbit connecties (oranje ipv groen lampje) zijn printers. De hub(-s) is een 3com superstack II Dual Speed Super Hub. Het netwerk zal mijns inziens beter presteren als deze worden vervangen door switches.

Informeer eerst even wat voor apparaten die 3com's precies zijn, je weet het nooit precies, misschien dat ze functioneren alszijnde wat we hier (over het algemeen) een switch noemen.

[Verwijderd]

De productpagina van 3com (http://www.3com.com/prod/...b=prodspec&sku=3C16611-US) geeft voor mij geen uitsluitsel over de werking van de hub. Op de site blijven ze 't apparaat echter steevast hub noemen en ik mag van 3com toch verwachten dat als ze een hub zeggen, ze een hub (met bijbehorende functionaliteit) bedoelen?

[Arfman]

Verwijderd schreef op 28 oktober 2003 @ 12:24:
Ik heb inmiddels (mede dankzij goede opmerkingen hier) contact opgenomen met infomeester, de leverancier van Info@ccess. (www.infomeester.nl)
Volgens hun technische helpdesk is een accessdatabase van 500 mb niet zo heel groot en moet hun programma over een 100mbit netwerk makkelijk draaien. De technischehelpdeskmedewerker vertelde mij verder dat áls er snelheidsproblemen zijn dit meestal aan een slecht geconfigureerd netwerk ligt. Hij merkte tevens op dat de server geen databaseserver rol heeft, meer een soort fileshareserver. Je werkt dus met alle medewerkers aan het zelfde file... (Op zich vreemd want een database - mits goed opgesteld - leent zich toch júist voor multi-client omgevingen?) Dus we gaan nu vrijdagmiddag 'down' en alle netwerkbekabeling en netwerkkaarten controleren...

Klinkt als de afschuiftactiek. Voor Access is 500 MB echt wel groot, het pakket is daar gewoon niet geschikt voor. Het filesharingverhaal van die gozer heeft daar mee te maken. Als je een SQL database zou hebben zou je inderdaad echt een databaseserver hebben, nu is het inderdaad een file van 500 meg die ergens neergepleurt wordt. Hoogst onefficient. Waarschijnlijk moeten al die arme werkstationnetjes die 500 MB ook nog eerst lokaal cachen, wat op een 100 mbit netwerk 500 / 12 MB = 41 seconden duurt. Ik denk dat uit je inventarisatie van het netwerk niets bruikbaars naar voren komt.

De meneer van infomeester vertelde ook dat info@ccess op een celeron snel moet lopen mits het netwerk maar goed is. Hij haalde zelfs een voorbeeld aan waarin één slechte netwerkkabel (van een PC naar een patch) het netwerkverkeer dusdanig ontregelde dat Info@ccess zeer traag werkte. Of dat uberhaupt mogelijk is weet ik niet. Het lijkt me eerlijk gezegd een beetje sterk!

Sja. Het enige wat ik me hierbij voor kan stellen is, is dat er ergens een dusdanig rotte kabel in een netwerk was geplugd die ervoor zorgde dat het netwerk overspoeld werd met broadcasts. In dat geval is niet alleen hun bakseltje traag, maar gaat alles traag.

Het vervelende aan het hele geval is dat infomeester voor ons bedrijf een - zoals dat dan zo mooi heet - stukje 'maatwerk' heeft geleverd. Dit programma gebruiken we nu 3 kwart jaar. Overstappen naar een ander programma (of naar bijvoorbeeld SQL) zal er dus niet inzitten.

Niet gehinderd door enige kennis zeg ik het volgende: is het niet mogelijk om die Access database te importeren in SQL Server, zodat alleen je backend (serveromgeving) veranderd ?

Overigens net met een stopwatch gekeken naar het snelheidsverschil met 'oude' pc's (celeron) en nieuwe pc's (pentium 4)...

een order opvragen duurt respectievelijk 13 en 9 seconden
een order invoeren (10 artikelen) duurt respectievelijk 8 en 7 minuten(!)
een verkooprapport genereren duurt respectievelijk 5 en 5 seconden.

Typisch iets wat komt doordat Access zich simpelweg niet leent voor databases van die grootte. Ik heb hetzelfde gehad met een Access database van 800 MB (!) op een Novell NetWare 5.1 server, dus laat je ook niet afschepen als ze zeggen dat het aan je netwerk OS of wat dan ook ligt.

het lijkt me dus dat de verschillende pc's niet het probleem zijn (wat infomeester overigens zelf ook aangeeft)

Dat klopt. Nogmaals: Microsoft Access is je bottleneck.

EDIT: het zijn inderdaad hubs. Switches zouden enige performancewinst kunnen brengen, als je server tenminste de gevraagde data snel genoeg kan aanleveren (en als elke PC 100 MBIT heeft zit je op een server al snel aan Gigabit).

Dit zal echter lang niet zoveel performancewinst opleveren als een overstap naar een echt databaseplatform.

[ Voor 6% gewijzigd door Arfman op 28-10-2003 19:09 ]

[Verwijderd]

Zojuist is hier iemand van infomeester aan het werk geweest en is de database teruggebracht van 535 mb naar 116 mb (!). Ik merk echter weinig performance verschil...

Ik ga wat doen met de hubs. Deze gaan - als het aan mij ligt - vervangen worden door switches met een gigabit connectie voor de server... gigabit kaartje in de server planten en we hebben weer íets aan snelheidswinst.

Info@ccess is een programma dat specifiek voor ms-access is ontwikkeld dus de db migreren naar een SQL server zal niet gaan mijns inziens.

De netwerkcheck gaat wel gewoon door maar ik verwacht idd ook niet daar wat wijzer van te worden want het netwerk zélf is snel genoeg (wat je mag verwachten van een 100mbit netwerk)

Maar goed, die andere server kómt er wel aan want er gaat door vertegenwoordigers binnenkort 'remote' ingebeld worden... wil wel eens weten hoe dat info@ccess loopt over een telefoonlijntje (5kbps?) (is wat genuanceerder natuurlijk want de 'inbelserver' kan de db over het lokale netwerk aanspreken.)

Overigens; Bestaan er programma's waarmee ik het netwerk kan doormeten?
Ik zou graag een overzicht maken van het netwerkverkeer per pc, hoevel packets verzonden en ontvangen, hoeveel 'bad' packets er zijn ontvangen etc. Ik kan ook iedere pc wel aflopen en alle netwerkverbindingsdetails nakijken...

[ Voor 15% gewijzigd door Verwijderd op 31-10-2003 11:15 ]

[Loesje]

Zojuist is hier iemand van infomeester aan het werk geweest en is de database teruggebracht van 535 mb naar 116 mb (!). Ik merk echter weinig performance verschil...

Wat die man heeft gedaan is het databestand comprimeren, zoals Boss hierboven al suggereerde. Maar dat maakt voor de performance inderdaad helemaal niets uit.

De meneer van infomeester vertelde ook dat info@ccess op een celeron snel moet lopen mits het netwerk maar goed is. Hij haalde zelfs een voorbeeld aan waarin één slechte netwerkkabel (van een PC naar een patch) het netwerkverkeer dusdanig ontregelde dat Info@ccess zeer traag werkte. Of dat uberhaupt mogelijk is weet ik niet. Het lijkt me eerlijk gezegd een beetje sterk!

Dat kan dus wel. Juist omdat access zo vreemd werkt met die file-sharing. Alle gebruikers namelijk hebben tegelijkertijd dat bestand open. Als er een gebruiker een brakke verbinding heeft, en die werkt in een bepaald record waar anderen ook bij willen, zullen die anderen moeten wachten tot die eerste user klaar is. Maar tijden van 5 minuten zijn belachelijk.

Info@ccess is een programma dat specifiek voor ms-access is ontwikkeld dus de db migreren naar een SQL server zal niet gaan mijns inziens.

Het is mijn werk om maatwerk databases te maken, voor zowel access als SQL omgevingen, en ik weet vrijwel zeker dat het wel kan. Vraag is of infomeester het kan, of dat ze alleen met access werken. Maar je kan het ze vragen. (je front-end is dan nog steeds access, maar de data staat op een SQL-server)

Verder kan ik me alleen maar aansluiten bij wat Arfman al zegt. En ik vermoed dat de overgang naar gigabit niets zal helpen. . .

Gaat het sneller als er maar een iemand aan het werk is?

edit:
Ik heb op hun site gekeken, en het is een product dat ze meerdere keren verkopen, en geen access-frontend. Ik denk niet dat ze voor een enkele klant de boel naar SQL zullen porten.

[ Voor 6% gewijzigd door Loesje op 31-10-2003 11:56 ]

[raymonvdm]

Heb je alle werstations wel netjes op auto staan ? ipv 100mbit full of 100mbit half.

Want vast instellen werkt niet altijd met hubs. Nou wil ik niet zeggen dat het op een cisco 3550 wel werkt. maar daar is het zo dat je of alles auto of alles vast moet zetten wil je performance hebben (dit is dan per poort)

Mooi switch trouwens zo`n cisco 3550-48 met 2 gbics.

Kun je dus 2 server aanhangen met 1gbit connectie. Of 1 server en een 2e switch getrunked.

[Twarp]

Zoals eerder ook al aangegeven heb je problemen op je clients en niet op je server. Je infomeester gaf ook al aan dat 100Mbit meer dan zat is dus aan je server zou ik in eerste instantie niets veranderen. Het wordt tijd dat jij je clien pc's eens onder de loep neemt en die waar nodig upgrade. Voor redundancy kan je altijd nog een tweede server neerzetten maar echt nodig lijkt het mij niet. Check je load van je netwerk, CPU en HD's dan kom je tot de conclusie dat je client de boosdoener is.

[Verwijderd]

Verdeel de load over 3 servers als volgt.

Server 1
Exchange server (30 gebruikers)
Domeincontroller (active directory)
Printerserver
Fileserver (installatie, etc)

Server 2
Database server voor Info@cces (25 pc's)

Server 3
Administratie programma (3 gebruikers)

Hebben we in de loop der jaren hier ook gedaan, mede omdat de database server nogaleens crashed, zodat de gebruikers gewoon door kunen werken. Met name het administratieve gebeuren ...

[Coen Rosdorff]

Voor access achtige toestanden over inbel lijnen zal je met een citrix achtige oplossing moeten komen. 115MB over een telefoonlijn gaat niet werken ;-)

Probeer trouwens eens een grafiek van je netwerk verkeer te maken als je met 1 of 2 clients in de dat pakket bezig bent. Dan kan je zien of het netwerk echt de beperkende factor is.

[ Voor 38% gewijzigd door Coen Rosdorff op 01-11-2003 03:23 ]

[Verwijderd]

Evil,

Access gedraagt zich als een filesystem zoals het nu is opgezet! GEEN client/server toepassing. Op het moment dat een client iets opvraagt dan wordt eerst de gehele dataset geladen en daarna wordt pas het resultaat eruit gehaald ->> gevolg veel (onnodig) dataverkeer

:: Kijk maar eens naar de CPU load op zowel de Client als de Fileserver, hier zul je zien dat de Client enorm staat te rekenen terwijl de Fileserver stabiel blijft.

Een echte client / server toepassing zorgt ervoor dat alle logica aan de serverzijde wordt uitgevoerd en slechts het resultaat over de lijn gaat. In geval van Access zou dit betekenen - data opgeslagen binnen bijv. SQL server en de logica bijv. in Stored Procedures zodat Access slechts de Stored Procedure hoeft aan te roepen en dus werkt als een echte frontend ( natuurlijk gaat hier wat inspanning aan vooraf )

Conclusie - er is onnodig veel netwerkverkeer EN dit wordt dan ook nog eens gehinderd door hubs ipv. switches - waarschijnlijk bij veel gebruik ook veel last van collisions dus geen optimaal netwerkverkeer.

[Verwijderd]

Als je het aandurft wat te spelen, dan kun je het allemaal wat sneller door de netwerkkaart heenduwen.

Zet file en printer sharing van de nic ip "maximise throughput for network applications"
Zet de volgende 2 regkeys:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpMaxDataRetransmissions"=dword:0000000a

[KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"KeepAliveTime"=dword:0000ea60
"KeepAliveInterval"=dword:000003e8

Mocht bovenstaande niet bevallen, is het simpel terug te zetten, door de keys weg te gooien, en de nic weer standaard te zetten.
Mijn ervaring is ongeveer 20 tot 30% meer netwerksnelheid.

[raymonvdm]

Maar hoe zit het nou met die hubs ?

WAnt dan mag nog steeds maar 1 station tegelijk lullen en dat kan best een probleem zijn als er 30 / 50 pc`s aanhangen probeer dus je collisiondomains zo klein mogelijk te maken. Door bijvoorkeur een managedswitch neer te hangen.

3Com/Cisco dat maakt niet zoveel uit (als je niet op geld let)

Heb je niet genoeg budget voor een volledige geswitchte omgeving plaats dan een paar backbone switch (als daar wel geld voor is)

Zodat zoveel mogelijk pc`s/hub`s geswitched hangen. Natuurlijk je server als eerste geswitched. Denk dat een nieuwe server dan niet eens noodzakelijk is. Al vergroot het wel je redundancy.

[THIJZEL]

hoe communiceerd dat programma met die accessdatabase? Via een odbc koppeling?
dat zou je het in theorie gewoon allemaal over kunnen zetten naar sql server en daarna de odbc koppeling aanpassen..

dit heeft de volgende voordelen:
* je maakt geen gebruik meer van de hobby database access( die is bedoelt voor de ledenadministratie van de plaatselijke tennisclub! niet voor een bedrijfscritische applicatie!!)
* véél minder dataverkeer ( alleen de querys en het resultaat daarvan word op en neer gestuurd)
* al het rekenwerk gebeurt server-side, dus langzamere clients geven geen problemen meer.
* makkelijker beheersbaar ( sql server heeft net ff wat meer mogelijkheden als access )

als ik jou was zou ik eens nagaan of dit niet mogelijk is..

[ Voor 9% gewijzigd door THIJZEL op 03-11-2003 00:22 ]

[Arfman]

Ik zie hier heel veel goedbedoelde replies staan (netwerkinstellingen, duplex, registry entries, hub/switches), echter, deze zullen met een aan zekerheid grenzende waarschijnlijkheid geen of nauwelijks resultaat opleveren. Waarom niet ?

Microsoft Access is niet of nauwelijks geschikt voor dit soort toepassingen !

Ik zie het zelf op m'n werk, het wordt onderkent door Microsoft en heel veel bedrijven die een beetje serieus bezig zijn met databases op MS platformen.

[StevenK]

Arfman schreef op 03 november 2003 @ 00:36:
Ik zie hier heel veel goedbedoelde replies staan (netwerkinstellingen, duplex, registry entries, hub/switches), echter, deze zullen met een aan zekerheid grenzende waarschijnlijkheid geen of nauwelijks resultaat opleveren. Waarom niet ?

Microsoft Access is niet of nauwelijks geschikt voor dit soort toepassingen !

Ik zie het zelf op m'n werk, het wordt onderkent door Microsoft en heel veel bedrijven die een beetje serieus bezig zijn met databases op MS platformen.

Het kan wel, maar alleen als je de applicatie dan TS-based draait.

Dan nog heb je het risico van (zware) corruptieproblemen.

Het is niet voor niks dat Access tegenwoordig native SQL-server ondersteuning heeft.

En als infomeester zegt 'kan niet', dan kun je er beter 'infoleerling' van maken, want *elke* acccess-database kan, met weinig werk, omgezet worden naar SQL server.

[Jazzy]

Ik zie 2 problemen:
- inefficient gebruik van een Access-database met bijbehorende hoeveelhied dataverkeer
- hubs waar switches beter zouden zijn

Je kunt het probleem oplossen op 2 manieren, het dataverkeer naar beneden (laten) brengen of de hubs vervangen door switches. Ik denk dat je beide moet doen, switches zijn in ieder geval slim omdat de hoeveelheid dataverkeer tegenwoordig best toeneemt.

Ik zie dat de uitspraken van Infomeester in twijfel worden getrokken en afgedaan als 'afschuifpolitiek'. Ik ga er echter vanuti dat een helpdeskmedewerker spreekt uit ervaring bij hun andere klanten en dus best kan beoordelen wat groot is en wat niet.

De logische stap lijkt mij: eerst je netwerk optimaliseren en dan de softwareleverancier zijn werk laten doen. En eerlijk gezegd moet het jou niet uitmaken of je Access gebruiken of SQL, als de performance maar acceptabel is.

[Loesje]

En als infomeester zegt 'kan niet', dan kun je er beter 'infoleerling' van maken, want *elke* acccess-database kan, met weinig werk, omgezet worden naar SQL server.

Ja, dacht ik ook. Tot je op hun site gaat kijken. Het is namelijk helemaal geen access-database. Ik vermoed dat het een VB-applicatie is, die de data opslaat in een Access-database. (Dus nog veel ranziger)

Maar wat THIJZEL zegt is wel waar. Als die applicatie een ODBC-koppeling gebruikt, dan is dat wel te vervangen door een echte database server.

Ik zou doen wat Jazzy zegt. Eerst de switches plaatsen. (eerst testen voor je het hele netwerk omgooit?)

Werkt dat niet voldoende dan verder kijken of het een ODBC-koppeling is, zoja: dan is het relatief makkelijk om er een SQL-server aan te gooien. Zonee, infomeester hard schoppen.

[StevenK]

Loesje schreef op 03 november 2003 @ 11:17:
[...]


Ja, dacht ik ook. Tot je op hun site gaat kijken. Het is namelijk helemaal geen access-database. Ik vermoed dat het een VB-applicatie is, die de data opslaat in een Access-database. (Dus nog veel ranziger)

Dan is het nog veel makkelijker, tenminste voor de programmeur.

Maar wat THIJZEL zegt is wel waar. Als die applicatie een ODBC-koppeling gebruikt, dan is dat wel te vervangen door een echte database server.

Ik zou doen wat Jazzy zegt. Eerst de switches plaatsen. (eerst testen voor je het hele netwerk omgooit?)

Werkt dat niet voldoende dan verder kijken of het een ODBC-koppeling is, zoja: dan is het relatief makkelijk om er een SQL-server aan te gooien. Zonee, infomeester hard schoppen.

[Arfman]

Mensen toch ..

Hubs vervangen door switches zal in dit geval NAUWELIJKS helpen .. 90% van de performanceproblematiek zit in de applicatie, niet de hardware !

[Loesje]

We reageren nu in cirkeltjes. Maar ik denk dat Arfman wel gelijk heeft.

[Jazzy]

Loesje schreef op 03 november 2003 @ 15:50:
We reageren nu in cirkeltjes. Maar ik denk dat Arfman wel gelijk heeft.

Zal ik nog maar een keertje zeggen dat je eerst je netwerk moet optimaliseren en dan alleen de applicatie over houdt?