Heart-Profit ERP

hallo,

wij gaan het server park binnen kort vervangen voor nieuwe. heart profit draait nu op een Pentium 3 server onder novell netware 5. gewoon een trage bak dus ! !

wij willen overgaan op Windows omgeving maar waar moet ik op letten voor de server specs. ik neem aan dat de snelheid wordt bepaald door de server en netwerk maar misschien is het ook wel iets om op SQL server te draaien??

waarop hebben jullie heart profit nou draaien en hoe bevalt het?

Hoi Leslie, welkom hier !

W2003 met gescheiden disks voor data en indexen, en je bent er wel zo'n beetje (voor Native MS Visual FoxPro database).
N.b.: Geen Raid 5 ! (want dat vertraagt juist t.o.v. 1 disk; neem dan hardwarematig Duplexen (jaja, dat bestaat ook onder Windows !)).

Wij hebben zelf zowel Native VFP en SQL/Server, beiden separaat op een 1GHz machientje, maar ik meen dat dit forum ook op de machine draait waar SQL/Server op draait (en anders is het de webserver wel waar SQL ook op staat).

Mocht je nog willen kiezen tussen Novell en Windows, dan kiezen wij tegenwoordig voor Windows (stabieler, nooit problemen met moeten reorganiseren van bestanden (jullie ook niet las ik laatst, maar het gebeurt met Novell toch wel hoor).

SQL/Server verhaal op zich is al eerder over geschreven (aan Dirk-Jan), en jullie moeten zelf maar eens kijken wat je daar mee wilt. Probeer wel te doorzien dat bij jullie uiteindelijk veel met veel heeft te maken, tot aan webshops / kassasystemen aan toe. Het enige wat een SQL/Server database als extra nodig heeft is veel geheugen per gebruiker (ik houd het niet helemaal bij, maar ooit was dat 16MB per gebruiker).

Als je verdere vragen hebt, stel ze gerust.

Peter

w2003 zal het wel worden maar waarom geen raid 5 oplossing? het zal ook zijn dat we een redelijk zware server gaan aanschaffen met de bedoeling om meerdere applicaties te gaan draaien. je kent de voordelen van een raid 5 oplossing maar hoeveel trager gaat het worden en wanneer bijj welke handelingen.
de server waarop het nu draait is een PIII 1000 1gb mem en een raid 5 oplossing. (dus trager kan het niet worden  :smile:)

je weet ongeveer wat wij hebben en doen aan heart profit, wij zouden voldoende hebben aan native vfp? of is SQL server "te"van het goede voor wat wij met heart profit doen.

het voordeel van novell is wel dat de server zelden of nooit gereboot hoeft te worden en dat er netjes met de schijf wordt omgegaan. maar windows server daarentegen herstart ik vaker. hoe is het met het wegschrijven van bestanden in heart? moet er b.v. vaak ge defragmenteerd.

ook is het zo dat er bij ons nu bestanden zijn die tegen de 2gb (bv LOVR) aan hikken en dat er niet zo goed mee overweg kan worden gegaan als deze te groot worden. is hier ook iets tegen te doen?

leslie

Raid5 is gemiddeld genomen iets trager in lezen (data leze is sneller, indexen lezen is langzamer). Raid5 is buidend langzamer in schrijven.

Voorgaande is t.o.v. 1 disk. Dus, t.o.v. 1 disk is Raid5 langzamer.

Als je twee disks hebt (geen Raid5 dus), worden data en indexen (zeg maar) parrallel gelezen, en is het al bij 1 gebruiker merkbaar dat van beiden de diskhead stil kan blijven staan bij het browsen door een tabel (altijd data + index). N.b.: De diskhead van de data zal wel bewegen omdat de data niet sequentieel is opgeslagen, maar dat zorgt er in elk geval niet voor dat de diskhead van de index wordt verplaatst (en de index wordt wèl sequentieel gelezen bij browsen door een bestand).
2 disks is door de bank genomen een faktor 100 sneller als 1 disk, en is dus nòg sneller t.o.v. Raid5.

Bij hardwarematig duplexen heb je 2 disks voor de data en 2 disks voor de indexen. Het schrijven gebeurt 100% parallel en maakt kwa snelheid niets uit, maar voor lezen kan de ene "gebruiker" de diskhead verplaatsen voor zichzelf, terwijl de diskhead voor de andere "gebruiker" blijft staan. Dit verschil is gelijkwaardig aan het eerder genoemde verschil tussen 1 disk en 2 disks, doch treedt nu alleen bij lezen op. Voor lezen geldt aldus dat een geduplexte configuratie ongeveer 100 keer sneller is als de situatie met 2 disks.

Raid5 is logisch gezien 1 disk, waarbij de gegevens gescattered zijn over de disk. Iets wat eigenlijk sequentieel is (zoals een index) is dat nu niet meer, en hoeveel dat scheelt kun je uitrekenen aan de hand van rotatiesnelheid (tegenwoordig 15.000 rpm) en gemiddelde accesstijd (positioneren diskhead, stel 5 ms; positioneren is niet aan de orde bij sequëntiele verwerking).
Aan de andere kant, als meerdere "gebruikers" een stukje gegeven nodig hebben, staan er 3 ook meerdere disks ter beschikking om dat stukje data op te halen, dus daar win je weer iets. Als je dit tegen elkaar laat wegvallen, blijft over het schrijven wat enorm veel langzamer is. Immers, waar normaal gesproken altijd sequentieel wordt geschreven, moet dit nu verplicht gescattered worden gedaan (zie Raid5 principe).

Konklusie :
Een hardwarematig geduplexed system is 100x100 = 10.000 keer sneller dan een enkele disk, en een enkele disk is sneller dan Raid5.
Vergeet niet : dit merkt 1 gebruiker al, omdat wat een gebruiker ook doet, hij heeft een index nodig om de data te bereiken en trekt met het lezen van z'n eigen data de diskhead van de index niet weg.

Kanttekeningen :

Wat ik "sequentieel" noem betreft het achter elkaar kunnen lezen / schrijven van gegevens van / naar de disk, waarbij de gelezen / geschreven volgorde van de data ook precies de volgorde is die is benodigd. Merk op dat je het hier niet hebt over gigabytes aan gegevens, maar dat enkele diskblokken (met daarin honderden records met per record bijvoorbeeld een artikelnummer) het niet hoeven verplaatsen van de diskhead steeds het aantal ms accesstijd (die er dan niet is) wint.
Defragmentatie is wat ons betreft niet aan de orde (hebben wij ook nooit gedaan, en ik zou denken dat ook niemand dat ooit doet), omdat je zo af en toe eens een index opnieuw opbouwt, en dàt eigenlijk je defragmentatie is. Merk op dat die index best vol met gaten kan/mag/zal zitten, maar dat er naar verhouding zo veel diskblokken aansluitend zijn dat je per saldo toch veel blijft winnen. Ook geldt dat als je eenmaal van mening bent dat defragmenteren zou helpen, je het ook wel iedere dag mag doen.

Een berekening zoals "100 keer sneller" is niet uit de losse pols gedaan, maar is uiteindelijk uitermate complex en van enorm veel afhankelijk. Begin maar met te denken aan de caches die op meerdere niveaus aanwezig zijn.
Denk er vooral ook aan dat je met blockgroottes (clustergroottes) te maken hebt, die voor de data zo klein mogelijk moet zijn, en voor de indexen niet zo groot mogelijk, maar met wel ergens een optimum dat velen malen groter is dan de data blokken. Kun je met Raid5 niet doen ... Wèl scheelt dit weer enorm, want òf je leest 128KB voor een datablok voor een record van 40 bytes, òf je leest 100 indexblokken van 16KB sequentieel, terwijl het er ook 2 hadden kunnen zijn van 1024KB. Let wel, het aantal gelezen bytes maakt in deze niet uit voor je disk susbsysteem, wèl het aantal keren dat blokken moeten worden gezocht. Over het laatste hebben we het hierboven gehad, en je begint nu misschien in te zien hoe enorm verkeerd je het kunt doen met Raid5 ...

Voor navolgende geldt dat "data" niet gelijk is aan de data zoals hierboven genoemd. Het betreft hier gewoon "gegevens" en wat ik noem kan gelden voor de data zoals hierboven genoemd, maar geldt net zo goed voor de indexen zoals hierboven genoemd.

Voor Native VFP heb je te maken met "balanced trees", die feitelijk de diepte aangeeft in de blokhiërarchie. Zie het maar zo dat als je voor een tabel 1.000.000 datarecords hebt van 100 bytes per stuk, bij een blokgrootte van 16KB, dan passen er in een blok 160 records. Aldus heb je totaal 6.250 blokken nodig. Nu moet het systeem wel weten waar die zich bevinden op disk, en dat werkt met verwijzingen die beginnen in een root(blok). Aannemend (want dat weet ik even niet) dat je 16 bytes nodig hebt voor een verwijzing, dan passen er voor het 16KB blok dus 1000 verwijzingen in 1 blok. We hebben er 6.260 nodig, dus met 7 blokken onder de root kunnen we alle (blokken van) records identificeren. Het root blok bevat dus 7 verwijzingen en kan nog 993 verwijzingen meer bevatten). Als het root blok vol is, ontstaat er een extra niveau, en heb je dus een rootblok dat naar 1000 blokken kan verwijzen die ieder naar 1000 datablokken kunnen verwijzen die ieder (in dit geval) 160 records kunnen bevatten.
Ook al weten we dat mijn berekening hier niet juist is omdat ik de lengte van de verwijzingen niet ken, je snapt wel dat er héél veel records meer in de tabel moeten alvorens het lezen van de datablokken langzamer wordt (want, dat gebeurt alleen maar als er een extra niveau ontstaat). Uit de praktijk (ooit) weet ik dan ook dat als je eenmaal de stap van zo'n 10.000 records hebt genomen, het voorlopig tot 10.000.000 records o.i.d. duurt alvorens er 1 blok extra moet worden gelezen. Dat ene blok extra is dan op de (meen ik) 4 die al gelezen moesten worden (in de diepte) en dus wordt het 25% langzamer als je die 10.000.000 records overstijgt.

Merk op dat voorgaande zich nog steeds -en absoluut- niet leent voor enige konkrete berekening, omdat -ook al kun je de blokgrootte zelf bepalen- je (als klant) hebt onze recordlengte niet in de hand en die is voor iedere tabel (van de totaal 1.700 of zo) anders. Ook de lengte van de "index records" is steeds anders, en het is wel de lengte van de records die bepalend is voor de benodigde diepte in de blokken bij het betreffende aantal records.

Ik refereer dan nogmaals aan de caches op de verschillende niveaus, waarbij je in elk geval voor je moet zien dat -waar het gebruikelijk is dat de meeste blokken in cache staan- de root blokken altijd wel in cache staan, en het niveau daaronder snel ook wel (in ons voorbeeld waren dat maar 7 blokken) en je je hooguit kunt afvragen hoeveel datablokken van een tabel in de cache(s) staan. Anders gezegd : voor alles wat in de cache staat gaat het hele verhaal van 100 keer sneller enz. niet op. Wèl voor de eerste benadering van betreffende blokken natuurlijk. Maar, die "100 keer" ontsaat toch niet zomaar;

Als we het "simpel" houden, en we nemen een SATA2 disk, dan kan deze 300MB per seconde verstouwen. Als dit een 7.200 rpm disk betreft, dan doet deze 8ms over een omwenteling. In deze 8ms kan 2,4 MB worden gelezen. Nemen we de specs erbij van zo'n anno begin 2007 disk, dan mag deze 7ms gemiddelde accesstijd hebben. Er is dus 7ms nodig om de diskhead te positioneren om ... tja, niét om 2,4MB te lezen, want dat krijg je in Profit niet voor elkaar. Denk gerust aan een data record zoals voor een artikelnummer, omdat je dat artikelnummer intypt, en er (ik zeg maar wat) 500 bytes nodig zijn voor het artikelrecord. Nu is er 7ms + een heel klein beetje nodig om 500 bytes te lezen ... Eens kijken, ... dat is dus 48.000 keer zo traag als dat de disk zou kunnen als de diskhead maar stil bleef staan ... (klopt niet helemaal, want je moet ook nog gemiddeld een halve omwenteling wachten totdat het gewenste blok voorbij komt).

Wellicht dat ik hier en daar een denkfoutje maak, maar dat is niet erg, want het gaat slechts om het aantonen van het enorme verschil wat ontstaat als je het niet helemaal goed doet.
Hoe dan ook, een nu berekende 48.000 keer zo traag t.o.v. mogelijk, mag wel leiden tot gemiddeld 100 keer zo traag.

Ik moet hier maar eens een eind aan breien, met de opmerking dat we nog lang niet klaar zijn met het "behandelen" van beïnvloedende faktoren. Denk maar eens aan de enorme overcapaciteit van een disk die rechtevenredig de gemiddelde accesstijd juist naar beneden brengt ! Of de kenlpunten in de CPU als je zoveel geheugen hebt dat de hele database in de cache staat. Of gewoon, het netwerk wat al sinds jaar en dag de bottleneck is !

Zo ver even.

Wij hebben hier Linux, Novell en Windows servers, en die worden alleen gereboot als de stroom is uitgevallen; kennelijk hangt het er vanaf wat  je ermee doet ?
(defragmenteren heb ik hierboven al behandeld).


Niet echt nee. Behoudens dan een lekkere snelle PC met minimaal 3GB intern geheugen zodat je het hele ding nog eens in 10 min. reorganiseert.
En anders SQL/Server.


Iedereen heeft voldoende aan Native VFP, dus jullie dan ook maar.  :smile:
Er zijn echter praktische redenen om het toch anders te willen, zoals inderdaad de 2GB limiet (lees : als je binnen 1 jaar die 2GB aan VORegels weet vol te schrijven heb je geen historie. Ja, op een extern medium wat je erbij kunt trekken als het moet (Profit-Historie)).
Ook wel pracktisch is het kunnen uitvoeren van de backup terwijl je gewoon doorwerkt, of het doen van een upgrade ... idem (w.w.b. het database-deel dan).

Aan de andere kant, "te veel van het goede" kan het ook niet zijn, want zo "te veel" of "zwaar" enz. is het nou ook weer niet. Wel heb je er een aparte server voor nodig en een stapeltje geheugen (+ Profit-SQLSeverTools + SQL/Server licenties). Verder gaat het allemaal best vanzelf hoor.
Voor de disks geldt hetzelfde als hierboven beschreven, met hooguit de opmerking dat wij nauwelijks in de hand hebben / kunnen zien hoe het diskaccess zich gedraagt.

Helaas Peter

Ja gaat voorbij aan wat de essentie is van de verschillende disk systemen

So-wie-so moet je altijd een hardwarematige oplossing kiezen bij welke RAID type je ook gebruikt. Dus een RAID kaart en geen Windows mirrors of zo.

RAID 0 = "STRIPING", het snelste, data wordt over 2 schijven verdeeld, en er is geen extra foutcontrole. Doordat de "traagheid" van de mechanica verdeeld wordt over 2 units is dit de snelste oplossing

RAID 1 = "MIRROR of DUPLEX", Hier gebruik je 2 schijven per set, waarbij dezelfde data op 2 schijven gezet wordt, als continue backup ingeval er een schijf plat gaat. Dit is dus ongeveer even snel als met een normale hard disk werken. (Data ruimte verlies is ca. 50%, je gebruikt immers 2 schijven voor 1 klus) Als er ergens een fout zit weet je echter niet welke van de 2 schijven correct is, tenzij er natuurlijk 1 helemaal dood gaat.

RAID 5 = Hier wordt met een set van minimaal 3 schijven gewerkt, (maar 4 of 5 is beduidend sneller). Middels "slim" dubbelen van de data en het werken met controlegetallen wordt de fouttolerantie optimaal gemaakt. Dit gaat enigsinds ten koste van de snelheid ja. RAID5 is echter gemaakt om heel lang stabiel te draaien en is het systeem op serverparken. En wanneer deze wordt uiitgevoerd in een 4 schijven array met 1 extra hotswap spare zal het systeem als er een schijf omvalt (en dat gebeurt eens per 2-3 jaar op een server) naadloos doordraaien.

De factor 10.000 of zo die Peter aangeeft is niet helemaal correct meer, sinds dat SCSI/RAID kaarten en 15k schijven worden toegepast.
Wij draaien met HP ML servers, RAID5, met extra redundant voedingen en koelingen (Ja we hadden er aardig wat geld voor over) en daar merk je dat bij bv reorganiseren, wat veel data doorvoer geeft,  de datadoorvoer beperkt wordt door de 100MB ethernetverbinding. Daarom hebben de zware users al gemigreerd naar 1 GB verbindingen.

Ik weet niet hoe de rest van jouw infrastructuur eruitziet maar het lijkt me zaak dat je goed jouw performance eisen neerlegd bij de leverancier. Als je trouwens toch bezig bent vergeet dan de backup niet!

Mooi. En geen idee waar je dit uit afleidt.


Ik kan net zo praten als jij hoor : onzin.
Ten eerste heb ik het over hardware matig duplexen waar nooit "mirror" bij hoort. Als je niet weet wat ik bedoel dan zul je een jaar of 20 terug moeten naar de tijd dat (via Novell) iedereen dat nog snapte.

Als jij vindt dat dat ongeveer even snel is als met een normale harddisk werken dan heb je het 100 x 100 niet begrepen. Of je hebt 100 x 100 mijn tekst niet gelezen;
vind je dat mijn tekst op punten niet klopt, dan houd ik mij aanbevolen.

Data verlies is 50% ?
Dan toch niet t.o.v. Raid5 waar het 33% is bij 3 disks. Bij 4 25% enz.
Een argument is dit nooit voor 100 euri 500GB disks waar jij ook 8GB van gebruikt ...

Als er ergens een fout zit weet je niet ... ? Huh ???
Wat voor een fout had jij in gedachten ?
Misschien is het goed om nog eens wat schoolboekjes erop na te slaan, waar het gaat om de foutdetectie in computersystemen.
Zodirekt ga je mij nog vertellen dat je thuis regelmatig fotobestanden enz. verminkt hebt omdat niet kon merken dat er iets fout is gegaan ?
 :biglol:


Mooi ! En jij dacht dat dat met Raid1 niet gebeurde ? Niet vergeten : hardwarematig.


Tja joh, laat ik de 15k met SCSI nou net hebben weggehaald omdat dat zo slecht kontroleerbaar is voor de redelijk willekeurige gebruiker. Maar, het maakt ook geen bal uit. Jij vindt kennelijk van wel;
Wat wilde je zeggen ? een 15K disk draait in 4ms rond en dus zou mijn voorbeeld er slechter op worden ? Mijn oorspronkelijke voorbeeld ging over 15k en 4ms accesstijd.
Als je nou nog eens iets zegt (wat op zich voor iedereen nuttig is), is het dan niet aardig om het ook enigszins te staven ?

Voor de goede orde : wij hebben geen enkele klant waar (door ons !) geen SCSI is gehanteerd. Nooit, in 19 jaar niet.


Tja, je kunt ook gewoon op de server reorganiseren natuurlijk ... (niet-Novell).


Bwaahahahahahaha
En nou ga *IK* zitten wachten op de allereerste Heart-Profit gebruiker die DAT gedaan heeft zonder onze bemoeiienis en die NIET in weet ik veel wat voor 'n ellende raakte. Dit is gewoon objectief hoor. Mag ik een voorschot nemen : van de 100 die zoiets ondernamen in samenwerking met een hardwareleverancier, eindigden er 95 in tranen. Weet je wat, als zodirekt iedereen op het forum is aangesloten maken we er een poll van !
Bij jou in de plaats (straat) zitten er al twee ! Loop er eens langs zou ik zeggen.
Jij hoort gelukkig bij die 5 en dat komt vast en zeker niet doordat een leverancier wist wat 'ie moest doen. Dat kan slechts komen omdat *jij* wist wat er moest gebeuren.

... waarmee ik maar wil aangeven dat jij toevallig best weet waarover je praat. Dat houdt echter niet in dat ik het niet ook weet. O nee, beter weet.
 :smile:

Mijne heren begrijp ik hieruit dat we niet op onze leverancier moeten vertrouwen maar op Bijvoorbeeld jullie Peter.

Opzich heb ik daar geen bezwaar tegen, laat maar horen.
 8) 8)