[Vtigercrm-developers] Shared Calendar performance

[Alan Bell]

looks like it has already been reported
https://code.google.com/p/fullcalendar/issues/detail?id=1405

Alan.
On 22/01/15 05:06, Prasad wrote:
> Alan,
>
> Would be great if you can file the same on fullcalendar issue tracker 
> too. I'm sure there was a reason for turning off the ajax-rendering. 
> Please update the issue link here too.
>
> --
> FB <http://www.facebook.com/vtiger> I Twit 
> <http://twitter.com/vtigercrm> I LIn 
> <https://www.linkedin.com/company/1270573?trk=tyah> I Blog 
> <https://blogs.vtiger.com> I Website <https://www.vtiger.com/>
>
> On Thu, Jan 22, 2015 at 10:21 AM, Uma S <uma.s at vtiger.com 
> <mailto:uma.s at vtiger.com>> wrote:
>
>     Hi Alan,
>
>     Thanks! for the notification and quick fix regarding the calendar
>     performance issue.
>
>     I have raised a ticket in trac
>     <http://trac.vtiger.com/cgi-bin/trac.cgi/ticket/8402#ticket> for
>     same. Please do update your further observations regarding this
>     here in trac. we will look into this soon.
>
>     On Mon, Jan 19, 2015 at 8:27 PM, Alan Bell
>     <alan.bell at libertus.co.uk <mailto:alan.bell at libertus.co.uk>> wrote:
>
>         Hi all,
>
>         at the moment the shared calendar in vtiger does one request
>         per person to get the events, so if you have 20 people in the
>         calendar that is 20 POST requests to vtiger, with form data like:
>
>         module:Calendar
>         action:Feed
>         start:2013-12-29
>         end:2014-02-09
>         type:Events
>         userid:70
>         color:#7e5c1d
>         textColor:white
>
>         browsers have a limit of 6 parallel requests per server (the
>         RFC says it should only be 2) and this isn't going to change
>         (Google say that if it is a problem then your web application
>         is broken, not their browser), this means that it can't get
>         the data for more than 6 people until one of the first
>         requests has come back, this means that if you have more than
>         6 people on the calendar it starts to slow down rather a lot.
>         You also don't get any clue that anything is happening until
>         they all show up at once. This is because around line 925 of
>         libraries/fullcalendar/fullcalendar.js there is a little bit
>         of code that stops it rendering the calendar until the count
>         of pending requests is zero. Commenting out the if statement
>         like this:
>
>                                         //if (!pendingSourceCnt) {
>         reportEvents(cache);
>                                         //}
>
>         makes it render the calendars progressively. It isn't any
>         faster overall, but it looks more responsive. At the moment it
>         does ajax requests to progressively get the data, but it
>         doesn't show the user anything until all the data has arrived,
>         which in my opinion is not really doing ajax properly.
>
>         The real solution to this is to have a multi-id feed request
>         for the calendar, so it does one request containing an array
>         of IDs and colours and this gets processed on the server and
>         there is a single response with all of the data. Is this
>         something that is going to happen in a future release or
>         should I crack on and write it in this one?
>
>         Alan.
>         _______________________________________________
>         http://www.vtiger.com/
>
>
>
>
>     -- 
>     With
>     Best Regards
>     Uma.S
>     Vtiger Team
>
>     _______________________________________________
>     http://www.vtiger.com/
>
>
>
>
> _______________________________________________
> http://www.vtiger.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20150122/6b2f0518/attachment.html>