Add host= deskspace.fmcloud.fm
That will / should give you the open hosted files screen...
hmmm - well there is a lot to unpack here ...
I will try to make a start but I do understand that from much of what @Vincent_L says it feels unlikely that he will be open to changing his view that essentially FileMaker fails to give him what he wants, what he is entitled to receive and what he believes that others also want?
The laws of physics control what our hardware and software machines can do.
The more we ask them to do the slower they work.
FileMaker makes a ton of things very easy that other databases do not make easy and hence those others are really tough to use, especially the first time.
So we built a COVID-19 Certification App last year, using Unity as the development environment, and both Amazon and Google backends. My colleague Matt commented that, for example, putting in the encryption that takes minutes in FileMaker took about a week between Unity and Google Firebase.
So FileMaker does a ton of work automatically without our having to work out how to do it. But that doesn't come for free. We are not doing the work but the machine is, hence that is taking up capacity that cannot then be used for other work.
The "holy cow" of FileMaker has always been that records magically update in front of your eyes when someone else commits them, over a WAN. Personally I would like the ability to tell the record when to update, but in order for FileMaker to remain accessible and easy to get started with they have deliberately retained this feature. That does not come for free, there is a ton of communication required to make it work so seamlessly. Its just physics isn't it?
When we look at some web tech that is much faster it is only faster because it is doing so much less, it is essentially a much thinner lighter process than FileMaker.
Further, FileMaker achieves the miracle, in my view, of enabling us to build a single file which will run on Mac, Windows, Linux and iOS. I am unaware of any software development application that does this, it will be interesting to compare any that do exist.
Back in the early nineties there were a number of database / data management Applications in the market, and now FileMaker is pretty much the only one left from that time other than Access which does, I understand still exist in some form. It has survived because it has made a reasonable job of developing and keeping faith, so far as possible, with existing users. New products don't have that burden, maintaining backwards compatibility is an enormous burden, it s much easier to dump the old stuff and start again, but FileMaker haven't taken that easy option.
@Vincent_L has done a great job of listing most of the key performance principles but he expresses his view that he does not want to follow them because - I guess reading between the lines - he has a very large relationship graph and a way of working that does not fit well with modern approaches to FileMaker design. That is his choice. He is obviously very aware of what he could do to improve what he sees as poor FileMaker performance.
I have to level with him. What he sees is the result of design decisions that he made, probably many years ago. This is, ultimately his own responsibility, no-one else's, certainly not FileMaker / Claris's. His solution is doubtless much bigger than it was then and people have found more performant ways of building very fast solutions with FileMaker over the intervening years, as the platform has developed. If he chose to do a few things the speed he sees will improve and if he doesn't - well that is his choice:
-
split up the relationship graph- even splitting it in two will start creating benefits
-
although FileMaker was sold as a relational database many years ago it is really a data management system today. Relationships are or can be slow. Using fewer relationships is faster. This is because FileMaker automatically re-evaluates the known universe from the current context at every possible opportunity in order to magically update everything without you having to do so. If you give it a big universe to evaluate it will take more time than a smaller one. This is basic physics.
-
reduce the amount of indexing. You do not generally need to search on every field to find the right record in a reasonably well designed solution. My approach since 2011 has been to use only a single field which I auto enter with the contents of the fields I wish to search and then I only search on that field. I never, ever, give users Find Mode. This means writing all the scripts necessary to control the Ui. It is more work. The user experience is simpler.
-
where you have unstored calculated fields change that existing field to auto-enter instead and add a new unstored calc field for use where required but use the auto-enter field for everything possible.
So I applaud Vincent's knowledge of all the things he could choose to do to improve the performance of his solution, he has provided us with a great summary of techniques to work through and I wish him every success in improving the performance of his design.
Finally here as couple of slides I have just done for a presentation I am doing for the Ann Arbour User Group on Tuesday night - a few of the principles that I find most helpful to follow.
Cheers, Nick
3 Likes
@OliverBarrett - would you like to share and describe some of your techniques / methods of evaluating performance?
Cheers, Nick
We have circled back to a conversation you and I have had many times, which I won't repeat. Explain to me with all the proposed problems you mention... that we have 65 files running, > 5000 TOs, 130 GB of data ( with no containers ), 100 users... and none of the speed issues you complain about?!
For this, we should probably as someone to split this off into it's own thread, because I'm sure no one wants to read this conversation again.
I wish I could share with you the goings on at one of our office. The prices Claris charges is so small compared to other platforms. It's not even close. For 15 users, the cost is ~$95,000 just to get up and running. Doesn't include the annual cost, and the cost of custom development, and the cost of hardware they require ( 3 separate servers ).
Listen, @Vincent_L, I get where you stand. I agree with some of it. I disagree with a lot, and your means of expressing it. We know that. And I'll leave that there.
Got it, thank you. I was using a web browser, not FMP.
Sorry - I should have been more specific - glad you got there.
Nick
BTW: Here is a description of the App...
2 Likes
I'm going to wait until I've got a better line. I'm in NZ and sitting behind a connection that is meant to give me 100Mbps. Normally I get between 85 and 95Mbps but a speed test shows that I'm getting 26Mbps. Test 2 took more than a few minutes, you'll see the results. With these network connection speeds scrolling is very laggy. Not a smooth experience.
NZ to France - that is challenging, more the latency I would think than the absolute speed? Chris Moyer from Michigan to France said he has never seen FileMaker handle images so fast. I will see if I can get an instance I can use on you side of the world!
I can see you - if you were 'fmadmin' took 439sec on test 2 - where I have been getting 65 - 100 seconds for the same test - so yours was about 1/5th the speed - such are the laws of physics I guess?
Cheers, Nick
In terms of geolocation, it would be the worst possible. I remember reading a Claris document that said that LAN connections should be less than 40ms latency. I have been working servers based in Sydney, Melbourne and Brisbane that have a ping time of 140ms. At that rate the connection doesn't feel spritely but it works.
I'm now sitting at a connection that is reporting 49Mbps. The performance isn't blinding but it's workable. Good job.
1 Like
Good - I can change the cell connection on my phone between 4g 3g & 2g which is handy means of throttling bandwidth on cell.
Are you North or South Island? My brother has been in ChCh for 25yr, before that 10 yrs outside Auckland.
That's not correct. The CPU will do predictive branching for any code running. That's on a much lower level than FileMaker's calculation engine interpreting your input.
2 Likes
Clay's words not mine
Yes but in terms of rugby it becomes really interesting 
Seriously @nicklightbody, Even though we're hosting the file and I know our hosting service is super fast, I'm still very impressed by the performance. It is really mind blowing.
1 Like
No problem. Probably the discussion was about something else.
I think I'm going to avoid this minefield...
I guess @MonkeybreadSoftware is right here. Predictive branching is a microprocessor feature that cannot be controlled by user space software.
The way user space software is designed and compiled has an influence on how efficiently predictive branching can be used when the application is running. That is my non-expert understanding of how this works.
1 Like
Even though we're hosting the file and I know our hosting service is super fast, I'm still very impressed by the performance. It is really mind blowing.
So Nick built an exceptionally Fast Filemaker Image gallery. The problem is exactly that it's "exceptionally" fast. Its astonishing. So people famillar with Filemaker see this as a extroardinary thing.
Nick has put all is knowlege, bending Filemaker's native way of working, to create that remarkable feat
=> That's exactly the problem of Filemaker. Having to have it perform Ok requires exceptional skills, and work, as we can imagine that Nick had to try out many solution to achieve this (illsutrated by the fact he has several files on display to achieve teh best performance possible). The norm, as the two knowledgeable gentlemen astonishement illustrates, is much slower performance.
So rather than contradict my statement, your solution Nick jsut prove my point. Filemaker is slow, so slow that seeing it it perforl ok, provokes praise and excitement.
But now let's quantify your solution speed : its fast for a… cloud filemaker solution, but is it smooth, is it absolutely fast compared to a traditional web-galery : Not in my view. It's workable, but not smooth.
1 Like
Yes, and it is called "apples to apples comparison".
I am all for pushing harder for the product to be better at what it does. But there is something about the attitude here that I am not comfortable with.
@nicklightbody clearly said that FileMaker's ease of use comes to a price. Making a comparison to other tools that do not have to achieve any of what FileMaker does, to focus only on the performance side of things and then say "Ah ha! your solution is still slower than XYZ" just feels dishonest "in my view" (to use your very words @Vincent_L )
If you want to drive an F1 racing car, go drive one. Just know that you will have to pay way more for fuel, tires, hired experts, etc. With the added benefit of not being able to park downtown. But it will be fast.
I know this topic is about performance, so I won't go too far saying performance is not everything, but I'll simply say that not everyone values it equally.
Have fun tuning your engines everyone!
4 Likes
This is a highly skewed view of what's happening here. The reality is, this is not a problem with FileMaker, you can create the same slowness with any programming language. What you run into more often with FileMaker, is where a convenience features, to make it easy to use, also creates additional overhead. Nick's knowledge and skill centers more around finding ways to make it faster, and reduce overhead. This is the entire concept behind computer science.
It doesn't take a lot to keep FileMaker running fast, but there absolutely is a level where expertise is needed to get the most out of it. The thing that amazes me with you is that refuse to hear that you have to change some of your habits and development practices. We can't help you with that.
It's true that if you are looking for raw horsepower, to process 20 million data-points per second, FileMaker is not your tool. But I don't imagine you are doing that.
3 Likes