What are the biggest and best Filemaker-driven sites out there?

[Geeksharka]

Hi all,

I've been building websites and Filemaker solutions for eons, but I usually stay away from combining the two for anything too big, preferring instead for a PHP/mySQL setup, or perhaps Ruby. We have however built a handful of smallish CWP sites, and numerous IWP hookups -- but although some of them are quite nice, none of them is truly large or spectacular.

We've built many an industry strength PHP/mySQL solution, but we now have a few clients that are interested in a full-on PHP/FMP solution, from start to finish. Their first question is, can it handle the load? And their second question is, can you show us some examples?

Well, it turns out, finding good examples is quite hard on Google and various forums (including this one), so I figured I'd drop a post and see what the Filemakerscentia can pull together. What I am looking for specifically are Filemaker driven sites, for content or etail, or both, that run without any bridging or cron scripts to match up Filemaker data to non-Filemaker data (such as mySQL tables). The bigger the data load, the better. Ditto for design points.

Any and all examples most welcome -- and if any 'load' details are known, such as hits or data load, that would be perfect.

Many thanks,

- Dirk Reynolds

ZWARM Intelligence

[bcooney]

I have been on a project that has spanned 2 yrs now. At first it was pure PHP/FM, but it can't handle the load. So, we are moving to PHP/MySQL, and will use both ESS and data dumps into FM.

My advice, don't expect the web engine to handle the load. It would be nice if FMS12 improves this, but we can't wait.

[IdealData]

I have been on a project that has spanned 2 yrs now. At first it was pure PHP/FM, but it can't handle the load. So, we are moving to PHP/MySQL, and will use both ESS and data dumps into FM.

My advice, don't expect the web engine to handle the load. It would be nice if FMS12 improves this, but we can't wait.

Any chance you can give some numbers here - helps to put things in perspective.

[Geeksharka]

I have been on a project that has spanned 2 yrs now. At first it was pure PHP/FM, but it can't handle the load. So, we are moving to PHP/MySQL, and will use both ESS and data dumps into FM.

My advice, don't expect the web engine to handle the load. It would be nice if FMS12 improves this, but we can't wait.

That's good to know, and has been our experience in the past too. Which is why whenever a site needed to handle any serious traffic we'd opt for a PHP/mySQL set up too. I guess I was just hoping that FMP's improved PHP handling in the past few versions would have allowed us to bypass the mySQL component. Not because mySQL sucks (quite the opposite), but because I'd rather use FMP instead if at all possible.

The site we're looking at now is kind of mid-range. Maybe 300-400 cart sales daily, plus of course the basic browsing/shopping interactions, most of which I think we can handle server-side without hitting FMP too much. Not sure what the site's hits etc. are yet, but nothing mind-boggling I'm sure.

I guess we're still on the fence here -- still hoping to see if any FMForum users have any good FMP website examples that are large and/or well designed.

[bcooney]

It is my understanding that it's the web publishing engine that's the bottleneck. This solution is for a competition that has a deadline for submittal (and it can't be staggered). Unfortunately, everyone waits until the last day, and we can't handle about 1000 users trying to submit all at once.

[webko]

It is my understanding that it's the web publishing engine that's the bottleneck. This solution is for a competition that has a deadline for submittal (and it can't be staggered). Unfortunately, everyone waits until the last day, and we can't handle about 1000 users trying to submit all at once.

It is the web publishing engine that is the bottleneck - it's single-threaded. If they ever change that to a multi-threaded engine, then it may be usable.

That said... http://search.pedro.org.au/pedro/findrecords.php runs at least 80K requests a day and rarely skips a beat. So long as you make sure each interaction is as lightweight as possible (in terms of number of queries, size of data returned, using layouts with only the basr minimum of fields on them) then you can manage the issue.

There are times where it simply won't cut it - I have a similar problem with one site that accepts enrolments into some fairly sought after make-up classes - for three days of the year, straight FileMaker locks up, but it would be fine the rest of the time. Due to those three days, it's a mySQL system using ESS for the admin users to use FileMaker.

We run probably about 80 CWP systems, and only 2 or 3 of them are too complex/large/hit too hard for the WPE to handle.

YMMV

Webko

[Genx]

With adequate levels of caching (public and private) it's not really an issue - the fact that you have to plan for this in the first place is an issue though.

If you can avoid it though... do.