Bit more detail would help get better quality answers, and the title to your question does not reflect the actual question you asked.
To do what?
What do mean by via the web?
How many at the same time?
How long is a 'session' likely to be?
Yes sorry about that. Users will logon via the web (anywhere in the world) using a browser on desktop or mobile to enter data in fields, create a user account, create records, delete records, sort records, print, save as PDF etc. Number of connections at any one time could be 2000-3000 - sessions could last a few hours although there will be a timer.
I have experience of small database setups in Filemaker (5-10 users) so this is beyond what I know. I have access to PHP programmers though.
This is quite the undertaking. Do your php programmers have experience with this sort of website (with any kind of database)? Do they know how to optimize a website to limit the actual connections to the database (any db)? Do your php programmers and/or website host know how to handle so many concurrent connections (hardware, web server apps, etc.) as there is a lot more to this size/type site than the database & PHP. Do your PHP programmers understand FMS as well as other database? Where do you get the estimated number of sessions?
The PHP guys want to use MySQL but I am just seeing if the principle of 2000-3000 users at any one time is possible using FM and PHP. I don't think they have experience with FMS though.
I suppose I am just asking whether FM + PHP can do this without some mega licence from Filemaker. Does PHP circumvent the need for a Team licence from Filemaker?
Apols that its a bit vague, I am exploring the possibilities before writing a report.
explore the possibilities with *any* database and then come back with answers to my questions. If they cannot answer, then the database is not a factor!
and then decide how FileMaker needs to be used instead of (or in addition to) MySQL.
You could use the efficient PHP connections to FileMaker for thousands of connections if you design the PHP calls and optimize for internet, but this is true of any database including MySQL. Keep in mind most PHP developers learn first using MySQL often because it is a free database and therefore useful for teaching with minimal costs. Sometimes they will use other open source database, but rarely are they initially taught on commercial proprietary databases like FileMaker, Microsoft SQL Server or Oracle.
PHP for FileMaker has some conventions that a PHP developer has to know such as selecting a layout to base things on to set context, etc. So hiring any old PHP developer that has no experience with FileMaker will mean a learning curve for them due to their lack of knowledge and experience, not that it doesn't work in FileMaker.
MySQL is a very fast database and very scaleable for high numbers of transactions. I find few PHP developers that know much more than how to connect (create,edit,update,delete) to a MySQL database because they are not database administrators. A lot of what we are talking about goes back to database administration. MySQL can be scaled bigger than FileMaker for simultaneous transactions if you have a database administrator who knows how to configure it correctly. Other issues that PHP developers that are not also database administrators tend to have issues with are security configurations. MySQL is one of the most vulnerable databases out there according to the National Vulnerabilities Database. MySQL databases set up by web developers that are not database administrators can be a real vulnerability. But I see it all the time for web solutions.
If you have the option to utilize a PHP developer that knows FileMaker, that would be a good idea. Are you stuck with these PHP developers? If so, and if they are not big on learning FileMaker, then maybe MySQL is what you'll need to do to accommodate their lack of skills. I've had this discussion many times and it does not mean a failure from the FileMaker perspective. What I usually do is emphasize that doing so, they need to be fully responsible for security and the MySQL database. But one of the big benefits of FileMaker is that it has Extended SQL Source (ESS ) abilities to put MySQL tables into the FileMaker Table Occurrence Graph and treat MySQL tables pretty much like they are FileMaker tables. This gives you the benefit of easy manipulation from within FileMaker while accommodating your PHP developers. One thing to note, this works best if the MySQL and FileMaker database are on the same local area network. I've done this for quite a few solutions and it works reasonably well and lets me get the benefit of a FileMaker user interface for the maintenance I need to do while making it easier on the PHP developers.
Ok I'll try to answer the questions Beverly.
Do your php programmers have experience with this sort of website (with any kind of database)?
– Yes they are experienced MySQL database programmers.
Do they know how to optimize a website to limit the actual connections to the database (any db)?
– Yes they do.
Do your php programmers and/or website host know how to handle so many concurrent connections (hardware, web server apps, etc.) as there is a lot more to this size/type site than the database & PHP.
– I believe so (they tell me they will limit this (to what I don't yet know).
Do your PHP programmers understand FMS as well as other database?
– No they have no knowledge of FMS.
Where do you get the estimated number of sessions?
– That was the clients estimate although we think this is over optimistic and the number of concurrent connections could be limited to 500 we think.
Just to restate:
1. My client knows my work through small Filemaker databases I have written for them for a few users.
2. They have a larger project and like my Filemaker style.
3. They have asked me whether I can write a Filemaker database that will be for up to 10,000 users but with concurrent connections estimated at around 2000 to 3000 (their estimate). This may be over optimistic on their part but I am trying to find the limitations of Filemaker using PHP as a 'Custom Web Publishing'
I have told them "I don't think Filemaker is cut out for that sort of database but I will write up a report."
I am asking is whether anyone has experience of using PHP with Filemaker for a large number of users.
I don't have any further information on the database yet as I don't have a spec.
Many thanks for your time,
Many thanks taylorsharpe
That info is a great help.Using PHP developers who are familiar with Filemaker would be a good idea. I know some detail on MySQL so it wouldn't be impossible to work with them that way if they can't handle FM. Yes the ESS route looks good - I can keep the MySQL and FMS on the same local network. The current in-house guys can do PHP/MySQL and have good security so thats a help too.
Thanks for you time,
Make sure you work directly with them when they design MySQL. It can get overly complex as to be difficult to work as ESS in FileMaker.
Sent from miPhone
Many thanks Beverly, I will run a series of extensive test first with a small filemaker database that I did for them as I can see a lot of learning curve is needed here.
Many thanks all, I have enough information to write my report.
Taylor, how would you compare the search speed of MySQL vs FileMaker when used with a large set of data?
2 of 2 people found this helpful
Just note https://www.filemaker.com/products/filemaker-server/server-15-specifications.html FileMaker Server 15 has a limit of 2000 CWP connections... BUT if your connections are coming from the same IP address (e.g. through the same web server hosting the PHP) then multiple users will use only 1 connection so you can go as far above the 2000 connection limit as you want.
ALSO note that the first time a PHP connection is established there is a delay of a few seconds, but if all the connections come via the same IP address (e.g. via a web server hosting the PHP) then this delay will only be there for the very first connection that is established.
As Taylor said, your PHP developers need to know FileMaker well or you need a FileMaker developer to provide them with a good API for what they want to do. E.g. calling a FileMaker script via PHP means that essentially a FileMaker Pro user session is created on the server and can be a bit heavy on the server (depending on your solution) and you certainly can't have 2000 users all calling a FileMaker Server script at once! Manipulating the data directly via PHP is usually less resource intensive.
Currently I have one server with 600 clients all posting data (via the one web server so only one connection is being used on the server) and the server barely blinks, but your demands might be much heavier.
3 of 3 people found this helpful
Taylor, how would you compare the search speed of MySQL vs FileMaker when used with a large set of data?
Oh that sure opens a can or worms and what ifs. Noting the initial delay on a first CWP connection sets FM at a disadvantage, but can be competitive after that. The size of the database really doesn't make that much difference in that FM's indexes are as good at MySQLs except that MySQL can be more granular on field types that allows for certain types of optimization. For example, FM only has a number field. MySQL has about many types (INTEGER, INT, SMALLEST, TINYINT, MEDIUMINT, BIGINT, DECIMAL, NUMERIC, FLOAT, DOUBLE, BIT, etc.) and if your data fits neatly into one of those types, it can be better indexed and managed by MySQL. Then again, it also puts constrains on the number formats you can use that FM doesn't constrain you with.
I've had a similar database, Oracle, do searches on the same table as single user where I was searching 83 million records and the speed to find a single indexed record in a table with 25 fields was about the same speed (3-4 seconds). It was an interesting comparison since both databases were on the same server, so hardware was not a variable. However, where Oracle and MySQL beat FileMaker are with a lot of simultaneous transactions on that same database. I have no comparison, but I'm sure if you had 500 people hitting that database simultaneously, both Oracle and MySQL would be much faster than FileMaker.
One of the limitations of FileMaker is that the database engine cannot be spread across multiple servers like you can with MySQL and Oracle (no, putting the web service on a 2nd machine is not putting the database on two machines). However, most such databases are not configured for such high end performance and, as single server performance comparisons, FileMaker fairs OK with them. Note that 360Works has some interesting syncing of servers that allows replications of FileMaker databases across the cloud with Load Balancing to effectively do what MySQL and Oracle and other large databases are doing and its pretty cool. It just isn't native FileMaker, at least yet <fingers crossed>.
In general, the current version of FileMaker does not scale as well as MySQL and for a lot of simultaneous transactions, MySQL will perform better. Also, MySQL has a lot of optimization tools that the database administrator can tweak that FileMaker hides from end users and are not modifiable by developers. That makes FileMaker server much more friendly, but also not as optimizable.
The beauty of FileMaker is the tight integration of the UI, security and schema into one tool. But it is not as scaleable as a highly optimized MySQL server. However, I'm forever running into people who remember FileMaker from a dozen years ago or more who have no idea how well it does perform on modern equipment. FileMaker is rather consistently underestimated in discussions with enterprise level IT people. Note that a couple of versions ago FM rewrote the CWP PHP API for FileMaker making a lot faster than in the past.
But back to your question, the size of the data set is not going to matter much compared to the number of simultaneous transactions going on.