FileMaker PHP API traag...

[andries]

Beste forumleden,

 

een kleine oproep van een man met de handen in het haar.

 

We hebben een file die we ondervragen via de PHP API van FileMaker. DIt gaat ongeloofelijk traag (10 sec responstijd voor 100 records met 2 velden, beide geindexeerd).

 

Ik denk dat ik er alles heb aangedaan om de file te optimaliseren voor een request via PHP.

- aparte Table Occurrence aangemaakt, zonder een relatie naar een ander veld.

- layout aangemaakt die op die table occurrence is gebaseerd, met enkel die twee velden op, er is geen enkele relatie aan deze TO gelinked...

- opstart script voert direct een exit script uit als de file via PHP wordt ondervraagd (zelfs opstart en afsluitscript helemaal gedesactiveerd helpt niets)

 

 

Als ik de tabel importeer in een nieuwe file, en deze ondervraag, dan gaat het weer supersnel... dus het ligt naar mijn mening niet aan de data. Ook niet aan de server ( Windows 2003 ) want andere files gaan wel goed, ... heeft iemand enig idee waarom dit zo traag kan zijn?

 

Echt alles al geprobeerd, zelfs een nieuwe tabel aanmaken met slechts 1 veld resulteert in dezelfde trage respons. Het is echt precies de file die ongeloofelijk traag is. In hoeverre heeft de grootte van de file een invloed op dit alles (file is 800Mb groot)?

 

Ook al rechtstreeks met SQL (via ODBC) requests gewerkt, en ook daar is het hetzelfde verhaal: traag...

[dudematters]

Ik vermoed dat dit te maken heeft met de grote van het bestand, wellicht dat je het moet limiteren. Op http://sixfriedrice.com/wp/up-to-speed-with-the-filemaker-php-api/ las ik dit, niet direct antwoord op je vraag maar ik vermoed dat je het in die richting moet zoeken, Filemaker haalt eerst alle data op voordat het verwerkt wordt, en dat kan bij grote bestanden erg traag worden.

 

Paging Through Records

Sometimes you have so many records in your database, that it isn’t realistic to put them all on one web page. The find command object has the ability to limit how many records are returned in cases like this. You give the find command a skip value and a max value. For example, if you want the first 100 records, tell it to skip 0 (zero) and include a max of 100. To get the next page-full, perform the same find command again, but this time set the skip to 100. The max should be 100 again. This time FileMaker will give you records 101 through 200. You set these parameters using the setRange method on the command object:

$cmd =& $connection->newFindCommand('My Layout');

$cmd->addFindCriterion('Last Name', 'Coffey');

$cmd->setRange(0, 100);

$result = $cmd->execute();

In this example, the skip value is 0 and the max value is 100. If you don’t call setRange, FileMaker includes every record in the result. For large sets of records, this can be very slow.

[Jeroen Aarts]

We hebben een file die we ondervragen via de PHP API van FileMaker. DIt gaat ongeloofelijk traag (10 sec responstijd voor 100 records met 2 velden, beide geindexeerd).

De Web Publishing Engine van FileMaker is niet zo heel snel, maar dit lijkt me wel abnormaal. Uit je beschrijving valt niet helemaal op te maken of je gewoon een reeks records opvraagt, of dat je nog wat anders doet (bv script laten lopen).

 

Ter info: sowieso wordt bij een verzoek via de FM PHP API niet het script uitgevoerd dat ingesteld is om bij het opstarten van het bestand (via FM client) te lopen. Dat zou ook wat al te gek zijn, aangezien HTTP requests via dez FM PHP API, gericht aan de WPE, "stateless" zijn. De WPE houdt voor CWP met PHP geen sessies bij (voor zover ik weet), en interesseert er zich niet in of bv. 2 opeenvolgende verzoeken van eenzelfde dan wel een andere client (browser) afkomstig zijn.

 

Desalniettemin, om alvast een mogelijk probleem met de grootte van de file te omzeilen, kan je nog proberen om een apart bestand aan te maken, via een file reference te linken naar je originele bestand, en in het nieuwe bestand een TO aan te maken. Je PHP verzoeken richt je dan op dit nieuwe bestand.

 

De passage waar Dudematters naar verwijst heeft m.i. gewoon betrekking op het opdelen van grotere recordsets in kleinere stukken, via paging. In jouw geval vraag je slechts een beperkte reeks records op.

 

Jeroen

[tackenco]

zaken die echt zeer vertagend werken zijn niet geindexeerde berekeningen en plaatjes (containers).

 

mijn ervaring bij het ombouwen van een webshop gebouwd met filemaker en xslt naar filemaker en de php api is dat de methode niet heel erg snel is maar in principe wel redelijk normaal moet aanvoelen. Ik had echter wel vergelijkbare problemen. Doordat het lang duurde voor dat je een resultaat zag gingen mensen meerder keren op de zelfde knoppen drukken waardoor naar mijn idee een bug naar voren kwam en de server om de haverklap vastliep. Ik heb dat voorgelegd aan Filemaker.

 

Dit was hun reactie:

First of all, your programming is not really the bottleneck in this situation. (at least not immediately) and more likely the WPE is at fault.

 

The main issue you are currently facing is that the WPE has no ability to queue up requests they simply get thrown on the stack and the more on the stack the more of a "slice" it takes.

Each time there is a concurrent request it has to take time to work on ANYTHING in que. So the larger the que the LESS each task gets worked on at any one time.

It is not that it has to finish each request before moving onto the next, that would actually be better, it's that each request competes with the others for a slice of time.

Hun oplossing was deze:

Knowing this, you can improve performance in a limited number of ways :

On the back end : Optimizing the DB and removing all unnecessary dependencies, calcls and controls.

On the Front end : To deal with concurrency and assuming you do not need to run Scripts from the Web Clients, you could change the system to use JDBC/ODBC to go to the database engine directly and hence short circuiting the WPE.

You can also try an hybrid solution with a mix environment for Web and for front end

Niet leuk voor mijn klant die al het nodige had geïnvesteerd in iets wat dus niet zou gaan werken. Ik heb de belangrijkste tabellen in mysql gezet en deze middels een ODBC koppeling in Filemaker geïntegreerd. Nu werkt het uitstekend.

 

Groet Niels

[Jeroen Aarts]

Niels, Dit strookt met onze ervaring met de WPE. In heftige productieomgevingen, met veel website bezoekers en vanaf een bepaalde grootte van de databank, daalt de performantie van de WPE snel. In deze omgevingen werken we meestal met een "online" MySQL databank, en synchronisatie met de FM databank.

 

Jeroen

[andries]

hartelijk bedankt voor de vele reacties!

 

Gisterenavond nog tot laat getest en vanalles geprobeerd, en het probleem ligt echt bij de file vrees ik.

 

We hebben vanalles geprobeerd, dit zijn de voornaamste resultaten:

1. Nieuwe file aanmaken en de tabellen opnieuw geimporteerd: super performantie, zoals het moet

2. Nieuwe file aanmaken met 1 TO van de originele file: en hier is het bizarre: hij toont gewoon niets, het lijkt alsof hij een lege tabel ondervraagt. Dus toen dachten we: XML requests en External Data Sources werken blijkbaar niet.

3. Dezelfde nieuwe file, maar dan met een link naar een andere grote en complexe file: fluitje van een cent alles werkt.

 

Onze conclusie is: we zitten met een corrupte file (hebben naar al de authentificaties gekeken en dergelijken en die zitten schijnbaar goed)... Mijn idee is dat de index corrupt is...

 

We gaan dus ook in het verhaal van een aparte database stappen en synchronisaties met het hoofdbestand.

 

Een zijvraagje over de PHP API. Deze is gebaseerd op XML requests, en het enige wat de API doet is die omzetten in Arrays (neen?). Als ik het goed heb begrepen maakt de server een xml bestand aan dat dan dient om de Arrays op te bouwen. Is dit bestand ergens te vinden of is dit niet echt een fysiek bestand dat wordt aangemaakt (sorry als dit echt een domme vraag is )?

[Jeroen Aarts]

Achter de schermen doet de PHP API inderdaad niets anders dan XML requests plaatsen bij de WPE (via curl?!), en deze worden ingelezen in de nodige objecten (records, recordsets, ...). Deze xml requests zijn net dezelfde als degene die je gebruikt om zelf rechtstreeks xml op te vragen bij de WPE, bv.

http://www.example.com/fmi/xml/fmresultset.xml?-db=test&-layout=test&-findall

 

Jeroen

[andries]

Het is idd via curl dat dit gebeurt (als ik FM Forums moet geloven toch). Maar dus het bestand wordt niet fysiek aangemaakt, maar het geeft gewoon een xml structuur terug?

 

Hoe werkt het dan met ODBC/JDBC? Ik dacht echt dat dit het heilige graal zou zijn (zeker na update naar FileMaker Server Advanced 11), maar we hebben daar dezelfde traagheid. We hebben dezelfde tests gedaan, en enkel bij die specifieke file is het traag. Is het daar ook zo dat op moment van de connectie hij al de data (informatie over de file) moet inlezen en heel de file opstart?

 

In het vervolg moet die sessie over ODBC/JDBC op FM Summit niet als laatste vallen, als ik al moe ben van de vorige sessies, dan zou ik hier mss zelf op kunnen antwoorden .

 

Anyway, we kunnen hier nog lang over doorgaan, maar ik vrees dat de enige oplossing op dit moment voor ons is om

a) een correcte backup te gaan zoeken, die niet corrupt is

b) toch een extra database te gebruiken voor de website als dit de snelheid niet verbeterd

 

In ieder geval bedankt voor het meedenken!