Jump to content

Web publishing performance issues


This topic is 2944 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Just a further update on my investigations - the below is essentially paraphrased from part of my FileMaker support process:

-----

It appears that the WPE doesn't thread properly, or has some sort of locking/race-condition issue in some cases.

I set up a test suit that attempted to gather performance metrics in pulling up a record via primary/indexed key and the impact of threading/multitasking (ie: what number of simultaneous queries gave the best performance).

To my surprise, I have found that the WPE does NOT answer multiple requests at once, or rather, some sort of locking issue causes them all to be answered asynchronously, ie: 1 query takes 3.5 seconds, 2 queries take 7 seconds, 3 queries takes 10.5 seconds (etc, etc) - See attached PDF for full results. In this case, NONE of the queries respond until all have completed, making it look like there is some sort of race-condition/locking type issue, which explains the terrible performance (in our particular setup).

So far, the problem is 100% replicatable all the time on all machines tested (tried both on single CPU FMSA/WPE combined server and separated 2 x 4 x CPU separated FMSA/WPE servers).

I would hazard a guess that it is due to the number of complex relationships in our particular setup, but have so far not narrowed it down to precisely what recipe of relationships/etc allows this specific problem to occur.

Either way, it does highlight some sort of very real problem with the way the WPE is locking/querying, where it becomes impossible for us to run more than 1 query at a time on a given table via XML.

------

I'd be interested in seeing if anyone else is able to replicate/has seen similar issues with their own FileMaker/WPE/XML setups.

Will let you guys know how I proceed,

Mr F.

FileMaker_non-threading_performance.pdf

Link to comment
Share on other sites

I haven't gotten that detailed with my investigation, but that does seem to be similar to what we're experiencing.

I know you take a large hit with unstored, calculated fields. We had some fields that were being calculated on other calculated fields and it was really taking its toll. We were able to boost performance a little bit by cleaning up some of these calculations so that it didn't use so many unstored fields.

That allowed the actually queries to return quicker, however, the CPU spikes have not been solved. Each query spikes the CPU to about 30%, so you can't get many people using it at the same time. Definitely won't work for live web applications. The same thing happens with ODBC. A single query will be nice and quick, but spikes the CPU.

I've resorted to creating a script that syncs our product data into an Access database and I use that for any product queries.

My checkout system is connected directly to FileMaker and while the same spikes occur during a checkout we don't get many simoultaneous checkouts so I'm hoping it won't cause an issue, but I won't know for sure until we try.

I have to say this is very frustrating. When I was first introduced to FileMaker I didn't like it at all. After having no choice but to work with it it's definitely grown on me and I even began to praise it when I learned about the WPE/XML stuff. But then we've gotten slapped in the face again since we can't even connect it to our web site. :

Hey FileMaker...I know you didn't start out as a SQL based database and I know the XML stuff is new. But you guys are obviously pretty sophisticated. Is this really that hard to fix...???? There's no reason a simple SQL query should spike a CPU to 35% or more.

Please help us out!

Link to comment
Share on other sites

Just adding on to my own findings, here's further info we've worked out/sent through to FileMaker engineering:

-----

Furthering to this, we've been doing some further investigation - We've noticed that the web publishing engine seems to be able to get itself into a state where it will get stuck in a loop of some sort and utilize all CPU's at around 35% forever, until the service is forcibly terminated and restarted.

We've had this a couple of times, including today, where we cut off all external access to the WPE. At this point, we proved there was NO traffic hitting the WPE front end (via netstat) making requests, yet the WPE (wpc.exe) sat utilizing all 4 CPU's non stop, seemingly forever (see attached image, right side of graph).

When this is occuring, the WPE runs VERY slowly - ie: 2-3 minutes to answer ANY request. It also will not terminate gracefully via the services manager, and has to be forcibly killed and restarted to fix the problem.

This does not happen all the time and is separate from our general bad performance issues, but I thought the info may help the engineers track down where the problem lies.

-----

WPE-cpu-graphs-cropped.PNG

Link to comment
Share on other sites

I've experienced these same issues with both the XML and ODBC connections. If you accidentally find yourself throwing an unstored calculation into the mix of your queries then you're screwed.

The CPU spikes and sticks at about 70% on our AMD Opteron and will not stop until we shut down the service.

Link to comment
Share on other sites

  • 3 weeks later...

Here's something kind of interesting regarding the last statement about the CPU sticking until you turn off the service.

I was working on some scripts that I've run many times before. It uses ODBC and it's relatively complicated insert into FileMaker.

Well, I had run about 10 of them with no problem and then the 11th one hung on me. CPU got stuck about 45% and sat there and wouldn't stop. I let this go for about 3 hours with no change hoping that it would eventually just stop without me having to shut everybody out of FM and shut down the service.

Well, it never stopped...until...

I was just about to the point of shutting everybody out and restarting the service when I figure well I'm gonna try another one to see what happens before I do that.

this time, the insert worked without much delay, and when it was done the CPU went back to 0%.

so it seems that running another and getting it to complete solved the problem of the one that was stuck....though the one that was seemingly stuck did NOT end up in FileMaker once the CPU stopped.

So, I don't know if that was a big coincidence or what, but I figured I'd let it be known what happened.

Still waiting on an update for these problems. I've got a checkout system that's working perfectly with FileMaker now about 85% of the time. the other 15% of the time customers complain that when they hit submit and wait a good 3 or 4 min and nothing happens they get impatient and close it.

This seems to be a case of FM just lagging on them because i haven't noticed the CPU getting stuck on a spike from a customer checkout yet.

Link to comment
Share on other sites

I just got off the phone with a FileMaker tech support guy. Used the free support code I got with one of our FileMaker Pro 8.5 clients. I couldn't believe what they told me.

Without getting into a huge schpeal about the whole conversation, he basically left me by saying that "FileMaker knows about the performance issues and it has not been considered a matter of importance."

No joke. Apparently they don't think the business of web developers is important.

Link to comment
Share on other sites

Yes. I called the tech support line from this link:

http://www.filemaker.com/support/phone.html.

There's actually quite a bit to the story. I first called yesterday afternoon and spoke with somebody. Explained everything I've mentioned in this thread and more, and was told "I'll research this issue and get back with you." He gave me a case number.

Today, having not heard anything back I called again. I gave my case number and explained everything over again to this guy. This guy told me he was a web designer himself and he seemed to understand what I was talking about when I mentioned Custom Web Publishing, ODBC, and web applications. This is the guy that told me they knew about the problems but it hasn't been brought high enough on the importance scale to expect anything to be done. He gave me the impression that since the performance hit is minimal in the fact that the CPU only spikes for an instant and then goes back to normal is the reason they don't think it's very important.

They seemingly fail to understand that you can't have multiple people hitting the server in this manner, constantly spiking the CPU leaving it un-usable and resulting in hanging web pages. He agreed with me on this fact and said he'd send me an email in which I could respond with these details, including a link to this thread which I mentioned to him, and then he would flag it and make sure they saw it. So that's good...if it actually happens.

Anyway, I responded with plenty of details only to get an email back that said the email he sent that to wasn't the email in my filemaker.com profile and could not be added to the case. Upon clicking the update profile and logging in I could see that yes, the email was not the same. I tried updating the email but it said that email already in use in another account. So then I tried looking up the password for that email address and it said that account didn't exist in the DB. Even when I left the PW blank like it says could be it said not found.

So at this point I called the tech support line back. I got another guy on the phone who was absolutely clueless. He read over the case information they had and then I once again had to explain everything. He was asking me questions about the CWP and ODBC and kept confusing the 2, and sometimes thought they were the same thing. I ended up having to explain how CWP works through the Web Publishing Engine, which is seperate from FileMaker Server and ODBC, but both ways cause the CPU spike. He then basically admitted he couldn't help me and sent the email to the address that was already in the profile.

So now, I responded to that email and I haven't gotten anything back, which means it should have gone through. I also submitted the problem to the problem submission of filemaker.com for the second time. Firs time was more than a month ago and I never heard anything back.

I also explained to them that my biggest fear right now is that I'm going to create an entire new solution that involves using mySQL as my database for web applications and then importing/exporting to/from FileMaker (which really sucks for many reasons) and then right when I get it all done they release a fix for this problem. How I'd probably just dump FM and use another product if not for my employer insisting on having everything in FM like I know other developers have done because of this exact problem.

Finally, I also praised them for the Custom Web Publishing features because I think that's really cool...but you can't even use it in any actual application because of the CPU problem. I explained that if this was fixed I WOULD choose FileMaker over other databases.

I finished up my conversations with all 3 people by stating that I would simply like some kind of an answer. If they're going to continue ignoring the problem then I'd like to know. If they didn't know was a problem, I'd like to make sure they do know, and how can that be done? If they need any other info I'm happy to help, etc. etc.

So, we'll see what happens. It'd be really neat to just make this work. I've got an entire solution completed and working great...when I'm the only one using it. :B

Anyway, I'm done ranting now. Anything you can do to get any information would be greatly appreciated. Thanks!!!!

Edited by Guest
Link to comment
Share on other sites

No joke. Apparently they don't think the business of web developers is important.

Honest to god, i don't think the support portion of FileMaker thinks that anyone is important -- ESPECIALLY when they bring to their attention potentially serious issues with their software.

Further -- either they deliberately don't follow up things they say they will -- or there's something wrong with the software they use (more likely the first than the second).

FileMaker really needs to re-think the way it treat's existing clients - especially developers.

Link to comment
Share on other sites

I got a call from 2nd tier support tech from FileMaker yesterday. I explained everything again to him and he asked me to reproduce the error, yet again, on yet another machine.

I did this on a brand new install of Windows / FM Server 8 Advanced v4 / Web Publishing Engine. I also installed the ODBC drivers.

I provided them with 2 .vbs scripts that pull data from FileMaker. 1 uses ODBC and the other uses the XML API (CWP). I included my own logs of the CPU spiking when the scripts are run.

I gave them the actual file I'm using, my logs, the .vbs scripts, and detailed instructions on the steps I took to configure everything. They have absolutely everything they need now to reproduce the problem.

He said that if he can reproduce the problem he'll escalate this again to the actual engineers.

I'll update when I know more.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 4 months later...

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. ;)

Link to comment
Share on other sites

  • 6 months later...

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.

Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

  • 5 months later...
  • Newbies

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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....

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 8 months later...
  • 4 months later...
  • Newbies

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.

Link to comment
Share on other sites

  • 1 month later...

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

Link to comment
Share on other sites

  • 3 years later...
  • Newbies

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.

Link to comment
Share on other sites

  • 3 years later...

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

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

This topic is 2944 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.