Apex Code Development You need to sign in to do that
Don't have an account?
RDN_LHR Visualforce Page takes AGES to load in Production (c.eu0.visual.force.com)
Hi,
I've created a simple Visualforce page and a simple controller. I've created a Web tab and pointed it at the page's url. Clicking on the tab simply gives a list of our org's unread emails related to Cases. Most times it takes over 30 seconds to load and render, even though it's only returning 20 or so rows at any given time.
The page:
<apex:page controller="emailController" tabstyle="emailmessage" sidebar="true"> <apex:pageBlock > <apex:pageBlockTable value="{!emails}" var="m"> <apex:column headerValue="Case" value="{!m.ParentId}"/> <apex:column headerValue="Closed" value="{!m.Parent.IsClosed}"/> <apex:column headerValue="Received" value="{!m.messagedate}"/> <apex:column headerValue="Owner" value="{!m.Parent.Owner.Name}"/> <apex:column value="{!m.fromaddress}"/> <apex:column value="{!m.toaddress}"/> <apex:column value="{!m.subject}"/> </apex:pageBlockTable> </apex:pageBlock> </apex:page>
The controller:
public class emailController { List<EmailMessage> emails = [select id,ParentId, Parent.Owner.Name,Parent.IsClosed, Parent.ClosedDate,status,fromaddress,toaddress,messagedate,subject from emailMessage where status ='0' order by Parent.IsClosed asc, messagedate desc ]; public List<EmailMessage> getEmails() { return emails; } }
What could possibly be causing a 30-second delay on this? I'm not saying that Salesforce.com performs that fantastically in the best of times for those of us on European instances, but 30 seconds for such a simple page is a little bit absurd.
Any input is greatly appreciated!!
Why did you create a web tab if you could create a Visualforce tab? I don't know if this will have a direct effect on load time but there may be something weird go on when you do this.
Regardless, for this type of simple controller and page it should not take this long, unless you are on a ridiculousy slow connection.
The thing is that I'm on a ridiculously fast connection. I suspect that one in Europe doesn't get the same response as one gets in Seattle. Even still, Salesforce's common mantra is to try to blame it on my ISP, the weather, astrology, you name it, anything that keeps them from admitting anything.
Still, user adoption is a hard battle if every third, fourth or fifth time you load a page, it takes 18-30 seconds, and only that page. It's this kind of reliability problem that nobody up in the cloud wants anyone to talk about.
I was really hoping it was something I did. At least I can fix that. Why a Web Tab instead of a Visualforce tab? I'd guess it was because old habits die hard. I don't expect a miracle by making that change but I'll be hoping for one nonetheless.
That's unfortunate to hear. We are hosted on na3 with users in APAC and EMEA that access visualforce pages much more complicated than your example and they have never reported any performance issues.
Unfortunetly your code looks fine as long as that query doesn't return too many results so it appears to be a network issue somewhere along the line.
Have you confirmed it's not your controller? If you got setup - admin - monitoring - debug logs, you can flag a user's requests to be logged. Alternative of course is just to use the System Log window.
The debug log confirms:
***Begining Page Log for /apex/unreademails 20090611083504.365:Class.emailController: line 3, column 35: SOQL query with 13 rows finished in 25278 ms 20090611083504.365:External entry point: returning LIST:SOBJECT:EmailMessage from method public LIST:SOBJECT:EmailMessage getEmails() in 1 ms Cumulative profiling information: 1 most expensive SOQL operations: Class.emailController: line 3, column 35: [select id,ParentId, Parent.Owner.Name,Parent.IsClosed, Parent.ClosedDate,status,fromaddress,toaddress,messagedate,subject from emailMessage where status ='0' order by Parent.IsClosed asc, messagedate desc ]: executed 1 time in 25278 ms No profiling information for SOSL operations. No profiling information for DML operations. 1 most expensive method invocations: Class.emailController: line 8, column 33: public LIST:SOBJECT:EmailMessage getEmails(): executed 1 time in 1 ms ***Ending Page Log for /apex/unreademails?inst=2
but when run again a minute later:
***Begining Page Log for /apex/unreademails 20090611083922.218:Class.emailController: line 3, column 35: SOQL query with 13 rows finished in 3911 ms 20090611083922.218:External entry point: returning LIST:SOBJECT:EmailMessage from method public LIST:SOBJECT:EmailMessage getEmails() in 0 ms Cumulative profiling information: 1 most expensive SOQL operations: Class.emailController: line 3, column 35: [select id,ParentId, Parent.Owner.Name,Parent.IsClosed, Parent.ClosedDate,status,fromaddress,toaddress,messagedate,subject from emailMessage where status ='0' order by Parent.IsClosed asc, messagedate desc ]: executed 1 time in 3911 ms No profiling information for SOSL operations. No profiling information for DML operations. 1 most expensive method invocations: Class.emailController: line 8, column 33: public LIST:SOBJECT:EmailMessage getEmails(): executed 1 time in 0 ms ***Ending Page Log for /apex/unreademails
Four seconds is almost tolerable. 25 seconds is really quite bad. Each time, the query returned the same 13 rows.
Doug, you're the greatest!
Hi guys ... I opened case number 2719575 on June 11. Its status is currently "Escalated" though I've not heard a thing since then.
I had to beg and threaten just to get it escalated as you'll see from the notes.
How could a sort that returns say, ten records have a performance problem on an "ORDER BY" clause? Just sounds a little odd to me that such a big multitenanted thing can't handle sorting ten records.
Also, the problem is intermittent. So five to ten minutes later, you might run the same script and get the return quickly. Sometimes you'll get the return quickly, and then five minutes later, the same resulting rows return slowly.
It's because it's an unindexed column coming via a join. Multitenant or not, basic database physics still apply.
The reason it comes back faster if you do the same query again is because the data has been cached by that point, so it's not doing nearly as many disk accesses to get it.
Why do I get decent response times on the na instance and not on the eu instance?
Does anyone out there know what the difference is infrastructure-wise? From where I sit, when I pit them against each other, and na is always faster. If they're both multitenanted, then the amount of data in my org itself isn't really a factor, and database physics apply to both.
I really find it hard to believe they're giving EMEA the same throughput they're giving NA. Just the amount of time it takes to render the same pages in EMEA as opposed to what I get on NA is indication enough.
I've modified the SOQL as suggested above. Even after the modification, it's still running at anywhere from 2 seconds to 9.2 seconds. This is with me leaving hours between requests so that I leave ample time for the result to fall out of the query cache.
This 9.2 seconds is 9.2 seconds of server time out of the debug log, not including the extra 3 or 4 seconds it takes to render pages on emea. This query is returning five rows.
When I do the query my way, unmodified and on NA, I get a 1.1 sec response returning about 30 rows, including the offending sort. The query's not been run in the NA account for a week and a half, I've got the only login. That gives it plenty of time to fall out of the cache.
With such wide differences in performance with two browsers open side by side on the same machine, what else am I to conclude than that EMEA gets short shrift?
hi, I am in Canada but my VF pages are very slow to load. > 25 seconds!
my post with screenshot
Hi,
I am having a very similar issue. We are on na28, and there is one page that loads in seconds when opened in Europe, but that takes almost one minute to load from anywhere in the US...
Then, once the page has been loaded once in the US, there is some kind of caching that happens because the loading of that same page with different parameters will load in seconds.
I was wondering if you ever got your issue resolved.