Many CalendarAJAXCall.ashx requests are made to the K2 server and slows performance

  • 16 February 2021
  • 0 replies

Userlevel 4
Badge +17

Many CalendarAJAXCall.ashx requests are made to the K2 server and slows performance


K2 Five
K2 blackpearl
K2 Five (all)
This article was created in response to a support issue logged with K2. The content may include typographical errors and may be revised at any time without notice. This article is not considered official documentation for K2 software and is provided "as is" with no warranties.


While troubleshooting Form performance, a large number of AJAX calls are made back to the server one after another. In a Network Trace they will have the name "CalendarAJAXCall.ashx". This slows down performance of the Form and it will take longer to load.


This happens when you create a To Date or To DateTime conversion function in an expression. This is needed to do a "To UTC" conversion based on the server date time, but the problem is that these calls are all made one after another, and there is no real way to change that.

In the environment we lose in total about 1.5 seconds on these Date conversion functions - this works out to about 30% of the total form load time. There is a way that this can be improved so that the calls can be made concurrently to not lose so much time.


Here is an example to reproduce the issue using an Expression:



Look at the code that causes the extra CalendarAjax call. This call is made from a method to parse the supplied value to the correct object type, so the calendar control can correctly display the date(time).

This method has a few checks and cases where it can get the correct object without going to the server, but in the case where the supplied type is a date, and the required object type is a datetime, it has to go to the server.

For example, if you use the ToDate conversion method to supply the value, and the control is set to Date, it can easily get the correct object type. But if the control is set to datetime, it needs to include timezone info of the server, and thus it has to contact the server.

The same goes for a string value, this also has no timezone info, and has to go to the server to convert it correctly.

There is a check just before the server call to check if the string is in zulu format (ex 2018-04-24 05:00:00Z), and if not then to do the call.

To batch this into one call or to improve the performance is possible for certain scenarios, but it will require quite a bit of rework. 

In summary:
1. A conversion is needed for Date to DateTime.
2. Batching might be possible, but will be a big undertaking.
3. You could change the control’s type to a Date instead of a DateTime. If it's set to only show the Date, you don't need to include Time. This also has no AJAX call. The best scenario would be to keep the control type the same as the source and destination (which seems to be the date).
4. If it has to be a DateTime type calendar control, complete the following workaround:

4.1 To Date ( Add Days ( Now ( ) , 5 ) ) , we have found a workaround given a ToDate conversion.
4.2 Add this in a ConvertToDateTime:

To Date and Time ( To Date ( Add Days ( Now ( ) , 5 ) ) )

- This adds time to adjust for timezones to bring the value back to 00:00:00 local time for the control.
- The time can be manipulated for timezone differences if needed by AddingSubtracting hours.
- This causes no AJAX call and the control still shows the date as before.

0 replies

Be the first to reply!