Why is my schedule so slow???

[RWX]

Hello everyone,

I need a little help with a multi-user schedule I've built. While it works quite well on my machine, it's SLOW AS MOLASSES when hosted on our FileMaker Pro 7 server.

Each user has a record in the Users table. There is a preference to include the user in the schedule. The only schedule view is a daily timeline. User names appear down the left hand side of the window and 24 portals are used to construct the timeline (12 hours in 1/2 hour increments).

When a user logs in, the system does a quick search of the Users table and finds all records with the schedule preference set to true. It then sorts these and builts a set of "timeblocks" for the user who just logged in. The timeblocks are stored in the TimeBlocks table. For every User record found, a single TimeBlock record is created. The TimeBlock record is set up as follows:

OwnerID (the user logging in)

ScheduleUserID (the person in the Users table who appears on the schedule)

Date (today's date)

Time1 - Time24

ScheduleUserFirstName (first name of user who appears on the schedule)

ScheduleUserLastName (last name of the user who appears on the schedule)

The Time fields each receive a time (the start of the block). The first field receieves 9am, the second 9:30am, etc. until all 24 fields are full (9am - 8:30pm). All TimeBlock fields are indexed.

Every user who logs into the system receives his/her own set of TimeBlocks for each user who is set to appear on the schedule.

The Schedule table contains a single record and only global fields. There are 24 Time fields, an Owner field, and a DateViewed field. For each of the 24 portals on the screen, the relationship is defined as follows:

Schedule::gOwnerID = TimeBlock::OwnerID

Schedule::gDateViewedID = TimeBlock::Date

Schedule::gTime1 = TimeBlock::gTime1

Each user gets his or her own schedule view this way. Each of the TimeBlock records is pulled into every portal. Basically the same TimeBlock record appears in each of the 24 portals for the user.

If John is the user logging in and both John and Jane are on the schedule, John will receive two TimeBlock records, one for him and one for Jane. On the schedule view, John's single TimeBlock record for himself appears in every portal row of the timeline next to his name. His single TimeBlock record for Jane appears in every portal row of the timeline next to her name.

The TimeBlocks are sorted by the ScheduleUserFirstName and ScheduleUserLastName. That way I ensure that the right record appears in the right row of each portal on the view.

Appointments are related as follows:

TimeBlock::ScheduleUserID = Appointment::OwnerID

TimeBlock::Date = Appointment::Date

TimeBlock::gTime1 = Appointment::Time

The TimeBlock records simply populate the portals on the Schedule view and "pull" the appropriate Appointment into the appropriate spot on the Schedule for the appropriate user. Here's a screenshot, as this might help it all make (some) sense:

When moving between dates, a script simply updates the related TimeBlock records to reflect the new date. This, in turns, pulls all of the correct appointments into the correct slots.

I think the biggest issue here is the fact that there are so many portals on the view. I've never built a schedule before, much less a multi-user one, so perhaps I'm missing something TOTALLY OBVIOUS. I'd very much appreciate any thoughts, tips, criticism, etc. as I really need to improve performance of the schedule.

Thanks very much for your time and thoughts!

-Rob

PS. The white blocks reflect availability. White = available. Gray = not available. Availability is defined elsewhere (in another table) and is also pulled into the schedule using the TimeBlocks. This definitely slows things down a bit too, but it was slow before I added this "feature."

[Søren Dyhr]

biggest issue here is the fact that there are so many portals on the view. I've never built a schedule before, much less a multi-user one, so perhaps I'm missing something TOTALLY OBVIOUS.

The manditory question here ...(I appologize for asking), but is the folder shared via the operating systems filesharing as well. This is the main reason for slowdown in first attempts to serve solutions. Two systems are pulling in the same file to make it sync...

Then to tipping you, I've actually made a solution back when applelink was a common lowcost solution of networking, it was slow slow slow. This made me turn our gantt charting into this instead of using portals at all - investigate the upload. What we did back then was to use Edoshins SmartRanges to handle the appointments ...but thats another issue. We made a found set fitting on the day in question and sorted it so all appointments were listed under each other so starthour was gradually increased for each user. This made a mirrored J curve of all the persons appointments. Overlapping assignments were spotted immidiately since the coloured part overlapped from the line above.

--sd

bars.zip

[stanley]

Rob:

That's a nice looking scheduler. I use portals for schedulers as well (my largest is maybe a bit less intensive than the screenshot you showed), and don't have big slowdowns such as you're describing, so I wonder if it isn't something to do with the graphics. Are those just colored FM buttons, or are they containers? If they're containers, then perhaps the images are too large, and you're hitting a network bottleneck. Something you might want to do is to watch how much network bandwidth is being used at the client machine while your slowdown is happening - see if the client machine is maxing out or not.

-Stanley

[Søren Dyhr]

so I wonder if it isn't something to do with the graphics. Are those just colored FM buttons, or are they containers? If they're containers, then perhaps the images are too large, and you're hitting a network bottleneck.

Yes that's a very important issue you bring up here, images are much slower when networked than than things found to your left in layoutmode ...because the chatting recuired is much less when asking draw 16 lines of red from point a to point b, than unpacking a .jpg image.

This is the main reason I in my template use the webdingfont...

--sd

[RWX]

Hello Stanley and S

[RWX]

S

[stanley]

Rob:

The standard answer is that you should NEVER have file sharing turned on on a FileMaker Server box. The reason for this is to keep users from mistakenly accessing the data files via OS-level file sharing, in which case the files would most likely become corrupted. Of course, in OSX you can set priveleges so that only you (or the admin, or whatever) can access the FileMaker Server folder, but really you should seal the box up as tight as possible.

-Stanley

[Søren Dyhr]

What would you suggest disabling???

Yes! But just for the folder the files reside in... take a look what I suggested in this thread:

http://www.fmforums.com/threads/showflat...true#Post163815

--sd