![]() The unstored find for 10 users with Startup Restoration easily took up about 60% of the CPU. For developers frustrated with a server needing more cores while the CPU usage is hanging around 20%, Startup Restoration will help, allowing you to do more with each core. The added efficiency on the CPU is a major part of the benefit. With Startup Restoration off, the same unstored find for the same 10 users took more than twice as long at just under 33 seconds. With Startup Restoration turned on, our example unstored find took a little less than 15 seconds for 10 simultaneous users. To get an idea of the impact, the two screenshots below show just how much faster enabling Startup Restoration is. That means, your query goes to the shortest “lane” available and has a better chance of being processed more quickly. The Startup Restoration feature allows the server to handle queries in parallel. Each query is put in a single line and assigned a processing "lane" once one opens up, much like a bank line with several tellers. Without Startup Restoration (what most users are used to), FileMaker Server handles queries in serial. This often happens as businesses expand, adding both more users and data which load the server with an ever increasing number of queries. Performance optimization is one of the most time-consuming (and expensive) types of development and is often overlooked or ignored until applications are nearly unusable.
0 Comments
Leave a Reply. |