Hello,

Is anybody out there using FileMaker Server 7 in a heavily used
environment (more than 50 host databases and more than 30 users)? Has
anybody ever seen it perform very slowly or crash?

We installed FileMaker server 7 on Windows 2003 Server 2x 3.2 Ghz Xeon
with 5 GB of RAM. This box is dedicated to FileMaker server. We have
about 94 hosted databases and an average of about 80 users on the host
at one time. We tried to clean up our databases prior to converting
to version seven and did additional cleanup to the databases after
conversion. We also have the ODBC plug-in from server seven advanced
installed although we have not made in the ODBC connections at this
time were during our testing. Anyway we noticed that the performance
was about five to 10 times slower than version 5.5 server even though
we have almost three times the horsepower in the hardware. Our
FileMaker 5.5 server is built on Windows 2000 service pack 4 2x P3 1.3
GHZ with 2GB of RAM.

We also noticed that the server crashes the services multiple times
per day. When we view the performance tab of the Windows task manager
of the server computer the page file usage is almost always at 2.0 -
2.02 GB when it crashes. The problem with the crash is that it
doesn't just crash one database but it crashes every single database
and causes users to lose data. When it crashes the users can no
longer see the databases and we have to reboot the server computer and
wait for the databases to load up before they can start working again.

We called technical support multiple times on this and they said to
try server 7 v2 can try uninstalling and reinstalling. The computer
continued to crash after uninstalling and reinstalling software. We
tried reformatting the server and and reinstalling everything and it
still crashed. We also tried a completely separate computer and
hardware and found that it crashed also. We tried the v2 patch and it
definitely lengthened the time before it crashes and provided a speed
improvement, but it still crashes also with load. It only takes about
15 computers performing server-based calculations continuously for
about 1.5 hours to bring it down. Server seven v1 only takes about 10
minutes to bring it down. To simulate load we set up a script in a
database that runs on form layout. This layout has some date
calculations in some case statements, a portal to related records in a
related database, a container field and record level security in the
new FileMaker seven security privileges. The security basically
checks the user versus the status of the records to determine whether
the user has modification rights, so it evaluates on every record.
This database has about 1400 records so we set up a script to loop
through the records, which obviously causes a calculation to evaluate
access privileges for each record. Server 7 seems to perform these
calculations on the server and bring the data back which takes about
10 to 15 seconds per record. The CPU usage on the server shows
activity when the script runs which looks like it is doing
calculations on the server.

We have also played with several different cache settings in FileMaker
server properties. It seems like a higher we set the cache the faster
the database performs in the faster crashes. We have set the cache to
the bare minimum which makes the server stay alive about four times
longer but still crashes and then the performance is terrible.
FileMaker tech-support also have us adjust the cache flush interval
settings from different intervals between one to 10 minutes. Anyway,
we can repeatedly crash it consistently regardless of the settings.

We also tried hosting only three databases the v2 updater instead of
94 in the FileMaker server seven services crashed in about eight hours
with 15 computers applying continuous load to it. v1 could crash in
about 10 minutes with three databases and 4 computers applying load.
I also ran analyzer on the three databases and addressed the issues it
found before doing these tests. These databases are were converted
from version 5.5 and are about .5 gigabytes in size and have
relationships to each other for viewing data in the related files.

Does anybody have any similar experiences with Server 7 or does
anybody have any success stories getting it to run stable with heavy
load and user base or converted databases?

Thanks in advance,

Did you check the speed of the databases with the files the same machine
with a copy of FileMaker? If it is slow it could be that the conversion
needs more cleaning up. Check the file references in the converted files and
eliminate any that arn't needed. I converted a fairly complex solution that
took forever to open. After deleting a lot of the converted references it
speeded up.


"Shawn" <smower (AT) lifetime (DOT) com> wrote

Shawn <smower (AT) lifetime (DOT) com> wrote:

Did you use MetadataMagic with File Reference Fixer to do this cleanup
before the conversion? If not, you've got multitudes of file references
hanging about. Many developers have adopted a multiple conversion
strategy...they clean, they convert, they find problems, they go back to
the 6 files, they clean some more, they convert again, lather, rinse,
repeat until clean.

Check out the file references in the first file that opens. If it's got
long lists of outdated file refs, it's searching and trying to resolve
every one in order to open the solution. When the other files start
opening, it's the same piled higher and deeper.

Today the FMDiSC (www.fmdisc.org) group was privileged to pick the
brains of Andy LeCates from Filemaker Inc for almost 3 hours, and to
share with him our top 78 issues regarding FM7. One topic that came up
repeatedly was performance, and it came out that most of the poor
performance reports come out of converted solutions.

Scratch-built FM7 files do NOT have this problem. It may be that your
files are simply overwhelming the server capacity. Though from your
post it seems like you certainly have a robust hardware and OS setup.

I have also, not, on the FSA talk list, seen reports such as yours
regarding constant crashing. Have you done any checks on the hard disk?
Is your network set up with no auto-sensing on the hubs? This used to
cause lots of disconnection failures in FM6, it could have other effects
in FM7.

One thing that has come out on the list is that in order to get the darn
Server to work properly, one has to completely uninstall, reboot,
install the base server, reboot, install the update, reboot. You get the
idea. Don't simply run the update on a server that's been configured,
apparently.

Big pain in the ass? You bet. Proper behavior for a software? I don't
think so. But for now, I'd try that.

Since you did test this on a separate machine (very good testing
process, btw) I suspect the problem lies in your files. Try the
installation with some basic FM7 built test files while the converted
files are not hosted, have all your 50 users make new records at the
same time, and see if the crashing happens. If it does NOT, then I
think you have your answer.

If it does, you have another data point.

I hate when things like this happen. We do feel your pain, honestly.
Most of us have been there at one time or another. Share the answer when
you find it?

Lynn Allen
---
www.semiotics.com

I'll add one small observation, the one common problem I have had in a
number of conversions, that typically grind things to a halt, is that
even though the reference and rel may be correct, somehow, the sorts
attached to the rel can get lost. This is not all sorts just the
occasional one, but occasional enough to induce a partial coma.


Chris Brown
Neurosurgery
University of Adelaide

Thanks for your response. We have done a lot of cleanup on file
references which definately sped up the opening time. We still find
that the general database scripts and tasks perform much slower with a
load of multiple users hitting the database at the same time. When
the file is not hosted, it works pretty fast, but once it is hosted,
sorts and looping through records with calculated security settings
take much longer. Server patch v2 helps with the speed, but it is
still not as fast as server 5.5. Tasks run about 2 - 10 times slower
on our converted databases.

"Terry" <tkunz (AT) socal (DOT) rr.com> wrote

Thanks for your response. We did not use MetadataMagic on the
conversion. We first did a practice conversion and identified the
filemaker log issues and fixed all those back in 5.5. We then read
through the filemaker upgrade document and tried to fix the issues
with accelerated calculations and not statements. We then reconverted
and tested the converted databases in our test lab. We made changes
and updates to them again on the 5.5 side and then converted most of
them again before we hosted them in our live network. Some of them
were partially rebuilt in 7 so we imported the new 5.5 data instead of
reconverting. After converting, we cleaned up file references which
sped up opening speed performance. The hard disk is brand new, but we
also tried it on a separate computer and got the same results. We did
a couple rebuilds, reformatted the box, installed from scratch etc.
and can get it to crash with every setting we try. We have since
downloaded a demo of MetadataMagic but found that it crashes about
half way through when it analyzing some of our 5.5 files. I don't
know if that means those files have corruption in them, but they sure
work beautifully in 5.5 without problems. I am open to the idea that
files could be the issue, but with 94 files, how do you tell if the
file is the issue or if it has corruption? I did try a test with one
basic hosted native 7 file and put a load of about 14 computers on it
and it has run good for a couple of days without crashing, but that is
only one file and no scripts, no layouts, no relationships etc. I
don't know that rebuilding all 94 files from scratch is very feasible?

Thanks,


lynn (AT) NOT-semiotics (DOT) com (Lynn allen) wrote in message news:<1gmfo9m.1f15d15t89e9vN%lynn (AT) NOT-semiotics (DOT) com>...

Terry wrote:
I don't have fmp 7 yet, but what does the term "converted reference" mean? What does fmp7
do to the old file references that need 'cleaning up'?
--
"... respect, all good works are not done by only good folk ..."
-till next time, Jameson Stalanthas Yu -x- <<poetry.dolphins-cove.com>>
consul (AT) INVALIDdolphins-cove (DOT) com ((remove the INVALID to email))

~consul <consul (AT) INVALIDdolphins-cove (DOT) com> wrote:

In previous versions of FM, a file reference happens when a calculation,
a relationship or a script that has to connect to another file is
created. Value lists referencing other files create them too.
Depending on the current location of your file in the directory
structure of your computer, on the server, or whatever the enviroment of
the files, the FULL PATH is stored with each file reference. Without
third party tools, these are never visible to developers, and cannot be
modified. In some cases I've seen file references which contain paths
which reference computers I don't even own anymore. FRs are Forever,
apparently.

Now, if you follow practices like renaming your working directory often
(I do, as part of my backup routine. I name the folder "ClientX110604.1"
and then drag it onto a Stuffit icon, and store it. Then I rename the
folder to "ClientX110604.2" to continue working. Other people move files
from computer to computer to work...each move builds different FRs into
files.

Every single one of the file references contains the folder name of the
moment it was created. The next time you make a object requiring a
reference, you get a new one if the folder has been renamed or the
computer location is different. Although FM 6 will resolve those
seemingly different references based on the name of the file, upon
conversion each one becomes open and obvious in the "Define...File
References" dialog box.

In FM7, these file references are explicitly editable. They can be as
simple as "file:Filename.fp7" which means "look in the same directory
for a file called "Filename.fp7" or it can be a full path on the local
drive, remote drives or IP addresses halfway across the planet. For EACH
file referenced there is one and only one FR created, thereafter all FR
objects such as scripts, relationships, etc use the single FR.

So FM7 expects and uses one and only one FR for each file. If you hand
it hundreds or thousands (or even dozens which may be obsolete and
unfindable, such as ones for old computers no longer in existance) it
chokes. No wonder, eh? It wants the 433rd FR to the same file for the
script it's running, but the Set Field of a related field in the script
uses the 278th instance of it.

Each of these different file references MAY create a different Table
Occurance on the graph when the files are converted. It certainly
confuses things when you go into a file and wonder "should I use the
Contacts 12 or the Contacts 43 TO for this relationship?"

This is why file references have to be consolidated and eliminated,
filtered down to ONE which makes the most sense, before conversion,
because if you don't, you've got to not only do it after, you have to
make major changes to your Table Occurance Graph as well.

This is what people use MetaDataMagic with File Reference Fixer for.
www.newmillennium.com

Lynn Allen
---
www.semiotics.com

Lynn allen wrote:
((snipped all the other important info))

Thanks. I'm in fmp6 for now, but I think in the coming summer, I know we will probably
move over to fmp7. My 2 ??solutions?? consist of 5 and 3 files, where I hope to move it
all to just 2 separate files with 5 and 3 tables.
Stuff to think about ... stuff to think about.

By the bye, with the 2 separate solutions, can I reference a table in one from the other
solution, provided both are open?
--
"... respect, all good works are not done by only good folk ..."
-till next time, Jameson Stalanthas Yu -x- <<poetry.dolphins-cove.com>>
consul (AT) INVALIDdolphins-cove (DOT) com ((remove the INVALID to email))

An interesting problem I recall from using FM5.5 some time ago.

We had a complex script that batched products ready to despatch, calculated
a schedule of credit card payments, created a payment file to upload to the
bank then printed thousands of invoices and box labels.

One day it began to inexplicably crash the entire server every time we ran
it.

After about a day of very stressfull analysis, the admin found out that
there was (at least) one corrupt record in the DB, and each time it was
referenced the server would crash. The only way to delete it was to delete a
small range of records that encompassed the corrupt one.

Perhaps you can test your DB by opening each record of each db in a script,
and writing a field of the last successfully opened record. See if it
crashes in a similar place each time.

LiFe.



"Shawn" <smower (AT) lifetime (DOT) com> wrote