Filemaker server 9 met 100 to 125 gebruikers

[williamlagerberg]

Heren,

 

Ik heb bij een klant van mij een redelijk probleem, de snelheid van filemaker laat ernstig te wensen over.

 

Het systeem draaide voor 25 to 50 gebruikers gewoon op een xserve wat goed voldeed ( gehele mac omgeving )

Na een overname waren we genoodzaakt meer gebruikers erin toe te laten de server is geupgrade naar een Xserve Intel met een Xraid.

Het systeem draaide redelijk maar de performance liet te wensen over.

 

Nu begrijp ik natuurlijk dat dit enorm afhankelijk is van het soort database grote en zo. nou neem van mij aan het waren in file maker 5 iets van 30 databases hetgeen terug gebracht is tot 8 databases met de diverse tabellen erin. Er is een filemaker programmeur aan het werk die best zijn vak wel verstaat. Dus in eerste instantie wil ik het puur over de hardware en de mailit pluggin hebben.

 

Om een lang verhaal kort te maken.Door dat de snelheid omhoog moest hebben we het overgezet naar ==> een VM ware server bestaande uit 3 * haast de zwaarste Dell 19 inch die er te koop zijn uiteraard met een heleboel rompslomp er omheen 2 cisco switches een Dell raid unit dit geheel helemaal redundent opgebouwd. Echt likkebaardend lekkerlessend .

Als ik naar de belasting van de server kijk staat hij de hele dag uit zijn neus te eten. als ik met mrtg kijk kom ik in een 1 Gbit netwerk omgeven aan een gemiddelde van 40 a 50 Mbit. We hebben zaterdag alles gefinetuned en vandaag kwam er een opmerking uit het is nou wel weer een stuk sneller , tis weer net zo snel als toen het op de mac draaide voor mij natuurlijk als apple liefhebber helemaal gaaf, maar voor de ict van het bedrijf zwaar ......

 

Een ding wil ik kwijt er wordt email opgehaald dmv mail-it bij alle gebruikers ( op eigen verzoek, een paar maal per dag). deze wordt op email adres vergeleken met de database en gestored bij de desbetreffende klant. Dat is wel een hele grote container (map weet ik veel) aan het worden, de share staat op een aparte daarvoor gemaakte 100 Gbyte ruimte, gekoppeld aan de virtuele server waar filemaker ook in draait. De filemaker partitie is ook iets van 100 Gbyte. het totaal van de databases is 30 a 35 Gbyte. Een backup ( wat we inmiddels door het snelheids verlies alleen nog maar snachts doen koste eerst op apple 10 minuten, op windows voor de finetuning 30 minuten nu 8 a 9 minuten )

 

Even nog een resume finetuning ging om de routeringen in de switches en het correct functioneren van VMware.

 

Nou ik ben benieuwd . William

 

Hoe krijg ik meer snelheid.

 

Eerste indruk ( ben ik voorbij de grenzen van filemaker aan het gaan ??

[Ron9_15]

Lijkt me op het eerste zicht niet dat je beyond the boundaries gaat, het is wel niet duidelijk in je post wanneer FM traag is.Altijd.... bij verwerken mail...

sommige layouts.Als er een dikke logge database tussenzit zou je eventueel met ESS (mysql) een en ander kunnen verbeteren.Heb er persoonlijk enkele van verschillende gigs zonder problemen draaien met een 60 tal users.Kijk ook de instellingen van de server eens na, genoeg memory toegewezen...

Groetjes

[pjotter]

Als je twijfelt over een aantal zaken zul je gewoon alles simpel moeten aanpakken denk ik. De FM server op de Xserve zou eigenlijk meer dan voldoende moeten zijn. Zelf ervaring met een database op een g5 mac met 50 users zonder ook maar een enkel probleem werkt super. De overstap naar de nieuwe servers lijkt mij in eerste instantie overdreven. Je opmerking om je eerst te richten op de hardware en de plugin lijkt mij niet helemaal juist (op afstand bekeken althans)

De plugin kan van invloed zijn maar dat heeft dan toch te maken met de opbouw van de database.

Zorg er voor dat bepaalde zaken niet worden gedaan. (dus zoals al aangegeven de backup in de nacht) mail-it niet overdag maar ook na werktijd. Kijk wat je kunt uitstellen zodat je er achter komt wat een probleem kan geven.

 

Hoewel niet helemaal vergelijkbaar heb ik ervaring met een trage database op een netwerk. Hier ging het om access97 database die 20 gebruikers heeft en supertraag was geworden. Database was echter langzaam gegroeid naar 800 mb (en bij access 97 wordt dan veel data elke keer overgezet over het netwerk). Door de tabellen in de database op te delen, plaatjes /layout's te verkleinen, regelmatig te comprimeren enz werkt het nu weer perfect. Ik denk dan ook dat je in de database moet kijken wat en hoe deze gebruikt wordt en die zien te stroomlijnen. Ik denk dat de hardware in orde moet zijn want als alles eerst op de xserve goed werkte en nu met een complete nieuwe server hetzelfde probleem geeft zou ik die uitsluiten. Geheugen is inderdaad erg van invloed en je kunt er elke keer weer meer geheugen in zetten maar als de database het probleem is zal dat uiteindelijk ook geen oplossing zijn. Succes met het zoeken naar de oplossing

[tackenco]

Hoewel geen goede kennis van servers, netwerk ed. weet ik wel dat FM traag wordt door plaatjes. Sinds nieuwe versies Filemaker is dat erger geworden. Daarnaast heb je last van niet opgeslagen berekeningen op je layout. Helemaal (of vooral) als die plaatjes of berekeningen in een portaal staan. Ook een tabel met opgeslagen files (foto's, geluid o.i.d.) wordt erg zwaar en kan vertragend werken. Je eigen suggesties met de mail-it plugin en het backup proces zouden natuurlijk ook vertragend kunnen werken. Ik heb mij ook laten vertellen dat niet alleen het geheugen van belang is maar ook de snelheid van je harde schijven.

Ik denk wel dat je er samen met de Filemaker programmeur naar moet kijken, het ligt zeker niet puur aan de hardware.

succes, Niels

[WJ]

30 a 35 Gbyte zijn de databases groot !?

 

Veel te groot lijkt me zo. Daar zit denk ik de bottleneck. Sla je binaire data op in container velden of zo ?

Je zult de grote van de database kunnen analyseren waarom zo groot. Zoveel data ? Je bent al je back ups aan het minimaliseren niet echt wenselijk.

Kan je de container data in aparte databases opslaan ? Of liever nog als referentie ?

 

Succes.

 

Groet,

 

WJ

[Peter Wagemans]

Om FileMaker Server zo snel mogelijk te draaien moet je zeker niet naar VMware gaan, zelfs al gebruik je een uiterst snelle machine.

VMware disk I/O is een stuk trager dan native disk I/O. Je kan beter een goedkope Quad Core Dell gebruiken dan een supersnelle rack server, die je dan vervolgens kreupel maakt door FMS onder VMware te gaan draaien. En was het nu dat FMS daar alleen op draaide, maar meestal is dat niet de bedoeling, right?

BTW, FMS met VMware is niet certified door FileMaker Inc., je bent je dus op glad ijs aan het begeven.

Geen woord slecht verder over VMware overigens. Dit forum draait onder VMware. Ik zal er echter geen FileMaker Server op gaan draaien, en zeker niet als die 125 users en 35 GB data aan moet kunnen.

 

Een snelle disk access en een sneller netwerkaccess zijn primordiaal. Meerdere CPU's is op het ogenblik niet belangrijk, maar houdt bij een investering rekening dat dit zou kunnen veranderen.

Voor backups mag je zeker niet op de schijf backuppen waar ook je data staan. Da's logisch. Throughput wordt door 2 gedeeld...

35 GB backuppen op 9 minuten betekent een throughput van 35 GB/540 sec = ~65 MB sec. Niet slecht, maar er zijn disk configuraties die meer dan 300MB/sec halen. Apple verkoopt zo'n kaart optioneel bij de Mac Pro, en... de XServe(). Prijzig, maar je hebt dan ook wel wat.

Het is verstandig om een aantal tabellen te groeperen in bestanden, en een aantal bestanden te groeperen per backup schedule.

Hierbij neem je als criterium: wat is groot en wordt niet zoveel gewijzigd? Wat is groot en kan altijd terug opgebouwd worden? De files en tabellen die hieruit komen steek je bijeen. En backup je niet zoveel. Volgende vraag: wat wordt er druk gewijzigd? Die tabellen en files zijn dus cruciaal en moeten meer gebackupt worden.

Heb je een bestand met sommige tabellen die veel gewijzigd worden, en andere tabellen die weinig gewijzigd worden, wijzig dan de samenstelling van die files.

Wat je met die denkoefening aan backupsnelheid wint, daar kan geen hardware tegen op.

8 files vertegenwoordigen 35 GB. Dat is gemiddeld zo'n 4 GB per file. Waarschijnlijk zijn er joekels bij die nog veel groter zijn. Het is goed geweest om de 30 FileMaker 6 tabellen/files terug te brengen naar 8 files, maar je hebt dat vooral gedaan vanuit het perspectief van 8 "windows" die je gebruikt, je interface dus. Doe nu de volgende stap: houd die interface, maar verdeel die data terug in verschillende bestanden, volgens bovenstaande logica. De fysische tabellen achter occurrences zijn een stuk gemakkelijk verplaatsbaar vanaf 7.

 

BTW, ik heb ooit zo'n Compaq server gezien met een fantastische RAID config met 3 disken, volledig redundant en zo, een zeer hoog James Bond gehalte... en de controller ging kapot.

Aan de schijven kon je niet meer aan ( raid ), en de controller was niet meer verkrijgbaar. Leuk he?

 

 

Genoeg geleuterd over backups. Je kan ook overwegen om 2 FileMaker Servers te draaien, en zo de workload te verdelen. FileMaker oplossingen werken vanaf 7 prima wanneer ze verdeeld zijn over verschillende servers. Zorg gewoon dat je referenties goed staan. Hier ook weer de regel: 2 gewone servertjes zijn een stuk sneller dan 1 mega-server, en weet je wat? Helemaal redundant...

Ronald oppert ook nog om eens te kiijken wat je met ESS kan. Niet zo soepel als de data in FileMaker zelf steken, en een stuk gevoeliger aan problemen, maar je kan er wel een pak weinig gebruikte bulkdata mee weghalen uit de server bestanden en op een MS SQL of MySQL server zetten.

Tackenco heeft het 100% correct als hij je als tip geeft zeker geen plaatjes IN de FileMaker tabellen te steken ( denk ook weer aan je backups! ). En zijn 2de tip is er ook boenk op: vermijdt unstored calcs op je layouts, want die geven een heel slechte gebruikerservaring als ze te lang duren - typisch bij grote datasets.

 

Voorts moet je eens antwoorden ( is het niet hier, dan zeker aan jezelf ) op een andere intelligente vraag die gesteld wordt: WAAR is het nu juist traag?

FileMaker heeft niet de snelste database engine die er bestaat. Snellere hardware is echter de ""quick & dirty" oplossing. Heel wat kan verbeterd worden door de juiste design ( interface/structuur/code ), of de juiste timing van taken die wat langer duren. -- peter