[FX.php List] Apache anolmaly with Fx.php and FileMaker Web
Publishing Engine
Tenon Support
support at tenon.com
Fri May 26 10:51:16 MDT 2006
At 11:00 PM -0500 5/25/06, Greg Lane wrote:
>Have you tried removing PHP from the picture? Construct a URL that
>requests a sufficiently large amount of data from FMSA and see if
>Apache responds in the same way. If it does, then the issue has
>nothing to do with FX.php or PHP. I would then try reproducing the
>issue with a vanilla install of OS X and FMSA.
In the limited analysis that Tenon did initially, we eliminated PHP
from the equation. The Apache spike is definitely being triggered by
FM requests. Validating this with a vanilla OS X and FMSA, of
course, would be fine.
We see that you have a two machine set up. We're curious about the
set up because it is our understanding that FMSA doesn't support
Apache 2, let alone Apache 2.2. So, independent of this particular
spiking issue, give us details about this so we can recommend it to
our customers who want to use Apache 2.2 and also want FMSA.
-TTS
>
>Greg
>
>On May 25, 2006, at 4:27 PM, William Vaughn wrote:
>
>>Tenon Technical Support:
>>
>>Your previous analysis of the atitle.PHP script went a long way
>>toward helping me understand the problem we are having with server
>>configuration.
>>
>>We are running iTools 8.2, Tenon PHP 5.1.1, Tenon Tomcat 5.5.9,
>>FX.PHP, and FileMaker Web Publishing 8v3 on a Mac Mini G4 1.25GHz
>>with 1GB RAM (Web Server).
>>
>>A second server is running FileMaker Server Advanced 8v3 on a Mac
>>G4 2.0GHz with 1.5GB RAM (Database Server).
>>
>>The Database Server is running FileMaker Server Advanced and hosts
>>FileMaker databases containing information that will be used to
>>power websites hosted on the Web Server. The Web Server hosts
>>websites using Apache and mod_PHP to publish dynamic content from
>>FileMaker. PHP powered websites use mod_PHP running FX.PHP to
>>communicate with FileMaker. The Web Publishing Engine communicates
>>with FileMaker Server running the Database Server, and makes xml
>>output available to FX.PHP, which in turn processes the data into
>>an HTML document served by Apache. Tenon Tomcat is disabled, as the
>>only reason it is installed is to permit Apache to use the bundled
>>mod_jk connector to communicate with the Web Publishing Engine.
>>
>>I have a test database set up on the Database server with a few
>>tables and a couple of relationships. In one table I have ~5000
>>records with four or five text fields: name, title, date, and
>>description. I designed a PHP page which displayed 500 of those
>>records in a list. At this point I encountered first encountered
>>the problem. When loading the page (it took two or three seconds)
>>the Web Publishing Engine placed a significant load on the
>>processor for two or three seconds while the page was loading. That
>>was expected. What followed was not. One of the Apache httpd
>>processes then pegged the processor at 85%-95%, AFTER the page had
>>loaded in the browser. This was quite confusing. So, I went to the
>>Web Server and opened Safari. I loaded the page. Sure enough, the
>>WPE (Web Publishing Engine) worked for about three seconds and
>>produced the page. Apache did not so much as blink. I set my laptop
>>down next to the KVM and loaded the same page. Lo and behold, the
>>WPE worked for two or three seconds, and the page loaded. Then,
>>once again, Apache pegged the processor for several seconds, AFTER
>>the page had loaded. So I did some experimentation, and found that
>>if I limited the page to about 130 records the problem went away:
>>130 records, and the WPE engine worked for two seconds; 135 records
>>and the WPE worked for the same two seconds, but this time Apache
>>pegged the processor for five to ten seconds after the page had
>>loaded. I experimented more and found that the number of records
>>was not the only factor. Fewer records with more data, or, vice
>>versa, more records with fewer data, would exhibit the aberrant
>>behavior. There was always a distinct limit, which if reached,
>>would cause Apache to go misbehave as described above.
>>
>>I have also run the script with the PHP CLI and , regardless of the
>>number of record the page is set for,it always behaves more or less
>>on a linear scale. (double the records, double the time.)
>>
>>I have thus far disabled the Apache caching (both disk and memory),
>>increased the memory limit for PHP from 8 to 16 MB, and , as
>>previously mentioned, varied the size and number of record
>>processed by the PHP script. None of these efforts, save the
>>reduction in the amount of data requested, have had any effect in
>>resolving Apache's use of CPU AFTER a page has loaded.
>>
>>I very much appreciate your efforts thus far, they have been
>>valuable. However, I would greatly appreciate any further insight
>>you might have regarding this problem.
>>
>>William Vaughn
>>Richard Carlton Consulting, Inc.
>>
>>_______________________________________________
>>FX.php_List mailing list
>>FX.php_List at mail.iviking.org
>>http://www.iviking.org/mailman/listinfo/fx.php_list
--
Tenon Technical Support
232 Anacapa Street, #2A
Santa Barbara, CA 93101
805-963-6983
805-962-8202 FAX
http://www.tenon.com
More information about the FX.php_List
mailing list