[FX.php List] Troubleshooting poor performance and intermittent time outs

Wed Dec 12 17:25:30 MST 2007

I like to troubleshoot by reducing the variables.

I would do the following:

- Make copy of the data base and mount it in FMSA
- Remove all relationships from the target table
- Create new layout with only 1 field on it. This is the best 
possible case for performance.
- Elminate the sort
- Test response using that setup.

If performance is still a problem, you are probably looking at your 
code, file size and server horsepower.

If not, then start adding to the layout until all your fields are on. 
Test along the way. Native fields first.

Gradually, rebuild the existing setup until you get back to where you are now.

Hopefully, there will be a "Eureka" moment along the way.

Hope that helps.

Jonathan

At 4:30 PM -0600 12/12/07, Jamie Adams wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>	boundary="----_=_NextPart_001_01C83D0F.0E1D5ECE"
>
>Hello all,
>I'm running a small FX.php app to generate live reports for clients. 
>I've got everything more or less working, but performance and 
>reliability still escape me.  Pages occasionally take up to 90 
>seconds to load (T1, not dial-up), which I can live with, but it's 
>hardly ideal.  What is more of an issue is the instances in which 
>pages never load.  I have about 7 PHP pages and that all work 
>sometimes.  Some more frequently than others.
>
>But occasionally they all go into a state in which you can wait 
>forever for them to load, and nothing happens.  The browser's status 
>bar will say we're waiting for the server.  There is one page that 
>seems more prone this problem than others, although its code is 
>shorter and simpler than the others.  For all the pages, including 
>this one, I got one template that worked, and modified it to create 
>the other pages.  So most of the code is very, very similar.  And 
>let's not forget that all the pages work sometimes.  Sometimes it 
>seems  that the longer I've been logged in to the app, the less it 
>works.  But other times, I have the problem immediately after 
>logging in, or more rarely while attempting to login.  Usually, once 
>one page fails to ever load, no other pages will until I logout and 
>log back in.  That's not to say that logging out and logging back in 
>fixes it.  Sometimes it does, and sometimes it doesn't.  The random 
>and intermittent nature of the problem has me looking and feeling 
>like an idiot.  From reading other posts on this mailing list, I 
>think FX.php has worked better for most of you.  I have some 
>theories about where I might be going wrong, and I'd like to share 
>them and see which ones you all think are likely, and which are not.
>
>First some basic stats about my app, database, and infrastructure:
>-All FileMaker components (FMSA, WPE, CWP, FMAPP) are running on a 
>single Windows server with Dual 2GHz Opteron CPUs, SATA drives, and 
>a gig of RAM, running on our local network.
>-All web components are (PHP, FX.php, HTML, and images) hosted by 
>our web host in another state, possibly a shared server, running 
>linux, specs unknown
>-Local network has a T1 internet connection, also used by our 
>office's client machines (10-20), and a couple other servers
>-The main database is roughly 8GB, about 40,000 records in the largest table
>-We have about 10-20 local FMAPP users from 9-5, and I would be 
>surprised to see more than 10 concurrent web users (thus far haven't 
>had more than 3)
>-My PHP pages have a single FMFind query with 1-5 parameters, a sort 
>parameter, and a skip parameter
>
>To me, the servers and connections seem adequate, and the demands 
>seem modest.  Still, I've had a few thoughts:
>-The database file is a bit large, which might cause some trouble. 
>I know it seems to slowdown finds performed in FMPro.
>-The separation of the web server and FileMaker server might be 
>causing some problems; especially as our Internet connection is not 
>always the greatest.
>-I could be doing something moronic in my FX.php/PHP code.  It 
>wouldn't be the first time.
>-I've always secretly believed the Internet was infested with space 
>demons bent on world domination, and this could be part of their 
>scheme.
>
>Also, I can send you a login to witness the issue, or the code to 
>any of my pages, upon request.  I just didn't want to publish them 
>to the entire planet.
>
>Jamie Adams
>________________________________________________________
>
>Liquis, Inc.
>
>400 Parker Drive, Suite 1110, Austin, TX 78728
>phone 512.299.9634, ext 103 -- fax 512.873.0575
>________________________________________________________
>
><http://www.liquis.com>www.liquis.com
><http://www.auctionpartner.com>www.auctionpartner.com
><http://www.furniture-partner.com>www.furniture-partner.com
>eBay Store: 
><http://stores.ebay.com/Auction-Partner-High-Tech-Equipment?refid=store>http://stores.ebay.com/Auction-Partner-High-Tech-Equipment?refid=store
>
>_______________________________________________
>FX.php_List mailing list
>FX.php_List at mail.iviking.org
>http://www.iviking.org/mailman/listinfo/fx.php_list

-- 
Jonathan Schwartz
Exit 445 Group
jonathan at exit445.com
http://www.exit445.com
415-381-1852
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.iviking.org/pipermail/fx.php_list/attachments/20071212/d87c1830/attachment.html