View Full Version : Any Hints or Tips to troubleshoot slow page load?


09-18-2009, 11:34 AM
I've seen the post stating that v10 WAS is "wicked fast" - but I'm not managing to see it.

My main grid (80 rows of test data) has a linking field that redirects to another a5w page. That a5w page contains:

1) A 6-column grid displaying 1 row of data (the select limits return to the 1 row as selected in previous main grid and runs in under 0.1s)
2) A 3-column grid displaying up to 5 rows of data (the SQL select runs in under 0.1s)
3) A dialog component consisting of textarea & 3 buttons.

The tables contain test data, no more than 100 rows in any table. The SQL selects each run in under 0.1s for each of the two selects. Yet the page transition/load/render takes 2-3 seconds.

ALSO, the transition on the main grid page, going from First page to Next or Last, also takes several seconds to handle the 80 rows of test data.

This is running against the localhost server (with the a5webroot on a RamDisk) within the A5 IDE. I've published to LAN server a couple times with similar results.

Any helpful suggestions on the matter of how to identify & resolve the lag?

09-18-2009, 11:37 AM

SLEEP() pauses the execution of a script for the specified number of Seconds. Seconds can be a fractional number.

Supported By

Alpha Five Version 5 and Above


Pauses a script for 1/10 of a second.

'script commands


'more script commands

This example displays a message for 5 seconds.



This message will appear for 5 seconds...





See Also

Script Functions

09-18-2009, 11:38 AM
I dont know if the function works for the WAS as well

09-18-2009, 11:40 AM
Ok, you lost me. How does that assist me in troubleshooting the slow page load?

Steve Wood
09-18-2009, 12:33 PM
You can use a Firefox add-in named YSlow to get a broad idea of the bottlenecks. And I would reduce the number of rows to 10 just to test. My "Fast!" note was just baseline, no testing on grids, etc. Also, localhost has always been a lot slower than on the App Server. The sleep() function mentioned below won't really help when you are just bringing up a page for review.

09-18-2009, 01:53 PM
Thank you Steve. That helped tremendously on the main grid page in going from First to Next or Last, etc.

ySlow graded me an "F" for failure to use Expires Headers. So I added the following to the header of my main grid a5w page:

Response.Add_Header("ExpiresDefault " + chr(34) + "access plus 1 years" + chr(34))

The change reduced my render time from almost 3s to roughly 0.5s; still working on the load/render of the second page, though, as there was no noticeable gain.

Thank you for the reference to the useful tool, Steve.

Steve Wood
09-18-2009, 03:17 PM
See, I didn't even know about the response.add_header issue, I will have to try that.

09-18-2009, 03:41 PM
I also reduced the Layout Options Rows of Data from 15 to 10 and that also contributed to improved performance on the main grid page. As I now move from page 1 to page 8 or any page in between (80 rows of data on the DB table), the render is probably 0.25s or so. Absolutely lightning fast (might even consider the word "wicked"!) compared to 2-3s or more before I added the Expires Header and reduced Rows of Data to 10.

I think the Expires Headers approach is applicable only to Apache-based servers, so it may not work for other (ie: MS IIS) platforms - in case you're working with something other than Alpha.

Found some useful posts by Jerry Brightbill:


The second page remains a mystery, though. It's so simple a page, after all. But at least I have something now to chew on.

Lenny Forziati
09-18-2009, 04:42 PM
Be VERY careful about setting an Expires header. If you don't understand what it does, you can end up with undesirable results.

An Expires header tells the browser to store a copy of this response until the specified date. If the same resource is requested again by the user, the browser is supposed to use the stored copy instead of trying to retrieve it from the server. This will certainly speed up your grids, because until the expiration date is reached, your browser isn't going to even contact the server again before displaying the page, resulting in stale data being shown.

Also, ExpiresDefault is an Apache configuration directive, not an HTTP header. To properly set the Expires header, use Response.Expire (new in V10):

Response.Expire("1 year") 'expire 1 year from now
Response.Expire("30 minutes") 'expire in 30 minutes
Response.Expire("Sat, 10 Oct 2009 04:00:00 GMT") 'expire at a specific date/time
Response.Expire(ServerSetting.Session_Timeout + " seconds") 'expire along with the expiration of the A5w session

Or Response.AddHeader (new in V10, supersedes Response.Add_Header):

Response.AddHeader("Expires: " + httpdate(date()+365)) 'expire 1 year from now
Response.AddHeader("Expires", httpdate(date()+365)) 'expire 1 year from now

Response.AddHeader("Expires: " + httpdate(now()+1800)) 'expire in 30 minutes
Response.AddHeader("Expires", httpdate(now()+1800)) 'expire in 30 minutes

Response.AddHeader("Expires: Sat, 10 Oct 2009 04:00:00 GMT") 'expire at a specific date/time
Response.AddHeader("Expires", "Sat, 10 Oct 2009 04:00:00 GMT") 'expire at a specific date/time

Response.AddHeader("Expires: " + httpdate(now() + ServerSetting.Session_Timeout)) 'expire along with the expiration of the A5w session
Response.AddHeader("Expires", httpdate(now() + ServerSetting.Session_Timeout)) 'expire along with the expiration of the A5w session

Or Response.Add_Header (deprecated in V10 so should not be used for new code but continues to work for legacy compatibility):

Response.Add_Header("Expires: " + httpdate(date()+365)) 'expire 1 year from now
Response.Add_Header("Expires: " + httpdate(now()+1800)) 'expire in 30 minutes
Response.Add_Header("Expires: Sat, 10 Oct 2009 04:00:00 GMT") 'expire at a specific date/time
Response.Add_Header("Expires: " + httpdate(now() + ServerSetting.Session_Timeout)) 'expire along with the expiration of the A5w session

09-18-2009, 05:19 PM
I guess the Expires Header is not terribly useful after all - that is, if the browser is caching EVERYTHING about the previous response. Maybe the shortest possible future time might be useful (ie: seconds), but in my application even that could potentially cause problems.

Thanks for the explanation, Lenny.

Back to the drawing board.