Closed Bug 273645 Opened 16 years ago Closed 14 years ago
slow reload of remote calendar from apache webdav server
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).
Are all users loading the same calendars? What version of calendar is used?
(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.
Reassigning all automatically assigned bugs from Mostafa to firstname.lastname@example.org Bugspam filter: TorontoMostafaMove
Assignee: mostafah → nobody
Component: General → Provider: ICS/Webdav
QA Contact: general → ics-provider
Is this bug still valid although it is two years old? Are there other bugs for improving performance in this area? -> qawanted
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.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
I suggest to prepare small performance test to verify this issue - it will be helpful also in the future
Whiteboard: [qa discussion needed]
You need to log in before you can comment on or make changes to this bug.