273645 - slow reload of remote calendar from apache webdav server

Status: RESOLVED WORKSFORME

(Calendar :: Provider: ICS/WebDAV, defect)

Description

[Brian Vereschagin]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041206 Firefox/1.0
Build Identifier: Sunbird/0.2 Sunbird/0.2b

I am using mozilla calendar in an office environment, 4 workstations are set up
to work with 7 calendars in an apache webdav directory. Two of the workstations
are loading the calendars at about one calendar every 10 seconds, and the other
two will reload all 7 in under a second. 

They are all using the same copy of windows xp pro(different licenses ofcourse).
The problem seemed to be occuring on the 2 faster computers (pentium 4s), and
not on the other 2 (duron 700, p3 550), however after further testing I have
realized that new users on the "proporly working" computers also exhibit these
delays. They are all connected to the same 100mb switch including the server,
and all computers are operating at 100mbit.

I installed mozilla calendar onto the linux partition of the duron 700 and it
exhibits the problem in this case. On the same computer a different user in
windows will have the difficulties with delay, maybe there is something special
about the one profile that is working fast. Additional users with fresh profiles
will exhibit these delays.

I believe apache is configured correctly as it works prefecty on 2 of the
profiles. I have tried the update without SSL and it seems to make no difference. 

Reproducible: Always
Steps to Reproduce:
1. Load mozilla calendar
2. Right click on the calendars and click "Reload Remote Calendars"
3. Wait
Actual Results:  
Linux: The animated reload icon appears to the right of the first entry and the
program freezes until all calendars are reloaded (takes over a minute).
Windows:Same thing but the reload icon sometimes updates its position to the
next calendar, but also freezes and often skips this update.
In both cases the calendars do eventually reload properly

Expected Results:  
Reload of all calendars in under a second.

Packet analysis indicates that the calendar data in all cases is downloaded in
less than a second however this http transfer seems to end in a few duplicate
acks sent to the server and then nothing happens for 10-20 seconds. With apache
2.0.50 this delay is ended with a response by the apache server of fin,ack
packets, the client acks it and the calendar program resumes responding.

I tried upgrading to apache 2.0.52 and now the fin,ack packets are never sent,
however the calendar program still takes the same ammount of time with no
traffic over the line and then eventually just unfreezes. This process takes the
same ammount of time as it did with the previous version of apache. 

Also adding to the time the update process takes is a failed attempt to retrieve
the ics file without authentication credentials. This is happening even though I
have saved the password. Once again a delay where no traffic is sent
occurs(about 5 seconds) and it tries again with the actual password and gets the
  vcalendar information in a split second (and then waits for *something* for a
good 10-20 seconds as indicated above).

Comment 1

[Michiel van Leeuwen (email: mvl+moz@)]

Are all users loading the same calendars?
What version of calendar is used?

Comment 2

[Brian Vereschagin]

(In reply to comment #1)
> Are all users loading the same calendars?
> What version of calendar is used?

calendar_windows_20040910.xpi
calendar_windows_20041104.xpi
calendar_windows_20041112.xpi

These were used on all of the workstations the speed of calendar reloading
remained the same for each workstation.

In linux on the duron 700 calendar_linux_20041112.xpi and
sunbird-i686-pc-linux-gnu.tar.gz(same release date i think).

They were generally on the same version at any given time.

Comment 3

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 4

[Martin Schröder [:mschroeder]]

Is this bug still valid although it is two years old? Are there other bugs for improving performance in this area? -> qawanted

Comment 5

[cmtalbert]

I have tested this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070102 Calendar/0.4a1

BuildID: 2007010203

And Apache webdav 2.0.58.

This issue seems to be resolved either by updates in Apache or by the significant improvements made in calendar over these last years (my guess is the later).

Either way, I am going to mark it WFM. Reporter, if you can still reproduce it, please open a bug and attach an ICS file that demonstrates the problem.

Comment 6

[Damian Szczepanik]

I suggest to prepare small performance test to verify this issue - it will be helpful also in the future