Perform Script On Server


PSOS takes some of the routines that normally happen on the client, and does them on the server instead. This can make things a lot faster if, for example, you're finding a lot of records in a table where each record is very big (has either lots of fields or some fields have tons of data).

When such a find is done on the server, the *whole* record doesn't need to come over the wire to your client: only the data that the calendar needs comes over.

This speed up is most noticeable when you're on the WAN: when your FileMaker client is not on the same physical network as your FileMaker Server. The further away these two are, the more PSOS can help.

To learn more about PSOS we recommend these two great articles by Beezwax:

Using PSOS (Perform Script On Server)

To use PSOS in DayBack you have to be running on FileMaker Sever =) and edit the script "Load Calendar Settings - On Startup --- Edit Configuration Here ---". Right towards the beginning of the script you'll see the comment "Would you like to use "PSOS" (Perform Script on Server) when possible?". It's currently set to True. Switch it to False if you'd like to turn this off.

That's all you have to do, but you may be interested in what that switch actually does. It tells DayBack to use PSOS if it can. Later in the same script you'll see the comment "If PSOS is on, make sure PSOS is available."

After that comment DayBack actually tests the server to see if you can use PSOS. DayBack runs a quick simple script on the sever to make sure your server supports PSOS and that you haven't exceeded the number of simultaneous PSOS sessions permitted. It also checks if you're running without server, as you may be when you're developing.

Each script called with PSOS also tests that you haven't exceeded the number of simultaneous PSOS sessions permitted and runs locally if you have.

In this way DayBack only uses PSOS when it can, so you don't have to keep messing with that switch as you move on and off your server.

Why Make This a Switch? Would You Always Want to Run This Way?

While we love PSOS for it's speed boost there are three reasons why you may not want to use it.

Server Load. If your server is under powered and you have a lot of users, you can crush your box with PSOS. Experiment with this switch if you think that you may be in this situation. If you're hosting with a 3rd party provider you can crush their box as well, so you may want to email them and ask about PSOS.
Debugging. If you're trying to step through a script with the script debugger AND you're hosting on FileMaker Server AND you have PSOS on, you can find debugging to be a bit "mysterious" as your script disappears to go run on the server and only returns to the debugger when it's done.
In these cases run the script "Toggle PSOS" to toggle PSOS on and off, turning it off for debugging. Don't worry if you leave it off--this script only adjusts PSOS for your session. It doesn't effect others of the file and won't be in effect when you restart the file yourself.
Speed. PSOS is not always the fastest way to go, even with a beefy server. The speed improvements in PSOS are most dramatic when you're far away from your FileMaker Server. But it does come with a trade off: scripts run with PSOS don't cache their results the way scripts running locally would. So if your server is close enough, you may not want PSOS running because you'd rather have the caching.
Here is an exaggerated example:
Without PSOS opening your calendar from another country takes 5 minutes to move from month to month. But once you've been to a given month, going back to that month takes only a couple seconds.
With PSOS on, it only takes 5 seconds to go from month to month... but it always takes 5 seconds. Going back to a previously visited month is no faster than going to a new month.
So experiment with PSOS to see what's fastest in your situation.
[email protected]
Follow us: