[imp] Individual messages taking 77 seconds to open.

[Vijay Sankar]

Quoting Joseph Mays <mays at win.net>:

> I have traced down somewhat to finding out where delay occurs in message.php.
>
> It is happening at line 257 in my message.php:   if  
> (!$imp_contents->buildMessage()) {
>
> So it's somewhere in buildMessage() function. Does anyone have any  
> clue what that function does in message.php and what might be  
> causing the 77 second delay for some people?
>
> -----Original Message----- From: Jan Schneider
> Sent: Tuesday, May 28, 2019 2:16 PM
> To: imp at lists.horde.org
> Subject: Re: [imp] Individual messages taking 77 seconds to open.
>
> You could use Xdebug or Blackfire to profile this script to find out
> where it's spending the time (most probably waiting).
>
> Zitat von Joseph Mays <mays at win.net>:
>
>>> do you see a pattern in the users who have this issue, like having a
>>> certain locale?
>>
>> I have been trying to identify something they have in common, but   
>> thus far have not. One handy aspect of this issue is that *I* have   
>> the problem and thus can replicate it. The support person for this   
>> system, however, does not have the problem, and thus spent some  
>> time  very confused about some calls he was receiving before first   
>> reporting it.
>>
>> I have ruled out browser version -- have tried Chrome, Explorer,   
>> Firefox, all have the problem.
>>
>> I have ruled out reverse dns.
>>
>> Note that I am only human, and thus might have overlooked  
>> something.  I would be happy to hear any suggestion about something  
>> that would  cause this problem in message.php (and only  
>> message.php), even if  it's something I thought I had ruled out.
>>
>> -----Original Message----- From: Ralf Lang
>> Sent: Monday, May 27, 2019 6:57 AM
>> To: imp at lists.horde.org
>> Subject: Re: [imp] Individual messages taking 77 seconds to open.
>>
>> Hi Joseph,
>>
>> Am 24.05.19 um 22:03 schrieb Joseph Mays:
>>> I’m working on a server that is using, in production what is   
>>> admittedly a very old version of horde imp. Still, the server has   
>>> been there unchanged for a few years. A strange problem has   
>>> developed in one aspect of horde imp in the last couple of months,  
>>>  though.
>>>
>>> Everything about the server is fine, except that some users (not   
>>> all) are having a problem when it comes to clicking on a message  
>>> in  the inbox and opening it. Opening the message takes almost  
>>> exactly  (I have timed it with a stopwatch many times) 77 seconds  
>>> to open.  Every other aspect of the horde server works fine and  
>>> responds  immediately.
>>>
>>> I have tried calling the horde imp webmail interface through both   
>>> ssl and non ssl versions. Both have the same problem. We have a   
>>> squirrelmail webmail interface that works with the same imap   
>>> server. It does not have this problem. We have other imap   
>>> interfaces that work fine. The problem is just some users of the   
>>> horde imp software, and specifically only with calling message.php  
>>>  through horde.
>>>
>>> I have put wireshark on the browser system and watched the  
>>> communication. The get request for message.php is sent immediately  
>>>  by the server when the link is clicked in the inbox. The server   
>>> acks the response, but the get request does not show up in the   
>>> webserver logs. Then, for 77 seconds, nothing apparently happens  
>>> on  either the client or server side (except for the sidebar.php   
>>> refreshes, which work fine through this whole process). Then, 77   
>>> seconds later, the get request appears in the webserver log, is   
>>> responded to immediately, and the message appears in the browser   
>>> interface.
>>>
>>> I have been going through every timeout I can find, php.ini, ssl,   
>>> the horde imp configuaration, nothing makes any difference. The   
>>> webserver seems to be processing *something* in message.php,  
>>> timing  out, and then going ahead and sending the message.
>>>
>>> At this point I would be happy to hear any ideas someone might have.
>>>
>>> I’ve set php to E_ALL for logging, nothing appears in the  
>>> webserver access or error logs beyond the http exchange.
>>
>> do you see a pattern in the users who have this issue, like having a
>> certain locale?
>>
>> -- 
>> Ralf Lang
>> Linux Consultant / Developer
>> Tel.: +49-170-6381563
>> Mail: lang at b1-systems.de
>> B1 Systems GmbH
>> Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
>> GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
>>
>> -- 
>> imp mailing list
>> Frequently Asked Questions: http://wiki.horde.org/FAQ
>> To unsubscribe, mail: imp-unsubscribe at lists.horde.org
>
>
>
> -- 
> Jan Schneider
> The Horde Project
> https://www.horde.org/
>
> -- 
> imp mailing list
> Frequently Asked Questions: http://wiki.horde.org/FAQ
> To unsubscribe, mail: imp-unsubscribe at lists.horde.org -- imp mailing list
> Frequently Asked Questions: http://wiki.horde.org/FAQ
> To unsubscribe, mail: imp-unsubscribe at lists.horde.org

Hopefully I am not sending you down the wrong path in debugging your  
problem but will share a problem/solution that may have some relevance.

FWIW, I had a similar issue that was difficult to debug and by sheer  
luck figured out the solution. The user in this case had too many  
devices and was using an iPhone all the time, two iPads at home on  
weekends, Webmail and Outlook 2011 from his Macbook on the road, and  
Outlook on a Windows 7 client at work to access email on the mail  
server.

He was used to accepting and rejecting meeting requests from whichever  
platform he was using and quite often all the calendar entries would  
be out of sync, entries deleted from one system remained on another,  
events created on one was not visible on the other etc. This was  
because he was not always on the VPN to the mail server while updating  
his calendar entries and the iPhone, iPad etc., also were replicating  
all sorts of stuff to iCloud. To complicate matters further, he would  
move meeting requests (email messages) to the wrong folder in Outlook  
or keep Calendar entries in his email folders. Whenever he did that,  
opening any email message through webmail would be quite slow (2  
minutes typically). I discovered this only because I made him bring  
all his devices to our lab, and wasted a whole day trying to simulate  
the problem. I never realized a user would do something like that. My  
solution in this case was to tell him to accept and decline meeting  
invites ONLY on the iPhone, NOT use Outlook 2016 for Calendar and  
Tasks, and be patient re. syncs.

Hope this is helpful information.

All the best,

Vijay


-- 
ForeTell Technologies Limited
59 Flamingo Avenue
Winnipeg, MB, Canada
R3J 0X6