FactoryPMI Performance

[paulengr 44]

I had not looked at FactoryPMI before. Now that I actually spent more than 30 seconds browsing, all I got to say is wow, neat. However, it has an interesting layout. The HMI system NEVER, EVER talks directly to either an internal database or to the PLC's themselves. It always communicates strictly to a SQL server. Interesting concept, but how well does it really perform? I'm comfortable with the idea of a database because lets face it, most of the big players out there (Fix, Cimplicity, Wonderware to a certain degree, Citect) actually run a "point database" which is proprietary and all queries go through that. To a certain degree, this is also the model of OPC (although OPC's implementation leaves a lot to be desired in a lot of ways). So, is the performance really that good? Any ideas of response time? Such as 100-200 ms?

[Nathan 7]

Paul, I believe FactorySQL restricts your performance times on the OPC end to about 50ms. The best way to test the database is to download a free copy of MySQL (or whatever database you want) and run it. Using a moderate amount of tags will run easily at that rate (<1000). Your system performance with respect to the database is based on tag count and update rate, and depends greatly on the system. That said, most integrators/end users that I've spoken with have been impressed by the response time. The big players "point database", "tag database", or "database dictionary" might be more of a relic from their own implementations before they started going with SQL databases. They implemented these in the first place because PLCs don't do well with many concurrent connections; the "point database" is a mapping to distribute that communication. I would argue that these vendors could implement their own proprietary "point databases" on an SQL database and get better performance (although they might need to keep tables memory resident and control their access to disk). This is not far from what Wonderware has done with InSQL. Much of the question has to do with licensing and supporting their existing customer base, not whether an SQL database can handle it. The question about Inductive Automation should address performance given that we've chosen an open model without a lot of proprietary optimization - in other words we could do a lot better if we forced you to use some particular database. For example, we'd use a trigger based notification instead of polling. We instead focused on supporting pretty much any SQL database type (MS SQL Server, MySQL, Oracle, PostgreSQL, etc). We haven't produced formal benchmarks since there are so many variables. I'd be happy to help you set up an evaluation to see how it runs for your process.