[FX.php List] Apache anolmaly with Fx.php and FileMaker Web Publishing Engine

Greg Lane glane at moyergroup.com
Thu May 25 22:00:49 MDT 2006


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.

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



More information about the FX.php_List mailing list