Super trage connecties naar Filemaker Server

[livio]

Hier op den bureau hebben we regelmatig het probleem dat een aantal mac's (een 10-tal) heel traag connecteren naar de FMP Server (FMP 5 server op OSX client).

 

Die probleem-mac's zijn allemaal nog OS9 clients (5.0v3). Op de OSX clients (5.x & 6.x) hebben we geen merkbare problemen.

 

Openen van een simpele database op de FMP server kan soms tot 10 minuten in beslag nemen (evenals het klikken op 'hosts' om de lijst van db's te krijgen). Als er dan aan die DB gerelateerde db's hangen duurt het weer een hele tijd voor die ook openen.

 

Andere mac's (zoals de mijne) hebben hier helemaal geen probleem mee en openen de db's in kwestie op enkele seconden. Het rare is dat dit probleem zich niet altijd voordoet. Iedere paar dagen kan dit voorkomen, op bepaalde momenten van de dag... Soms hebben we weken dat alles goed loopt.

 

Ik denk dat dit misschien aan ons netwerk zou kunnen liggen, maar heb er geen idee van hoe we dit kunnen opsporen of oplossen. Het netwerk is een 100MB netwerk met shielded Cat5 FTP UTP kabels. We gebruiken 1 grote switch/hub waar alle machines (en een internet-router) op toekomen.

 

Iemand een idee ?

[De Foemper]

Ik denk dat dit misschien aan ons netwerk zou kunnen liggen, maar heb er geen idee van hoe we dit kunnen opsporen of oplossen. Het netwerk is een 100MB netwerk met shielded Cat5 FTP UTP kabels. We gebruiken 1 grote switch/hub waar alle machines (en een internet-router) op toekomen.

Hmm, inderdaad het genre van probleem waar je wel eens een tijdje mee zoet kan zijn. Mijn eerste idee zou ook richting netwerk, dwz routing edm gaan.

 

Twee suggesties:

- teken even de topologie van je netwerk en leg het voor aan een network engineer (of doe een poging hier op het forum)

- wanneer het probleem zich voordoet, Cancel en test meteen met een andere applicatie (file sharing, of zet er even een ftp server op), test dit ook wanneer je wel goede performatie haalt. Kwestie van te weten of het FileMaker-gerelateerd is of niet.

 

DF

[Duckie]

We hebben hier ook een tijd last van gehad. Het blijkt dat als je het servervenster op de host actief laat staan de performance aanzienlijk toeneemt. Dat is in ieder geval voor Mac zo, Windows? Geen idee!

[Sanne]

FileMaker als actieve applicatie op de Mac-server is, meen ik, alleen van toepassing onder OS 8/9: daar is aanzienlijke performance mee te boeken.

 

Ik dacht ook begrepen te hebben dat dit onder OS X geen punt van overweging meer is: voorgrond- of achtergrondapplicatie maakt voor de performance niet meer uit.

 

Onder Windows is dit in zijn geheel zelfs niet van toepassing.

 

Zou graag hiervan bevestiging horen.

[livio]

da's inderdaad zo... voorgrond of achtergrond ... maakt niks uit voor de performantie ! dat is dus zeker de oorzaak van ons probleem niet !

 

Ik dacht eerder aan het volgende : als je op 'hosts' klikt stuurt FMP client volgens mij een request uit via UDP via een broadcast-adres (naar alle beschikbare machines op de LAN). Als die antwoorden op poort 5003 dan zet hij deze in de lijst van 'beschikbare FMP servers' zodat je dan een DB kan aanklikken en openen.

Zou het kunnen dat het krijgen van antwoorden van bepaalde machines op de LAN (via UPD) zo lang duurt dat FMP hierdoor traag is bij het tonen van zo'n lijst ?

 

 

Livi

[dannydv]

FileMaker als actieve applicatie op de Mac-server is, meen ik, alleen van toepassing onder OS 8/9: daar is aanzienlijke performance mee te boeken.

Ik dacht ook begrepen te hebben dat dit onder OS X geen punt van overweging meer is: voorgrond- of achtergrondapplicatie maakt voor de performance niet meer uit.

Onder Windows is dit in zijn geheel zelfs niet van toepassing.

Zou graag hiervan bevestiging horen.

Inderdaad Sanne, dit zal iedereen hier wel kunnen bevestigen Dit was enkel een Mac OS 6/7/8/9 fenomeen. Mac OS X heeft daar gelukkig een einde aan gemaakt

[dannydv]

als je op 'hosts' klikt stuurt FMP client volgens mij een request uit via UDP via een broadcast-adres (naar alle beschikbare machines op de LAN). Als die antwoorden op poort 5003 dan zet hij deze in de lijst van 'beschikbare FMP servers' zodat je dan een DB kan aanklikken en openen.

Zou het kunnen dat het krijgen van antwoorden van bepaalde machines op de LAN (via UPD) zo lang duurt dat FMP hierdoor traag is bij het tonen van zo'n lijst ?Livi

Ik ben het eens met je beschrijving Livio.

Er is natuurlijk wel een manier om na te gaan of dat de reden is.

Wat als je je databases opent door te connecteren naar een absoluut ip adres ?

Ik bedoel, je maakt een starter filetje waarmee je rechtstreeks connecteert naar de server door het aangeven van een ip adres en de checkbox save relative path to file uit te zetten.

Ik heb gemerkt dat dit op de Mac een erg grote versnelling te weeg brengt bij het connecteren naar de server vanaf een OS X client.

Bij een Windows PC heeft dit geen snelheidsverschillen tot gevolg.

[livio]

dat was ik er vergeten bijzetten in mijn vorige post, maar het is idd zo. Wanneer we die snelheidsproblemen hebben, gaat het wel snel indien we direct een IP van een FMP server aanduiden. Dan komt de lijst van gesharede db's er direct op !

 

Livi

[livio]

Net gevonden :

 

 

 

Het probleem stelt zich enkel met FMP 5.0. Ik heb een aantal machines geupdated naar FMP 5.5v1 en het probleem is op die machines opgelost... vreemd toch?

 

Zitten er netwerk related updates in de 5.5 ?

 

 

Livio

[BasB]

Bij een klant van ons ook twee trage pc's via een vast IP bestanden laten openen in plaats van kiezen uit de lijst met de door FM gevonden hosts. Dit schijnt ook bij hen de oplossing te zijn.

 

Het lijkt erop dat de PC bij elk bestand dat geopend wordt, weer opnieuw de lijst met hosts moet gaan zoeken en dan pas het juiste bestand kan openen. Deze lijst (of het pad naar het eerst geopende bestand) wordt blijkbaar niet ergens 'onthouden', om voor volgende, te openen, bestanden te gebruiken.

 

Wellicht dat dit bij de andere werkstations wel gebeurt, waardoor deze vertraging niet optreed.

 

Even een theorie in de groep gooien danmaar.

Stel dat FM ergens in een temp-bestand de paden opslaat van huidige netwerk connecties (zoals het mapen van netwerkdrives op PC), maar dat omwille van schrijfrechten, de PC's of huidig ingelogde gebruiker dit bestand niet kunnen benaderen?

 

Blijft het wel vreemd dat bij onze klant dit probleem zich niet consequent voor doet, maar eens in de x maanden een week lang ofzo.

 

Enfin,

Groeten, Bas