Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 4726 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

Hi Everyone,

We have had a CWP solution running for several months on a WIN 2003 Server. We recently upgraded both the server, OS and FileMaker Server software.

On the new machine the FileMaker files seem to be running much better than before, but unfortunately the CWP pages now seem to load in minutes rather than seconds. We moved the php files directly from the old to the new server and have also tried loading "fresh" copies of the php files. Because the CWP files are basically useless on the new machine, we have had to keep the old machine running so our clients websites would still function.

Here are the configurations for the two machines:

OLD

WIN Server 2003, Enterprise, SP 2

Intel Xeon 2.50 GHz

1.95 GB RAM

60 GB Hard Drive

IIS v6.0

PHP v5.2.6 build 5/2/08

FileMaker Server Advanced v10.0.2.206

NEW

WIN Server 2008, Enterprise without Hyper-V, SP 2

6 Core AMD Opteron 2.60 GHz (2 processors)

32 bit OS

2.0 GB RAM

60 GB Hard Drive

IIS v7.0

PHP v5.2.11 build 9/16/09

FileMaker Server Advanced v11.0.1.95

Any ideas or suggestions as to why we are seeing such a significant performance drop with the same php files on updated hardware and software? I am hesitant to go back to the older version of php, because the version currently on the new server is what is indicated in the FileMaker documentation.

Thanks,

Paul

Posted

Ignore the FileMaker documentation, the PHP version used is irrelevant in the scheme of things and actually has absolutely nothing to do with the CWP engine - I would start by looking at a different PHP version. More specifically, undeploy the CWP component and re-deploy it without PHP - then go to php.net and track down a fast cgi installer instead (works 10x better with IIS7 when it works) - you're likely to see massive general speed improvement with that.

That being said the question is whether PHP, the web server, the CWP engine or FMS is causing the latency.

If you've changed little to nothing and performance has decreased, look at the factors that have changed. I doubt a lot was changed in the CWP base and if you're seeing better performance with FMS in general, that isn't likely to be the culprit either.

After trying PHP swap if you're still having issues run some standard XML queries against the CWP engine and take a look at the IIS logs to see if you can determine where the lag is coming in using the stats.

HTH

  • 4 weeks later...
Posted

I posted a response on FileMaker Forums as I experienced the same issue. The solution is to replace any instance in the config file that has the IP address of your FileMaker Server with 127.0.0.1 instead of "http://localhost". For some reason in Windows Server 2008 and other servers, PHP takes a longer time to resolve. Once you switch it to 127.0.0.1 you will see dramatic improvement in performance. While FileMaker DID mention this in the deployment document it was easy overlooked because it appeared under IWP/CWP. I have submitted a bug report to FileMaker as it's possible they could fix this in the future. Because many of us code the PHP sites to "http://locahost" instead of "http://127.0.0.1" for ease of moving the sites from our staging to deployment server I never bothered to think this was related. Give it a shot and it works for you please post a message here for others to see. Thanks.

Javier Villalobos

JVillalobos Consulting

[email protected]

Posted

Hi

I am having the same problem. I have setup FMSA 11 on win2008 Server R2 in a test environment on 1 Hyper-V virtual server using fastCGI with PHP 5.32. I don't think the virtualisation is the problem as the filemaker access is fine. The PHP access is very slow, I have also tried installing the filemaker bundled PHP and this is just as slow. Changing locahost to 127.0.0.1 didnt make any difference either.

Thanks

Craig

  • 1 year later...
  • Newbies
Posted

Javier

You sir, are a genius...! We've seen load times for ajax calls drop from multiple seconds to a few hundred milliseconds (i.e. what they should be). Anyone know why this is...???

Cheers

Steve

Posted

It's not actually a FileMaker issue it's a win 2K8 issue - the resolution of the localhost DNS entry in win 2k8 is just botched... you see the same performance issues with SQL server and any other technology. There's a way to fix it but I can't remember what it is... so the quick fix is to bypass the dns altogether and just use the IP.

  • 4 months later...
Posted

Genx, thanks for your comments on this issue. It is one affecting me. I wondered if you had any more thoughts on the underlying XML performance of the Filemaker server. I have actually just posted this topic

http://fmforums.com/forum/topic/81518-optimise-xml-performance-for-web-services-manager-and-php/

in the 360works sub-forum as I think my performance problems with using the PHP API and 360works product (which has its own PHP file and addresses the Filemaker server via XML directly) are both to do with the XML performance on the Filemaker server. Both are going realy slow, especially when related data is evaluated in scripts or called for display to the user.

Is there anything I should know about configuration to get the most out of the XML engine or I am I stuck? Right now even simple finds on indexed fields take 3-5 seconds and using the Web Services Manager WSDL is painfully slow, whereas IWP returns complex finds on multiple fields almost instantly. I is soo frustrating!

Any help would be much appreciated.

Posted

XML is by its nature somewhat slow, and the FM versions are especially 'wordy'

GenX knows some good ways around this, but the simple version is:

- Only use the fields on a layout that are absolutely required - the XML interface returns *all* of the data on the layout, even if it's not required

- I tend to avoid portals for much the same reason - if there are 1000 rows in the portal, all of that information comes back as well

This topic is 4726 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.