I got another call from the tech. guy just about an hour or so after I sent all of the information. He said that he was able to reproduce the errors on all machines he tried it on and that he would be escalating the case to the next level up...the engineers. He said that this forum thread caught the eye of some the engineers as well (I'd guess that's your doing, thank you again) and that they would be expediting the case.

I'll be sure and keep you posted with any updates I hear.

Occsionally the Ancient One here can still be useful.

Steven

Hi guys,

As a "regular contributor" to this thread, I thought I'd chime back in.

I've been away for two weeks on a FileMaker free holiday, so just catching up on things now -

We still have an active support case with FileMaker, but have heard absolutely nothing back from support for several weeks now (since I last posted).

I'd love to be able to give our DB setup to engineering to replicate, but unfortunately, it's rather huge and complicated.

I'm hoping I can boil it down to a simple/replicatable issue on a smaller/distilled set of tables/data, but the exact profile that causes our problems to occur is obviously complex enough that it hasn't been found by FileMaker's normal/in-house testing or from enough other customers that they're aware of the problem.

This now appears to be the main thread on the internet (according to google) about WPE/FM performance issues, so hopefully together we can help FileMaker sort it out.

More news as it happens...

Cheers,

Mr F.

I just created a new file and added 2 fields to it and then exported only those fields from our actual system. This gave me a single file with approximately 115k records in it, 3k of which were marked as 'Current' and that's the example I used to show them the CPU spikes.

He was able to reproduce it on all his machines. I haven't heard anything back from them as of now. I'm going to call them again tomorrow.

I was looking through my subscribed threads here and figured I'd add another statement to this one. I never did hear anything good from FM. They kept running me around in circles making me to talk to different people, re-explaining the entire issue just to hear the same answers over and over again....which really was no answer.

I figured I'd go ahead and let you guys know what I've done to get around this problem....which is basically to use a different database for the web stuff. A sad scenario for FileMaker as if it wasn't for my boss I'd ditch this crap and start over with a DB that actually works.

Anyway, as it stands now, I have an Access database that is used for the web site. While ODBC connections with FM spike no matter what, the only real problem with this was during a customer checkout on the web site.

When the checkout system began to insert all data into necessary tables it had to hit FileMaker a number of different times, spiking the CPU each and every time, and would lag horribly as we've all discussed.

With Access as the DB on the web now that does not happen and all the data inserts with the snap of your finger. So then the only problem is getting this data into FileMaker.

In order to do this I'm still connecting to FM via ODBC, however, I'm simply pulling all data from all the tables in Access into filemaker 1 table at a time. This way it's really only 1 hit per table.

So, my Access tables mirror my FM tables (customers, addresses, invoices, invoice items). The "thank you" page in my checkout system calls a script in the background that imports all data from these tables where ImportedToFM = 0.

So what happens is a person checks out online and his single order ends up in the tables with ImportedToFM = 0. Instantly, the data gets imported into FM and does not cause any problems since it's only 4 hits.

So as it stands now I have orders coming into FM in real-time and it doesn't lag or slow down FM in the least.

It's just sad that it takes another product to make it work.

I've read some information that FM9 is going to include a way to attach to MySQL databases, however, it doesn't look like it will actually let you design the MySQL db using FM tools. So you'll still have to completely the design the whole thing using MySQL and then create layouts in FM to attach to it.

In my mind if I'm creating a database in MySQL I'm just gonna use a web front-end rather than buy FM Pro for all my users.

I'm still completely amazed by the fact that FM seemingly doesn't care about this situation, but what can ya do. Just use a better product I guess. ;)

Have any of you kept your eye on this thread? I just got an email from somebody at FileMaker saying they're going to have an engineer call me. I doubt anything will be different than last time but we'll see.

what's funny is that FM9 doesn't fix the problem...they simply made it a little bit easier to do what my last post explains I did to get around the problem. By connecting the 3rd party DB directly to FM it may have saved me a good 5 min or so. LOL.

well, as expected, no help at all. Is anybody still following this thread? I've got some funny information I could post here but I won't waste the time if nobody is following along anymore..??

Hey there DrewAngell,

Long time, no responses, eh?

I have to admit, my experience with FMP/FMP support was exactly the same - We got the issue escalated umpteen times up to engineering, both directly and through one of the leading accredited developers here (Australia).

We got absolutely no movement though (or indication as to what might actually be wrong).

Without wanting to give away any exact specifics, I actually got as far as meeting people VERY high up in engineering/Asia-pac operations (think somewhere near the top).

They basically apologised for the lack of support and the fact that the product didn't work and said they were going through a difficult stage with support of going from a desktop app to a (supposedly "enterprise") server product.

The upshot was, it doesn't work properly - there are known/unfixed bugs, and the answer (at the time - this was a while ago) was basically: "Maybe wait until FMP 9 comes out and use the remote data source feature instead".

Very poor service overall IMHO. We to are basically switching to an entirely different platform because of the awful integration performance.

Cheers,

Mr F.

Just in case anyone is reading this thread. The problem does not seem to have gone away in FileMaker Server 9 Advanced. We are a VLA user for FileMaker and seriously considering moving our HUGE FileMaker system that has been in use for 6+ years to a MySQL solution with a Web UI.

Contact your FMI Sales Rep and ask for help from one of the Systems Engineers.

Steven

Agreed. I still say that the problem is the CPU spike that occurs with each and every single call you make to FM whether it's ODBC, XML, or PHP API. One simple call spikes the CPU to 60%+ on high end servers. Throw in 2 or 3 calls at once and you're officially screwed.

FM techs reproduced this problem way back when I was originally trying to deal with them about it. The only answer I ever got was, and I'm not kidding here...

"Don't worry about the CPU spike. The problem is performance. How can we make performance better for you?"

I'd say...uh...fix the CPU spike. Again, they'd say ignore that how can we make performance better. We went around in circles with this for a long time.

I started asking why Acces, MySQL, SQLServer, or any other DB package doesn't spike a single bit when you make basic calls to it and they just said "now you're comparing apples to oranges".

They refuse to fix the problem and when it doesn't work correctly they tell you that you must not be programming it correctly.

I've tried this in FMSA8 when the XML API was the only thing availble. I had ODBC scripts and the XML API scripts written manually that they looked at and confirmed were written correctly. Now I've been trying the PHP API manually and also with the Dreamweaver Extension FMStudio available from FMWebSchool.com.

Fix the problem? Absolutely not. I've tried calling FM techs a number of times throughout this past year, or two..?? Can't even remember how old this thread is now I'll have to look.

Anyway, they just laugh at me and tell me that I don't know what I'm doing. No joke, one tech litterally told me "we all got a nice little chuckle out of what you've been saying here." That's FM techs answers to their problems so I think your move to MySQL is probably the best bet.

Which reminds me, that is one more thing they'll tell you on the phone. They'll try and tell you how great FM because it now has external data sources and you can attach MySQL databases to FM and use them within FM that way.

When I stated that the feature was pretty cool, but not good for a solution to this problem because if I'm going to re-develop in MySQL anyway then I'll just use MySQL and ditch FM entirely. He said "That's fine."

They have no desire to fix this problem from my experience. The same tech that told me I wasn't doing it correctly claimed that he himself was using FM the way I'm trying to (dynamic lookups of products in categories and dynamic shopping cart, etc) and he gave me a sample web site to look at that he claimed was dynamic. When I went to his web site, though, all of the product pages were static .html pages with the products hard coded into the source code. When I told him this was not a dynamic site they laughed some more.

I gave up at that point and told my client that if they want to stick with FM that's fine but I'll have to re-develop everything in MySQL and then attach it all to FM and development time will probably be twice as long because of re-creating the loop twice basically.

Oh dear....that means I've got no chance in FileMaker aclling me with a solution. I've raised a support issue regarding a stock installation of PHP and FMSA 9 working with SSL. I've had case number for almost a month with no reply - why on earth do they CHARGE for this lack of support!

My workplace have a huge installation of FileMaker too (2 servers with over 500 clients) and our IT dept are thinking of moving to Sharepoint....

Yeah, I wouldn't count on a response. At least not a worth-while one. You'll have to keep bugging them to get anything. Don't just let it sit there this long without hearing anything. Keep calling and bugging them if you actually want to get some "answers". However, as I've mentioned, there "answers" to this problem aren't good ones anyway.

I've seen a lot of people mention moving big accounts like this to another DB server and when I tell that to FM people they just say Oh well. Then I say something like "I can't believe you guys will just say Oh Well instead of actually looking into this problem and fixing it. If you'd just fix it this would be a SWEET database server!"

That's when they just tell me again that it works fine and I must be doing it incorrectly.

Anybody had a chance to test out FMSA10 yet???

I just upgraded my FMSA9 system to 10. It had been running for about a year without too many issues, but then in the last few days under "heavy" load (3 or 4 simultaneous users), I would get 100% CPU usage for up to a minute. Usually under this load, I would just get time outs and everything would return back to normal after a few minutes, but this time it never recovered and even the admin console was malfunctioning. So that prompted me to upgrade.

I'm only a few hours into the upgrade and server load is still heavy but CPU usage only spikes to 100% once in a while and doesn't stay there. Load average is: 0.39, 0.33, 0.32.

It's still way too early to tell whether this will sustain but so far it looks promising. This thread is really old but I would love to hear from others who have upgraded to 10.

http://fmforums.com/forum/showtopic.php?tid/201061#333076

I can't believe how old this thread is.

I've been having the same problem on some of our servers.

I wish I had the time to spend on investigating and logging our server to put together a case and call FileMaker as well.

Please advise on how to document the issue.

I work for a company that has a fairly large account with FileMaker (we have over 4000 installations of FileMaker and I support about 7 servers). I'd like to refresh this case and throw our company's weight on this as well.

In the absence of actual logs here's how I'd describe the situation:

It seems that CWP web sites are usually running smoothly for a few weeks only to come to a screeching halt later. Once the performance is excruciatingly low I have to bounce the server and then everything is ok. So, I would say that there's something that is building up on the server that causes the slowness.

Strangely our server are restarted every night, so you'd think that whatever builds up would be cleared. That doesn't work, I have to bounce the server when it is slow, period.

We're running everything on virtual machines with Windows 2003 Server SP2, FileMaker Server 9 with nothing else on the machines.

Rant: At this point I'm disappointed with how FileMaker server has evolved since it's 7 version, as far as I am concerned it has been declining since, with no relative improvement at all, except maybe UI. I'd like to point out that in fms7 you could use one console to connect to any server vs. having 7 icons/links to connect to different servers. fms8 came about and external authentication ceased working, that was never fixed, we skipped that release.

FMS9 came out and here's what we get:

- external authentication for the console is not working

- WPE has major issues as documented in this thread

- Java implementation of the console ceases to work if java is updated past v. 1.6.0_7

Folks,

 

Have any of you made any traction with this problem?

 

I JUST called Filemaker Support and he literally told me, without asking platform, version of Filemaker, even what I was doing...

 

"We're not web developers."

 

When I asked to talk to someone who DID know something about the WPE, he said there's no one here...we don't do web.

 

He claimed instantly it wasn't Filemaker - that our website was coded wrong, and to play with the Sample file.

 

He also claimed, again without even looking it up, that this issue has NEVER been reported before.

 

I basically hung up on him.

 

If any of you that had pull before are still listening, nothing has changed supporting this bug.

 

We consistently see nearly every day WPE take off with the CPU and bring our WPE pages to a screeching halt. 

 

We've been with Filemaker since before Server was around - but much more of this, and I will be looking to change to another solution to host our AMS. Website integration is too important and necessary these days for Filemaker to offer a product and then refuse to support it. FM is laughed at as it is in the Association Management Software space anymore. I usually stick up for it, but I'm getting tired of babysitting a rogue process with no help.

Hi all,

Just some observations on this that may interest those still wrestling this.

We are using FMS12v3 Advanced Server on Windows with 2 servers (DB + PHP/WPE)

First off, we got trapped on a 32-bit VM for the web server due to plug-in compatibility issues. This in itself caused us big problems when the server was busy. The WPE process was constantly maxing out memory as it could only address 2GB.

We finally fixed that and after a very painful process of deploying FMS12 onto a new 64-bit web server (which took about 10 attempts and some messing around with bindings and PHP settings) we hit a new problem with performance. After a while we realised that we had made a big mistake and put a calculated field on the home page layout (i.e. the first layout that the CWP code used to get important details on the client). This did not just slow down the user trying to log in, it made every other WPE user pretty much stop. We started watching the Admin stats on the main Filemaker server console and could see that, at login, the WPC client was generating something like 8000 remote calls. The WPE basically never got past this. You could wait pretty much forever and the login just did not complete and the WPC calls stayed nailed up there. The calc in question field was looking at what the client logging in currently owed us in outstanding invoices, and some of our clients have 100s of invoices, so the calc was particularly hard for our biggest accounts.

After putting 2 and 2 together and realising that this field was causing the problem, we took it off the layout and instantly the logins worked again. The WPC remote calls count would not exceed 50.

We found some other processes that caused issues. If we had a layout that CWP was using and that layout had lots of data from related tables on it, again, the WPC remote calls would rocket, so we had to clear up those layouts and go get the related data another way via native layouts.

We found that calling lots of records, even those with all native table fields of course caused the WPC call count to go high and performance to completely nose dive.

The most important thing though was that the performance when the WPC remote call count goes high is just completely non-linear. At some point the server would get past a sustainable remote call count and just die and never come back. The only way to fix it was to turn off the web services from the FMS console. Note, restarting services on the web server itself did not clear the WPC remote calls! Filemaker Server had to do it from the console.

Also, interesting was that, in most cases, even when Filemaker Pro clients where connected and doing something horrible to the server (like a massive replace operation, or rendering lots of summarised data) the remote call count on that client (say 10000 or more) would not really impact the WPE performance. The only thing that we suspect can interfere is an import from Excel or CSV but that is a suspicion and we are going to test it again now we have removed the suicidal calc fields from the CWP layouts.

What is a shame is that Filemaker Server can't handle these things gracefully. Unstored calcs and related fields can just kill the server stone dead. It a pretty big issue to workaround, but our findings so far are that so long as you steer clear of these, run on a 64-bit server with 4GB+ of RAM and at least 2 vCPUs, then you should see reasonably reliable performance.

Michael

This a is a really old post to resurrect...

I will note that a lot of this has existed since WPE was first added. And that's because almost zero has changed in it since.

It is a single-threaded process. Which means one bad query will make everything else wait.

And a bad query is as you described above - a massive calc field, related fields on the layout, portals, extraneous fields on layouts.

Personally, after many years building FM Based websites, I look at the expected load and just won't used straight FM for a site with anything more than about 500 queries a minute. And that had better be a pretty slim tight database.

After that, I use a MySQL table for web interactions and ESS back to the FileMaker system (if they have a pressing business need for using FileMaker as the GUI)

On 12 October, 2006 at 2:09 PM, Steven H. Blackwell said:

What amount of RAM do you fellows who are having this problem have installed on your Servers?

From 16 to 512GB, the amount of memory does not appear to have any impact when it comes to XML queries.

What you can probably do is to make sure you are not having any related data in your query, WPE usually answers more quickly if you do 3-10 queries with no related data; one for each table in question than 1 query with related data.

Also setting up a reverse proxy using nginx can be a solution.

Personally I gave up on the FileMaker XML for CWP for production environments, I built server side scripts that exports all modified data from FileMaker and INSERTs/UPDATEs to postgreSQL database using server side scripts; I have just recently become aware of the PostgreSQL FDW approach using JDBC, in which may or may not be a much better approach than any other.

Sad to say WPE performed better with FileMaker 6 than FileMaker 7 - 11, not sure about the newer ones.

Edited March 7, 20169 yr by ggt667