Loading...
 

Tikiwiki-devel (mailman list mirror)


After the joke : really, currently "module_action_calendar" can increase x20 cpu time to produce a page with 10.x (will test trunk)

Hi,

Recently I got an incredible increase of answer time of my server (from
a few seconds till 50 sec. for home page).

After a check using Xdebug:profiler I discovered that it was the
module_action_calendar which was using 95% of the CPU working 50 seconds
to produce near 50,000 date conversions (date_format and timezone) with
a database containing 8,000 action_log records... for a maximum of 5
sec. really useful.

I checked the reason : I had just changed the ui language from en to fr
and timezone Paris, this seems to be the direct cause which generates an
incredible number of conversions of dates (all the data base x times  ?).

I think that :
-----------------
- It should be useful to find this problem. -
-----------------

The module cannot be used.

For him, the module_calendar_new uses only 0.1 sec. CPU to be generated

Best regards

Trebly

Data form XDebug Profiler to show the module :
12355 calls of tikilib::date_format for all uses 19.7s
29479 calls of Tikidate::TimezonelsValid for 5.3s

module_action_calendar uses : 34,0s
module_calendar_new uses : 00,108s

Some others elements linked to the module himself, more fine not yet
analyzed, uses twice the time of the need for the full page without the
module.


--------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Hi, this is complements about my previous message

I took a while to work on this problem.

I confirm that the problem concerns all calendars.

The process :
-----
For each date in the calendar database which is concerned we have, when
the calendar has to be used (any date), the call to the “open calendar ”
function, which will convert all the dates of the full data of the
calendar, this automatically (4 calls of date_format and -not yet
analysed- calls for Timezone).

Each time that a component of a page uses a calendar the getcalendar
function of calendarlib is called.

This leads to a great time used for date conversions and can make
explode the CPU need by tiki (95 % of the time after explosion spent to
calculate the date conversions when a calendar with 9,000 dates is
called, 50 sec. to show a page for less than five without calendar).

In my test case, I was just using (the automatic recording of actions )
near 9,000 dates (actions_calendar) but it is the same for any calendar.

It is evident that, when we have only one calendar with just 1,000
dates, the CPU is doubled...


The most critical call stack (reverse) is :

date_format
<< TikiCalendarLib -> list->tiki_items
<< TikiCalendarLib -> list_items_by_day
<< CalendardLib -> getCalendar
<< TikiCalendarLib -> getCalendar
<< module_xxxx_calendar or any calendar edit or show
if module_action_calendar or module_calendar_new or any module_calendar
<< Modlib -> execute_module
<< include_once::tiki-modules.php
<< Smarty_tiki -> fetch
<< Smarty_internal_templateBase -> display
<< Smarty_tiki-> display
<< tiki_index.php

Conclusion :
-----
So calendars are not currently practically usable for calendars with
more than a few dates.

The Calendars are not usable for real use in tiki sites with a normal
number of dates in calendars opened, the feature must be forgotten for
most of practical applications.

The solution is obviously
---------
1- to organize the software so that calls to the conversions (format and
timezone) should be performed only for the dates that are to be
displayed in the current window.
May be a short term solution could be to use a getCalendarTWd ( get
calendar for a window in the time) which will return only the array
between the limits of the dates that are to be displayed. But it is only
a partial workaround, if the span of time is the year the problem can
remain identical.

2- the dates that are got for calendar management and their filters must
be reverse converted from the immediate input.

3- any calculus of dates are made in absolute time with the parameters
of timezone concerned (we keep date as a couple of the absolute date and
the timezone associated)

There is job.

Best regards

Trebly

On 07/03/2013 03:40, Bernard TREMBLAY wrote:
> Hi,
>
> Recently I got an incredible increase of answer time of my server (from
> a few seconds till 50 sec. for home page).
>
> After a check using Xdebug:profiler I discovered that it was the
> module_action_calendar which was using 95% of the CPU working 50 seconds
> to produce near 50,000 date conversions (date_format and timezone) with
> a database containing 8,000 action_log records... for a maximum of 5
> sec. really useful.
>
> I checked the reason : I had just changed the ui language from en to fr
> and timezone Paris, this seems to be the direct cause which generates an
> incredible number of conversions of dates (all the data base x times  ?).
>
> I think that :
> -----------------
> - It should be useful to find this problem. -
> -----------------
>
> The module cannot be used.
>
> For him, the module_calendar_new uses only 0.1 sec. CPU to be generated
>
> Best regards
>
> Trebly
>
> Data form XDebug Profiler to show the module :
> 12355 calls of tikilib::date_format for all uses 19.7s
> 29479 calls of Tikidate::TimezonelsValid for 5.3s
>
> module_action_calendar uses : 34,0s
> module_calendar_new uses : 00,108s
>
> Some others elements linked to the module himself, more fine not yet
> analyzed, uses twice the time of the need for the full page without the
> module.
>
>
> --------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

--------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

I have a calendar with nearly 1,000 events. I use the calendar_new and
upcoming_events modules and have no issues. See http://keycontent.org

-R

Rick Sapir
http://ricksapir.com
http://about.me/ricks99

Creating Content — Managing Information
--- Original Message ---
From: “Bernard TREMBLAY” <bty-tikidev@trebly.net>
To: <tikiwiki-devel@lists.sourceforge.net>
Sent: Friday, March 08, 2013 8:39 PM
Subject: Re: Tiki-devel After the joke : really, currently
“module_action_calendar” can increase x20 cpu time to produce a page with
10.x (will test trunk)


> Hi, this is complements about my previous message
>
> I took a while to work on this problem.
>
> I confirm that the problem concerns all calendars.
>
> The process :
> -----
> For each date in the calendar database which is concerned we have, when
> the calendar has to be used (any date), the call to the “open calendar ”
> function, which will convert all the dates of the full data of the
> calendar, this automatically (4 calls of date_format and -not yet
> analysed- calls for Timezone).
>
> Each time that a component of a page uses a calendar the getcalendar
> function of calendarlib is called.
>
> This leads to a great time used for date conversions and can make
> explode the CPU need by tiki (95 % of the time after explosion spent to
> calculate the date conversions when a calendar with 9,000 dates is
> called, 50 sec. to show a page for less than five without calendar).
>
> In my test case, I was just using (the automatic recording of actions )
> near 9,000 dates (actions_calendar) but it is the same for any calendar.
>
> It is evident that, when we have only one calendar with just 1,000
> dates, the CPU is doubled...
>
>
> The most critical call stack (reverse) is :
>
> date_format
> << TikiCalendarLib -> list->tiki_items
> << TikiCalendarLib -> list_items_by_day
> << CalendardLib -> getCalendar
> << TikiCalendarLib -> getCalendar
> << module_xxxx_calendar or any calendar edit or show
> if module_action_calendar or module_calendar_new or any module_calendar
> << Modlib -> execute_module
> << include_once::tiki-modules.php
> << Smarty_tiki -> fetch
> << Smarty_internal_templateBase -> display
> << Smarty_tiki-> display
> << tiki_index.php
>
> Conclusion :
> -----
> So calendars are not currently practically usable for calendars with
> more than a few dates.
>
> The Calendars are not usable for real use in tiki sites with a normal
> number of dates in calendars opened, the feature must be forgotten for
> most of practical applications.
>
> The solution is obviously
> ---------
> 1- to organize the software so that calls to the conversions (format and
> timezone) should be performed only for the dates that are to be
> displayed in the current window.
> May be a short term solution could be to use a getCalendarTWd ( get
> calendar for a window in the time) which will return only the array
> between the limits of the dates that are to be displayed. But it is only
> a partial workaround, if the span of time is the year the problem can
> remain identical.
>
> 2- the dates that are got for calendar management and their filters must
> be reverse converted from the immediate input.
>
> 3- any calculus of dates are made in absolute time with the parameters
> of timezone concerned (we keep date as a couple of the absolute date and
> the timezone associated)
>
> There is job.
>
> Best regards
>
> Trebly
>
> On 07/03/2013 03:40, Bernard TREMBLAY wrote:
>> Hi,
>>
>> Recently I got an incredible increase of answer time of my server (from
>> a few seconds till 50 sec. for home page).
>>
>> After a check using Xdebug:profiler I discovered that it was the
>> module_action_calendar which was using 95% of the CPU working 50 seconds
>> to produce near 50,000 date conversions (date_format and timezone) with
>> a database containing 8,000 action_log records... for a maximum of 5
>> sec. really useful.
>>
>> I checked the reason : I had just changed the ui language from en to fr
>> and timezone Paris, this seems to be the direct cause which generates an
>> incredible number of conversions of dates (all the data base x times  ?).
>>
>> I think that :
>> -----------------
>> - It should be useful to find this problem. -
>> -----------------
>>
>> The module cannot be used.
>>
>> For him, the module_calendar_new uses only 0.1 sec. CPU to be generated
>>
>> Best regards
>>
>> Trebly
>>
>> Data form XDebug Profiler to show the module :
>> 12355 calls of tikilib::date_format for all uses 19.7s
>> 29479 calls of Tikidate::TimezonelsValid for 5.3s
>>
>> module_action_calendar uses : 34,0s
>> module_calendar_new uses : 00,108s
>>
>> Some others elements linked to the module himself, more fine not yet
>> analyzed, uses twice the time of the need for the full page without the
>> module.
>>
>>
>> --------------------------
>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
>> endpoint security space. For insight on selecting the right partner to
>> tackle endpoint security challenges, access the full report.
>> http://p.sf.net/sfu/symantec-dev2dev
>> ___
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>
> --------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>


--------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Hi,

Thanks rick,

In your case the date calculus can increase a little, depending of the
span of time (day, month, year...), the calculus time. But with 1,000
dates it cannot be important. You have a good case (not the same with
10,000 per year... in action_log)...

May be you have test load time with or without module_calendar ?

Best regards

Trebly

On 09/03/2013 16:28, Rick Sapir wrote:
> I have a calendar with nearly 1,000 events. I use the calendar_new and
> upcoming_events modules and have no issues. See http://keycontent.org
>
> -R
>
> Rick Sapir
> http://ricksapir.com
> http://about.me/ricks99
>
> Creating Content — Managing Information
> --- Original Message ---
> From: “Bernard TREMBLAY” <bty-tikidev@trebly.net>
> To: <tikiwiki-devel@lists.sourceforge.net>
> Sent: Friday, March 08, 2013 8:39 PM
> Subject: Re: Tiki-devel After the joke : really, currently
> “module_action_calendar” can increase x20 cpu time to produce a page with
> 10.x (will test trunk)
>
>
>> Hi, this is complements about my previous message
>>
>> I took a while to work on this problem.
>>
>> I confirm that the problem concerns all calendars.
>>
>> The process :
>> -----
>> For each date in the calendar database which is concerned we have, when
>> the calendar has to be used (any date), the call to the “open calendar ”
>> function, which will convert all the dates of the full data of the
>> calendar, this automatically (4 calls of date_format and -not yet
>> analysed- calls for Timezone).
>>
>> Each time that a component of a page uses a calendar the getcalendar
>> function of calendarlib is called.
>>
>> This leads to a great time used for date conversions and can make
>> explode the CPU need by tiki (95 % of the time after explosion spent to
>> calculate the date conversions when a calendar with 9,000 dates is
>> called, 50 sec. to show a page for less than five without calendar).
>>
>> In my test case, I was just using (the automatic recording of actions )
>> near 9,000 dates (actions_calendar) but it is the same for any calendar.
>>
>> It is evident that, when we have only one calendar with just 1,000
>> dates, the CPU is doubled...
>>
>>
>> The most critical call stack (reverse) is :
>>
>> date_format
>> << TikiCalendarLib -> list->tiki_items
>> << TikiCalendarLib -> list_items_by_day
>> << CalendardLib -> getCalendar
>> << TikiCalendarLib -> getCalendar
>> << module_xxxx_calendar or any calendar edit or show
>> if module_action_calendar or module_calendar_new or any module_calendar
>> << Modlib -> execute_module
>> << include_once::tiki-modules.php
>> << Smarty_tiki -> fetch
>> << Smarty_internal_templateBase -> display
>> << Smarty_tiki-> display
>> << tiki_index.php
>>
>> Conclusion :
>> -----
>> So calendars are not currently practically usable for calendars with
>> more than a few dates.
>>
>> The Calendars are not usable for real use in tiki sites with a normal
>> number of dates in calendars opened, the feature must be forgotten for
>> most of practical applications.
>>
>> The solution is obviously
>> ---------
>> 1- to organize the software so that calls to the conversions (format and
>> timezone) should be performed only for the dates that are to be
>> displayed in the current window.
>> May be a short term solution could be to use a getCalendarTWd ( get
>> calendar for a window in the time) which will return only the array
>> between the limits of the dates that are to be displayed. But it is only
>> a partial workaround, if the span of time is the year the problem can
>> remain identical.
>>
>> 2- the dates that are got for calendar management and their filters must
>> be reverse converted from the immediate input.
>>
>> 3- any calculus of dates are made in absolute time with the parameters
>> of timezone concerned (we keep date as a couple of the absolute date and
>> the timezone associated)
>>
>> There is job.
>>
>> Best regards
>>
>> Trebly
>>
>> On 07/03/2013 03:40, Bernard TREMBLAY wrote:
>>> Hi,
>>>
>>> Recently I got an incredible increase of answer time of my server (from
>>> a few seconds till 50 sec. for home page).
>>>
>>> After a check using Xdebug:profiler I discovered that it was the
>>> module_action_calendar which was using 95% of the CPU working 50 seconds
>>> to produce near 50,000 date conversions (date_format and timezone) with
>>> a database containing 8,000 action_log records... for a maximum of 5
>>> sec. really useful.
>>>
>>> I checked the reason : I had just changed the ui language from en to fr
>>> and timezone Paris, this seems to be the direct cause which generates an
>>> incredible number of conversions of dates (all the data base x times  ?).
>>>
>>> I think that :
>>> -----------------
>>> - It should be useful to find this problem. -
>>> -----------------
>>>
>>> The module cannot be used.
>>>
>>> For him, the module_calendar_new uses only 0.1 sec. CPU to be generated
>>>
>>> Best regards
>>>
>>> Trebly
>>>
>>> Data form XDebug Profiler to show the module :
>>> 12355 calls of tikilib::date_format for all uses 19.7s
>>> 29479 calls of Tikidate::TimezonelsValid for 5.3s
>>>
>>> module_action_calendar uses : 34,0s
>>> module_calendar_new uses : 00,108s
>>>
>>> Some others elements linked to the module himself, more fine not yet
>>> analyzed, uses twice the time of the need for the full page without the
>>> module.
>>>
>>>
>>> --------------------------
>>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>>> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
>>> endpoint security space. For insight on selecting the right partner to
>>> tackle endpoint security challenges, access the full report.
>>> http://p.sf.net/sfu/symantec-dev2dev
>>> ___
>>> TikiWiki-devel mailing list
>>> TikiWiki-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>
>> --------------------------
>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
>> endpoint security space. For insight on selecting the right partner to
>> tackle endpoint security challenges, access the full report.
>> http://p.sf.net/sfu/symantec-dev2dev
>> ___
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>
>
> --------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

--------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Here’s the report from the Tiki Server Stat module:

http://keycontent.org/Home: 1.13 seconds, 36 MB, 145 queries in 0.0 secs

http://keycontent.org/tiki-calendar.php: 1.10 seconds, 28.89 MB, 98 queries
in 0.0 secs

http://keycontent.org/tiki-calendar_edit_item.php 0.72 seconds, 47.52MB, 43
queries in 0.0 secs


Contact me directly for details. The calendar has 1,000s of events and I’ve
never experienced any slowdowns.

-R


Rick Sapir
http://ricksapir.com
http://about.me/ricks99

Creating Content — Managing Information
--- Original Message ---
From: “Bernard TREMBLAY” <bty-tikidev@trebly.net>
To: <tikiwiki-devel@lists.sourceforge.net>
Sent: Sunday, March 10, 2013 8:52 PM
Subject: Re: Tiki-devel After the joke : really, currently
“module_action_calendar” can increase x20 cpu time to produce a page with
10.x (will test trunk)


> Hi,
>
> Thanks rick,
>
> In your case the date calculus can increase a little, depending of the
> span of time (day, month, year...), the calculus time. But with 1,000
> dates it cannot be important. You have a good case (not the same with
> 10,000 per year... in action_log)...
>
> May be you have test load time with or without module_calendar ?
>
> Best regards
>
> Trebly
>
> On 09/03/2013 16:28, Rick Sapir wrote:
>> I have a calendar with nearly 1,000 events. I use the calendar_new and
>> upcoming_events modules and have no issues. See http://keycontent.org
>>
>> -R
>>
>> Rick Sapir
>> http://ricksapir.com
>> http://about.me/ricks99
>>
>> Creating Content — Managing Information
>> --- Original Message ---
>> From: “Bernard TREMBLAY” <bty-tikidev@trebly.net>
>> To: <tikiwiki-devel@lists.sourceforge.net>
>> Sent: Friday, March 08, 2013 8:39 PM
>> Subject: Re: Tiki-devel After the joke : really, currently
>> “module_action_calendar” can increase x20 cpu time to produce a page with
>> 10.x (will test trunk)
>>
>>
>>> Hi, this is complements about my previous message
>>>
>>> I took a while to work on this problem.
>>>
>>> I confirm that the problem concerns all calendars.
>>>
>>> The process :
>>> -----
>>> For each date in the calendar database which is concerned we have, when
>>> the calendar has to be used (any date), the call to the “open calendar ”
>>> function, which will convert all the dates of the full data of the
>>> calendar, this automatically (4 calls of date_format and -not yet
>>> analysed- calls for Timezone).
>>>
>>> Each time that a component of a page uses a calendar the getcalendar
>>> function of calendarlib is called.
>>>
>>> This leads to a great time used for date conversions and can make
>>> explode the CPU need by tiki (95 % of the time after explosion spent to
>>> calculate the date conversions when a calendar with 9,000 dates is
>>> called, 50 sec. to show a page for less than five without calendar).
>>>
>>> In my test case, I was just using (the automatic recording of actions )
>>> near 9,000 dates (actions_calendar) but it is the same for any calendar.
>>>
>>> It is evident that, when we have only one calendar with just 1,000
>>> dates, the CPU is doubled...
>>>
>>>
>>> The most critical call stack (reverse) is :
>>>
>>> date_format
>>> << TikiCalendarLib -> list->tiki_items
>>> << TikiCalendarLib -> list_items_by_day
>>> << CalendardLib -> getCalendar
>>> << TikiCalendarLib -> getCalendar
>>> << module_xxxx_calendar or any calendar edit or show
>>> if module_action_calendar or module_calendar_new or any module_calendar
>>> << Modlib -> execute_module
>>> << include_once::tiki-modules.php
>>> << Smarty_tiki -> fetch
>>> << Smarty_internal_templateBase -> display
>>> << Smarty_tiki-> display
>>> << tiki_index.php
>>>
>>> Conclusion :
>>> -----
>>> So calendars are not currently practically usable for calendars with
>>> more than a few dates.
>>>
>>> The Calendars are not usable for real use in tiki sites with a normal
>>> number of dates in calendars opened, the feature must be forgotten for
>>> most of practical applications.
>>>
>>> The solution is obviously
>>> ---------
>>> 1- to organize the software so that calls to the conversions (format and
>>> timezone) should be performed only for the dates that are to be
>>> displayed in the current window.
>>> May be a short term solution could be to use a getCalendarTWd ( get
>>> calendar for a window in the time) which will return only the array
>>> between the limits of the dates that are to be displayed. But it is only
>>> a partial workaround, if the span of time is the year the problem can
>>> remain identical.
>>>
>>> 2- the dates that are got for calendar management and their filters must
>>> be reverse converted from the immediate input.
>>>
>>> 3- any calculus of dates are made in absolute time with the parameters
>>> of timezone concerned (we keep date as a couple of the absolute date and
>>> the timezone associated)
>>>
>>> There is job.
>>>
>>> Best regards
>>>
>>> Trebly
>>>
>>> On 07/03/2013 03:40, Bernard TREMBLAY wrote:
>>>> Hi,
>>>>
>>>> Recently I got an incredible increase of answer time of my server (from
>>>> a few seconds till 50 sec. for home page).
>>>>
>>>> After a check using Xdebug:profiler I discovered that it was the
>>>> module_action_calendar which was using 95% of the CPU working 50
>>>> seconds
>>>> to produce near 50,000 date conversions (date_format and timezone) with
>>>> a database containing 8,000 action_log records... for a maximum of 5
>>>> sec. really useful.
>>>>
>>>> I checked the reason : I had just changed the ui language from en to fr
>>>> and timezone Paris, this seems to be the direct cause which generates
>>>> an
>>>> incredible number of conversions of dates (all the data base x times
>>>> ?).
>>>>
>>>> I think that :
>>>> -----------------
>>>> - It should be useful to find this problem. -
>>>> -----------------
>>>>
>>>> The module cannot be used.
>>>>
>>>> For him, the module_calendar_new uses only 0.1 sec. CPU to be generated
>>>>
>>>> Best regards
>>>>
>>>> Trebly
>>>>
>>>> Data form XDebug Profiler to show the module :
>>>> 12355 calls of tikilib::date_format for all uses 19.7s
>>>> 29479 calls of Tikidate::TimezonelsValid for 5.3s
>>>>
>>>> module_action_calendar uses : 34,0s
>>>> module_calendar_new uses : 00,108s
>>>>
>>>> Some others elements linked to the module himself, more fine not yet
>>>> analyzed, uses twice the time of the need for the full page without the
>>>> module.
>>>>
>>>>
>>>> --------------------------
>>>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>>>> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
>>>> endpoint security space. For insight on selecting the right partner to
>>>> tackle endpoint security challenges, access the full report.
>>>> http://p.sf.net/sfu/symantec-dev2dev
>>>> ___
>>>> TikiWiki-devel mailing list
>>>> TikiWiki-devel at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>
>>>
>>> --------------------------
>>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>>> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
>>> endpoint security space. For insight on selecting the right partner to
>>> tackle endpoint security challenges, access the full report.
>>> http://p.sf.net/sfu/symantec-dev2dev
>>> ___
>>> TikiWiki-devel mailing list
>>> TikiWiki-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>
>>
>> --------------------------
>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
>> endpoint security space. For insight on selecting the right partner to
>> tackle endpoint security challenges, access the full report.
>> http://p.sf.net/sfu/symantec-dev2dev
>> ___
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>
> --------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>


--------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Hi, Rick

Thanks.

I have gone to each the url that you have given.

I will go further and contact you for details.

Here I have questions of general interest.

With which processor on the server do you have such good results ?

Even my server is not for production (and not parameterized for speed,
just for test and no one pref to optimize neither in Apache, traces in
debug mode etc... and XDebug profiler with his traces)
but the elementary times of calculus and the structure of functions
calls are good.

The processor that I use for the server is an intel Core2 Xtrem quad
X9650 with index 4,409 at
<http://www.cpubenchmark.net/high_end_cpus.html>

At the the top there are The Intel Xeon E5-26xx and E5-46xx with 12.6 to
14.97 performance index.

In time there is too the caches sizes and speed, memory speed etc...
which are determinant for global performance

The problem is that on servers with apache there no natural parallelism
with http requests.
When the software uses well the ob statements and hrefs to fill data the
navigator generates to solve the hrefs others http process and Apaches
creating new processes uses second core etc... as when there are several
users. With tiki generally I have never more than 25% used (I have
developed the slideshow in 8.3 which uses multi request streaming images
and is able of very quick loads using 75% or more of capabilities of the
processor to optimize images)
With height cores (core I7) or Xeon then the time to make calculus can
be divided by a 10th factor or more.

So there is till now, for me, not known explanation to explain so short
time for your beautiful calendar(s).
To know more precisely that it is only xDebug profiler which can
generate traces that can be easily analyzed to know how many date_format
(for example) are performed in which duration to produce the calendar(s)
and operate on them. Then for this calculus we could have a performance
benchmark...

It think that it is interesting for conception to compile such
informations to be able to size the application to manage great
calendars and know where are the limits for whom and why.

It is not urgent, I don’t know how these calendar management problem
(not for you currently) will be included in development strategy.

Best regards

Trebly

On 11/03/2013 15:47, Rick Sapir wrote:
> Here’s the report from the Tiki Server Stat module:
>
> http://keycontent.org/Home: 1.13 seconds, 36 MB, 145 queries in 0.0 secs
>
> http://keycontent.org/tiki-calendar.php: 1.10 seconds, 28.89 MB, 98 queries
> in 0.0 secs
>
> http://keycontent.org/tiki-calendar_edit_item.php 0.72 seconds, 47.52MB, 43
> queries in 0.0 secs
>
>
> Contact me directly for details. The calendar has 1,000s of events and I’ve
> never experienced any slowdowns.
>
> -R
>
>
> Rick Sapir
> http://ricksapir.com
> http://about.me/ricks99
>
> Creating Content — Managing Information
> --- Original Message ---
> From: “Bernard TREMBLAY” <bty-tikidev@trebly.net>
> To: <tikiwiki-devel@lists.sourceforge.net>
> Sent: Sunday, March 10, 2013 8:52 PM
> Subject: Re: Tiki-devel After the joke : really, currently
> “module_action_calendar” can increase x20 cpu time to produce a page with
> 10.x (will test trunk)
>
>
>> Hi,
>>
>> Thanks rick,
>>
>> In your case the date calculus can increase a little, depending of the
>> span of time (day, month, year...), the calculus time. But with 1,000
>> dates it cannot be important. You have a good case (not the same with
>> 10,000 per year... in action_log)...
>>
>> May be you have test load time with or without module_calendar ?
>>
>> Best regards
>>
>> Trebly
>>
>> On 09/03/2013 16:28, Rick Sapir wrote:
>>> I have a calendar with nearly 1,000 events. I use the calendar_new and
>>> upcoming_events modules and have no issues. See http://keycontent.org
>>>
>>> -R
>>>
>>> Rick Sapir
>>> http://ricksapir.com
>>> http://about.me/ricks99
>>>
>>> Creating Content — Managing Information
>>> --- Original Message ---
>>> From: “Bernard TREMBLAY” <bty-tikidev@trebly.net>
>>> To: <tikiwiki-devel@lists.sourceforge.net>
>>> Sent: Friday, March 08, 2013 8:39 PM
>>> Subject: Re: Tiki-devel After the joke : really, currently
>>> “module_action_calendar” can increase x20 cpu time to produce a page with
>>> 10.x (will test trunk)
>>>
>>>
>>>> Hi, this is complements about my previous message
>>>>
>>>> I took a while to work on this problem.
>>>>
>>>> I confirm that the problem concerns all calendars.
>>>>
>>>> The process :
>>>> -----
>>>> For each date in the calendar database which is concerned we have, when
>>>> the calendar has to be used (any date), the call to the “open calendar ”
>>>> function, which will convert all the dates of the full data of the
>>>> calendar, this automatically (4 calls of date_format and -not yet
>>>> analysed- calls for Timezone).
>>>>
>>>> Each time that a component of a page uses a calendar the getcalendar
>>>> function of calendarlib is called.
>>>>
>>>> This leads to a great time used for date conversions and can make
>>>> explode the CPU need by tiki (95 % of the time after explosion spent to
>>>> calculate the date conversions when a calendar with 9,000 dates is
>>>> called, 50 sec. to show a page for less than five without calendar).
>>>>
>>>> In my test case, I was just using (the automatic recording of actions )
>>>> near 9,000 dates (actions_calendar) but it is the same for any calendar.
>>>>
>>>> It is evident that, when we have only one calendar with just 1,000
>>>> dates, the CPU is doubled...
>>>>
>>>>
>>>> The most critical call stack (reverse) is :
>>>>
>>>> date_format
>>>> << TikiCalendarLib -> list->tiki_items
>>>> << TikiCalendarLib -> list_items_by_day
>>>> << CalendardLib -> getCalendar
>>>> << TikiCalendarLib -> getCalendar
>>>> << module_xxxx_calendar or any calendar edit or show
>>>> if module_action_calendar or module_calendar_new or any module_calendar
>>>> << Modlib -> execute_module
>>>> << include_once::tiki-modules.php
>>>> << Smarty_tiki -> fetch
>>>> << Smarty_internal_templateBase -> display
>>>> << Smarty_tiki-> display
>>>> << tiki_index.php
>>>>
>>>> Conclusion :
>>>> -----
>>>> So calendars are not currently practically usable for calendars with
>>>> more than a few dates.
>>>>
>>>> The Calendars are not usable for real use in tiki sites with a normal
>>>> number of dates in calendars opened, the feature must be forgotten for
>>>> most of practical applications.
>>>>
>>>> The solution is obviously
>>>> ---------
>>>> 1- to organize the software so that calls to the conversions (format and
>>>> timezone) should be performed only for the dates that are to be
>>>> displayed in the current window.
>>>> May be a short term solution could be to use a getCalendarTWd ( get
>>>> calendar for a window in the time) which will return only the array
>>>> between the limits of the dates that are to be displayed. But it is only
>>>> a partial workaround, if the span of time is the year the problem can
>>>> remain identical.
>>>>
>>>> 2- the dates that are got for calendar management and their filters must
>>>> be reverse converted from the immediate input.
>>>>
>>>> 3- any calculus of dates are made in absolute time with the parameters
>>>> of timezone concerned (we keep date as a couple of the absolute date and
>>>> the timezone associated)
>>>>
>>>> There is job.
>>>>
>>>> Best regards
>>>>
>>>> Trebly
>>>>
>>>> On 07/03/2013 03:40, Bernard TREMBLAY wrote:
>>>>> Hi,
>>>>>
>>>>> Recently I got an incredible increase of answer time of my server (from
>>>>> a few seconds till 50 sec. for home page).
>>>>>
>>>>> After a check using Xdebug:profiler I discovered that it was the
>>>>> module_action_calendar which was using 95% of the CPU working 50
>>>>> seconds
>>>>> to produce near 50,000 date conversions (date_format and timezone) with
>>>>> a database containing 8,000 action_log records... for a maximum of 5
>>>>> sec. really useful.
>>>>>
>>>>> I checked the reason : I had just changed the ui language from en to fr
>>>>> and timezone Paris, this seems to be the direct cause which generates
>>>>> an
>>>>> incredible number of conversions of dates (all the data base x times
>>>>> ?).
>>>>>
>>>>> I think that :
>>>>> -----------------
>>>>> - It should be useful to find this problem. -
>>>>> -----------------
>>>>>
>>>>> The module cannot be used.
>>>>>
>>>>> For him, the module_calendar_new uses only 0.1 sec. CPU to be generated
>>>>>
>>>>> Best regards
>>>>>
>>>>> Trebly
>>>>>
>>>>> Data form XDebug Profiler to show the module :
>>>>> 12355 calls of tikilib::date_format for all uses 19.7s
>>>>> 29479 calls of Tikidate::TimezonelsValid for 5.3s
>>>>>
>>>>> module_action_calendar uses : 34,0s
>>>>> module_calendar_new uses : 00,108s
>>>>>
>>>>> Some others elements linked to the module himself, more fine not yet
>>>>> analyzed, uses twice the time of the need for the full page without the
>>>>> module.
>>>>>
>>>>>
>>>>> --------------------------
>>>>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>>>>> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
>>>>> endpoint security space. For insight on selecting the right partner to
>>>>> tackle endpoint security challenges, access the full report.
>>>>> http://p.sf.net/sfu/symantec-dev2dev
>>>>> ___
>>>>> TikiWiki-devel mailing list
>>>>> TikiWiki-devel at lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>>
>>>>
>>>> --------------------------
>>>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>>>> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
>>>> endpoint security space. For insight on selecting the right partner to
>>>> tackle endpoint security challenges, access the full report.
>>>> http://p.sf.net/sfu/symantec-dev2dev
>>>> ___
>>>> TikiWiki-devel mailing list
>>>> TikiWiki-devel at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>
>>>
>>>
>>> --------------------------
>>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>>> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
>>> endpoint security space. For insight on selecting the right partner to
>>> tackle endpoint security challenges, access the full report.
>>> http://p.sf.net/sfu/symantec-dev2dev
>>> ___
>>> TikiWiki-devel mailing list
>>> TikiWiki-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>
>> --------------------------
>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
>> endpoint security space. For insight on selecting the right partner to
>> tackle endpoint security challenges, access the full report.
>> http://p.sf.net/sfu/symantec-dev2dev
>> ___
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>
>
> --------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

--------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel



On 2013-03-12 22:08, Bernard TREMBLAY wrote:
> Hi, Rick
>
> Thanks.
>
> I have gone to each the url that you have given.
>
> I will go further and contact you for details.
>
> Here I have questions of general interest.
>
> With which processor on the server do you have such good results ?
>

KeyContent.org runs basic shared hosting from BlueHost.... nothing
special at all.

-R


Creating content — Managing information
www.ricksapir.com
Twitter: @ricksapir

--------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Quick note... I do not see the action calendar module on keycontent.

--
LP


On Wed, Mar 13, 2013 at 8:34 AM, Rick Sapir <rick@ricksapir.com> wrote:

>
>
> On 2013-03-12 22:08, Bernard TREMBLAY wrote:
> > Hi, Rick
> >
> > Thanks.
> >
> > I have gone to each the url that you have given.
> >
> > I will go further and contact you for details.
> >
> > Here I have questions of general interest.
> >
> > With which processor on the server do you have such good results ?
> >
>
> KeyContent.org runs basic shared hosting from BlueHost.... nothing
> special at all.
>
> -R
>
> ---
> Creating content — Managing information
> www.ricksapir.com
> Twitter: @ricksapir
>
>
> --------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

That’s correct. As stated earlier, I’m only using calendar_new and
upcoming_events

-R


Creating content — Managing information
www.ricksapir.com
Twitter: @ricksapir

On 2013-03-13 11:32, Louis-Philippe Huberdeau wrote:
> Quick note... I do not see the action calendar module on keycontent.
>
> --
> LP
>
> On Wed, Mar 13, 2013 at 8:34 AM, Rick Sapir <rick@ricksapir.com>
> wrote:
>
>> On 2013-03-12 22:08, Bernard TREMBLAY wrote:
>> > Hi, Rick
>> >
>> > Thanks.
>> >
>> > I have gone to each the url that you have given.
>> >
>> > I will go further and contact you for details.
>> >
>> > Here I have questions of general interest.
>> >
>> > With which processor on the server do you have such good results ?
>> >
>>
>> KeyContent.org runs basic shared hosting from BlueHost.... nothing
>> special at all.
>>
>> -R
>>
>> ---
>> Creating content — Managing information
>> www.ricksapir.com 1
>> Twitter: @ricksapir
>>
>>
>> --------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar 2
>> ___
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel 3

--------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

posts: 1768 Catalan Countries

Mmm, in that site where adding event to the calendar is so slow, *I have
no module related to calendars* (other than since_last_visit_new; i.e.
no side module for calendar, or upcoming events, etc).

So to me, this looks like some slooow process in either calendar
internals, or email sending (from user and group watches) internals.
I should definitely learn how to use the xDebug and the trace that you
say, Bernard... (maybe my goal for a next tiki fest...)

Regarding email sending... I’m curious to understand then why sending
newsletters from a tiki site can be so fast (many emails sent per
second, according to the log shown in the newsletter interface), and
adding a simple event to a calendar is so slow in my sites...

If I’m able to find some time to learn howto setup the whole xdebug and
trace thing, I’ll do it. (no time currently, unluckily)

Cheers, and thanks for feedback so far.

Xavi


On 13/03/13 18:55, Rick Sapir wrote:
> That’s correct. As stated earlier, I’m only using calendar_new and
> upcoming_events
>
> -R
>
> ---
> Creating content — Managing information
> www.ricksapir.com
> Twitter: @ricksapir
>
> On 2013-03-13 11:32, Louis-Philippe Huberdeau wrote:
>> Quick note... I do not see the action calendar module on keycontent.
>>
>> --
>> LP
>>
>> On Wed, Mar 13, 2013 at 8:34 AM, Rick Sapir <rick@ricksapir.com>
>> wrote:
>>
>>> On 2013-03-12 22:08, Bernard TREMBLAY wrote:
>>>> Hi, Rick
>>>>
>>>> Thanks.
>>>>
>>>> I have gone to each the url that you have given.
>>>>
>>>> I will go further and contact you for details.
>>>>
>>>> Here I have questions of general interest.
>>>>
>>>> With which processor on the server do you have such good results ?
>>>>
>>> KeyContent.org runs basic shared hosting from BlueHost.... nothing
>>> special at all.
>>>
>>> -R
>>>
>>> ---
>>> Creating content — Managing information
>>> www.ricksapir.com 1
>>> Twitter: @ricksapir
>>>


Hi, Xavier

For xDebug, xDebug profiler and analyzer I will produce here when needed
all the parameters to set in php.ini (their meaning with links to
documentation) and way to activate.
I have done it only for Windows XP and Win7, for php everything is
identical on unix servers the difference is only for the analyzer which
is not the same. But it is not a problem, it is a simple software
installation in a few minutes.
With these informations, everything can be done in half an hour, and
another hour for the use of analyzer and get results.

The alone problem has been for me to install a private server (I have it
near me) because I was before in the mode of shared hosting resources by
OVH and they don’t provide xDebug.

Best regards,

Trebly

On 14/03/2013 11:02, Xavier de Pedro wrote:
> Mmm, in that site where adding event to the calendar is so slow, *I have
> no module related to calendars* (other than since_last_visit_new; i.e.
> no side module for calendar, or upcoming events, etc).
>
> So to me, this looks like some slooow process in either calendar
> internals, or email sending (from user and group watches) internals.
> I should definitely learn how to use the xDebug and the trace that you
> say, Bernard... (maybe my goal for a next tiki fest...)
>
> Regarding email sending... I’m curious to understand then why sending
> newsletters from a tiki site can be so fast (many emails sent per
> second, according to the log shown in the newsletter interface), and
> adding a simple event to a calendar is so slow in my sites...
>
> If I’m able to find some time to learn howto setup the whole xdebug and
> trace thing, I’ll do it. (no time currently, unluckily)
>
> Cheers, and thanks for feedback so far.
>
> Xavi
>
>
> On 13/03/13 18:55, Rick Sapir wrote:
>> That’s correct. As stated earlier, I’m only using calendar_new and
>> upcoming_events
>>
>> -R
>>
>> ---
>> Creating content — Managing information
>> www.ricksapir.com
>> Twitter: @ricksapir
>>
>> On 2013-03-13 11:32, Louis-Philippe Huberdeau wrote:
>>> Quick note... I do not see the action calendar module on keycontent.
>>>
>>> --
>>> LP
>>>
>>> On Wed, Mar 13, 2013 at 8:34 AM, Rick Sapir <rick@ricksapir.com>
>>> wrote:
>>>
>>>> On 2013-03-12 22:08, Bernard TREMBLAY wrote:
>>>>> Hi, Rick
>>>>>
>>>>> Thanks.
>>>>>
>>>>> I have gone to each the url that you have given.
>>>>>
>>>>> I will go further and contact you for details.
>>>>>
>>>>> Here I have questions of general interest.
>>>>>
>>>>> With which processor on the server do you have such good results ?
>>>>>
>>>> KeyContent.org runs basic shared hosting from BlueHost.... nothing
>>>> special at all.
>>>>
>>>> -R
>>>>
>>>> ---
>>>> Creating content — Managing information
>>>> www.ricksapir.com 1
>>>> Twitter: @ricksapir
>>>>
>
>
>
> --------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
>
>
>
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

--------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Hi, Xavier

a second part of answer :

- may be the event creation runs a setCalendar but as there is no
related display of calendar the window in time is set to begin(first)
and end (last) dates of calendar, then setCalendar converts the whole
calendar. In event creation not any format should not be called, only
the converted date of event to absolute datetime should be inserted.
XDebug will tell this.

Best regards

trebly

On 14/03/2013 11:02, Xavier de Pedro wrote:
> Mmm, in that site where adding event to the calendar is so slow, *I have
> no module related to calendars* (other than since_last_visit_new; i.e.
> no side module for calendar, or upcoming events, etc).
>
> So to me, this looks like some slooow process in either calendar
> internals, or email sending (from user and group watches) internals.
> I should definitely learn how to use the xDebug and the trace that you
> say, Bernard... (maybe my goal for a next tiki fest...)
>
> Regarding email sending... I’m curious to understand then why sending
> newsletters from a tiki site can be so fast (many emails sent per
> second, according to the log shown in the newsletter interface), and
> adding a simple event to a calendar is so slow in my sites...
>
> If I’m able to find some time to learn howto setup the whole xdebug and
> trace thing, I’ll do it. (no time currently, unluckily)
>
> Cheers, and thanks for feedback so far.
>
> Xavi
>
>
> On 13/03/13 18:55, Rick Sapir wrote:
>> That’s correct. As stated earlier, I’m only using calendar_new and
>> upcoming_events
>>
>> -R
>>
>> ---
>> Creating content — Managing information
>> www.ricksapir.com
>> Twitter: @ricksapir
>>
>> On 2013-03-13 11:32, Louis-Philippe Huberdeau wrote:
>>> Quick note... I do not see the action calendar module on keycontent.
>>>
>>> --
>>> LP
>>>
>>> On Wed, Mar 13, 2013 at 8:34 AM, Rick Sapir <rick@ricksapir.com>
>>> wrote:
>>>
>>>> On 2013-03-12 22:08, Bernard TREMBLAY wrote:
>>>>> Hi, Rick
>>>>>
>>>>> Thanks.
>>>>>
>>>>> I have gone to each the url that you have given.
>>>>>
>>>>> I will go further and contact you for details.
>>>>>
>>>>> Here I have questions of general interest.
>>>>>
>>>>> With which processor on the server do you have such good results ?
>>>>>
>>>> KeyContent.org runs basic shared hosting from BlueHost.... nothing
>>>> special at all.
>>>>
>>>> -R
>>>>
>>>> ---
>>>> Creating content — Managing information
>>>> www.ricksapir.com 1
>>>> Twitter: @ricksapir
>>>>
>
>
>
> --------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
>
>
>
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

--------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Hi, LP

Just comment : why speak about the actions calendar ?

No really matter with action calendar, it is only one of the modules or
plugin which are using calculus of calendar and his display.

I found the problem with action calendar because I have set the option
with near 8,000 events. My test calendars are small, only some hundreds
of dates.
I don’t know why tiki had to convert all the dates this is the most
important problem.

Xavier seems to have may be the same problem sometimes.
It can comes from start end end limits dates in getCalendar set to the
min and max dates when setcalendar is called (the whole span of the
calendar).

I have explained that the problem comes from the repeated calculus
date_format and timeZone executed as function called by getcalendar.

LP has said everything about the future solution. It remains just to
understand where is the current problem, then to be able to avoid that
some sites could have worse situations that the 50 seconds met by Xavier
to define a new event (in a calendar_new).

The CPU use depends of number of dates involved in a calendar calculus,
normally only for display of a short window in time, so no problem
should exist and certainly not when a new event is defined.

With 8ms by date on my server if calculus involves many dates
(thousands) it increases and can use for 10,000 dates 98% of resources
to produce the page and 20xtime the basic time to produce a whole common
page.


Trebly

On 13/03/2013 16:32, Louis-Philippe Huberdeau wrote:
> Quick note... I do not see the action calendar module on keycontent.
>
> --
> LP
>
>
> On Wed, Mar 13, 2013 at 8:34 AM, Rick Sapir <rick@ricksapir.com
> <mailto:rick@ricksapir.com>> wrote:
>
>
>
> On 2013-03-12 22:08, Bernard TREMBLAY wrote:
> > Hi, Rick
> >
> > Thanks.
> >
> > I have gone to each the url that you have given.
> >
> > I will go further and contact you for details.
> >
> > Here I have questions of general interest.
> >
> > With which processor on the server do you have such good results ?
> >
>
> KeyContent.org runs basic shared hosting from BlueHost.... nothing
> special at all.
>
> -R
>
> ---
> Creating content — Managing information
> www.ricksapir.com <http://www.ricksapir.com>
> Twitter: @ricksapir
>
> --------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> <mailto:TikiWiki-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
>
>
> --------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
>
>
>
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

--------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Hi, Rick

I will upload my test site on my OVH hosting and compare treatment
duration (on OVH as on BlueHost I imagine no profiler can be run.. nor
xDebug, it is one of the main reason I have built a little local private
server for development tests).

In my answer to LP you will find my aim on this problem.

Trebly

On 13/03/2013 13:34, Rick Sapir wrote:
>
>
> On 2013-03-12 22:08, Bernard TREMBLAY wrote:
>> Hi, Rick
>>
>> Thanks.
>>
>> I have gone to each the url that you have given.
>>
>> I will go further and contact you for details.
>>
>> Here I have questions of general interest.
>>
>> With which processor on the server do you have such good results ?
>>
>
> KeyContent.org runs basic shared hosting from BlueHost.... nothing
> special at all.
>
> -R
>
> ---
> Creating content — Managing information
> www.ricksapir.com
> Twitter: @ricksapir
>
> --------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

--------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

posts: 1768 Catalan Countries

I have no clue myself where the issue/s is/are in the code, but as end
user I know that each time that we add a single new event to the
calendar (tiki 9 svn), Tiki takes between 5 and 10 seconds to come back
into a responsive state.

Maybe because a dozen of people are subscribed to the calendar, or who
knows (we have 6 calendars defined in that tiki, with a dozen events per
month or so in total). Using the fullcalendar interface, btw.

Our calendar shows dates in the the time zone specified by Tiki (not the
browsers, etc).

I can share a db dump if any dev is willing to debug the calendar
internals to behave at similar speeds as the rest of Tiki, and not much
slower than the rest of tiki, as nowadays, when you have some real data
inside the calendar for production.

Xavi

On 09/03/13 16:28, Rick Sapir wrote:
> I have a calendar with nearly 1,000 events. I use the calendar_new and
> upcoming_events modules and have no issues. See http://keycontent.org
>
> -R
>
> Rick Sapir
> http://ricksapir.com
> http://about.me/ricks99
>
> Creating Content — Managing Information
> --- Original Message ---
> From: “Bernard TREMBLAY” <bty-tikidev@trebly.net>
> To: <tikiwiki-devel@lists.sourceforge.net>
> Sent: Friday, March 08, 2013 8:39 PM
> Subject: Re: Tiki-devel After the joke : really, currently
> “module_action_calendar” can increase x20 cpu time to produce a page with
> 10.x (will test trunk)
>
>
>> Hi, this is complements about my previous message
>>
>> I took a while to work on this problem.
>>
>> I confirm that the problem concerns all calendars.
>>
>> The process :
>> -----
>> For each date in the calendar database which is concerned we have, when
>> the calendar has to be used (any date), the call to the “open calendar ”
>> function, which will convert all the dates of the full data of the
>> calendar, this automatically (4 calls of date_format and -not yet
>> analysed- calls for Timezone).
>>
>> Each time that a component of a page uses a calendar the getcalendar
>> function of calendarlib is called.
>>
>> This leads to a great time used for date conversions and can make
>> explode the CPU need by tiki (95 % of the time after explosion spent to
>> calculate the date conversions when a calendar with 9,000 dates is
>> called, 50 sec. to show a page for less than five without calendar).
>>
>> In my test case, I was just using (the automatic recording of actions )
>> near 9,000 dates (actions_calendar) but it is the same for any calendar.
>>
>> It is evident that, when we have only one calendar with just 1,000
>> dates, the CPU is doubled...
>>
>>
>> The most critical call stack (reverse) is :
>>
>> date_format
>> << TikiCalendarLib -> list->tiki_items
>> << TikiCalendarLib -> list_items_by_day
>> << CalendardLib -> getCalendar
>> << TikiCalendarLib -> getCalendar
>> << module_xxxx_calendar or any calendar edit or show
>> if module_action_calendar or module_calendar_new or any module_calendar
>> << Modlib -> execute_module
>> << include_once::tiki-modules.php
>> << Smarty_tiki -> fetch
>> << Smarty_internal_templateBase -> display
>> << Smarty_tiki-> display
>> << tiki_index.php
>>
>> Conclusion :
>> -----
>> So calendars are not currently practically usable for calendars with
>> more than a few dates.
>>
>> The Calendars are not usable for real use in tiki sites with a normal
>> number of dates in calendars opened, the feature must be forgotten for
>> most of practical applications.
>>
>> The solution is obviously
>> ---------
>> 1- to organize the software so that calls to the conversions (format and
>> timezone) should be performed only for the dates that are to be
>> displayed in the current window.
>> May be a short term solution could be to use a getCalendarTWd ( get
>> calendar for a window in the time) which will return only the array
>> between the limits of the dates that are to be displayed. But it is only
>> a partial workaround, if the span of time is the year the problem can
>> remain identical.
>>
>> 2- the dates that are got for calendar management and their filters must
>> be reverse converted from the immediate input.
>>
>> 3- any calculus of dates are made in absolute time with the parameters
>> of timezone concerned (we keep date as a couple of the absolute date and
>> the timezone associated)
>>
>> There is job.
>>
>> Best regards
>>
>> Trebly
>>
>> On 07/03/2013 03:40, Bernard TREMBLAY wrote:
>>> Hi,
>>>
>>> Recently I got an incredible increase of answer time of my server (from
>>> a few seconds till 50 sec. for home page).
>>>
>>> After a check using Xdebug:profiler I discovered that it was the
>>> module_action_calendar which was using 95% of the CPU working 50 seconds
>>> to produce near 50,000 date conversions (date_format and timezone) with
>>> a database containing 8,000 action_log records... for a maximum of 5
>>> sec. really useful.
>>>
>>> I checked the reason : I had just changed the ui language from en to fr
>>> and timezone Paris, this seems to be the direct cause which generates an
>>> incredible number of conversions of dates (all the data base x times  ?).
>>>
>>> I think that :
>>> -----------------
>>> - It should be useful to find this problem. -
>>> -----------------
>>>
>>> The module cannot be used.
>>>
>>> For him, the module_calendar_new uses only 0.1 sec. CPU to be generated
>>>
>>> Best regards
>>>
>>> Trebly
>>>
>>> Data form XDebug Profiler to show the module :
>>> 12355 calls of tikilib::date_format for all uses 19.7s
>>> 29479 calls of Tikidate::TimezonelsValid for 5.3s
>>>
>>> module_action_calendar uses : 34,0s
>>> module_calendar_new uses : 00,108s
>>>
>>> Some others elements linked to the module himself, more fine not yet
>>> analyzed, uses twice the time of the need for the full page without the
>>> module.
>>>
>>>


--------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Hi,

There is no real bug, it is a way to work on data which generates
important calculus on server (when it has been written they were not
really others manners to do it).

The problem is that there are date_format and timeZone for the dates
concerned by a request to show or edit the calendar.
Each datetime generates a minimum of 8 ms of calculus (on a CPU Intel of
family Quad XTrem at 3GHz).

The effect depends of the processor capacity. I have just a quad XTrem
at 3GHz, but these calculus load only one core.
So the CPU time is currently of 5sec. while Eric is telling about 1sec.
or less.

The time while tiki doesn’t react is probably pure CPU time.

To confirm the analyze, the dbdump is partially useful, to be sure of
the amount of data. The dump is only for the “calendar” tables.
But the more important would be to have a xDebug profiler trace.

If you have already xDebug installed, there are some parameters to set
in php.ini to launch for test. This generates files (often quite large
files, a full tiki page generates near 40Mo of Xdebug). They cannot be
analyzed manually, so after I can analyze these files. The most
interesting is to make a trace for your request for new event.
I generally configure the xDebug parameters to produce a separate trace
for each http request, most of time a simple request they are,
nevertheless, several files produced. With the datetime and the url, it
is easy to know which is the right and most interesting file.
Then, the analyze will give all useful information to understand the
nature of the calculus done.

Basically we know what happens. The solution will come with a new version.

It is interesting to have more accurate informations on your experience
on calendars but it is not necessary for development (rewrite with
different principles).
Versus it can be important for you if your calendar should be enlarged.
The most important is to know where are the limits with the extension of
the size of database, but further the number of dates focused by the
requests. Optimization can be found and dispositions can be taken to
avoid an unexpected too large increase of the treatments durations.

Best regards

Trebly

On 11/03/2013 10:13, Xavier de Pedro wrote:
> I have no clue myself where the issue/s is/are in the code, but as end
> user I know that each time that we add a single new event to the
> calendar (tiki 9 svn), Tiki takes between 5 and 10 seconds to come back
> into a responsive state.
>
> Maybe because a dozen of people are subscribed to the calendar, or who
> knows (we have 6 calendars defined in that tiki, with a dozen events per
> month or so in total). Using the fullcalendar interface, btw.
>
> Our calendar shows dates in the the time zone specified by Tiki (not the
> browsers, etc).
>
> I can share a db dump if any dev is willing to debug the calendar
> internals to behave at similar speeds as the rest of Tiki, and not much
> slower than the rest of tiki, as nowadays, when you have some real data
> inside the calendar for production.
>
> Xavi
>
> On 09/03/13 16:28, Rick Sapir wrote:
>> I have a calendar with nearly 1,000 events. I use the calendar_new and
>> upcoming_events modules and have no issues. See http://keycontent.org
>>
>> -R
>>
>> Rick Sapir
>> http://ricksapir.com
>> http://about.me/ricks99
>>
>> Creating Content — Managing Information
>> --- Original Message ---
>> From: “Bernard TREMBLAY” <bty-tikidev@trebly.net>
>> To: <tikiwiki-devel@lists.sourceforge.net>
>> Sent: Friday, March 08, 2013 8:39 PM
>> Subject: Re: Tiki-devel After the joke : really, currently
>> “module_action_calendar” can increase x20 cpu time to produce a page with
>> 10.x (will test trunk)
>>
>>
>>> Hi, this is complements about my previous message
>>>
>>> I took a while to work on this problem.
>>>
>>> I confirm that the problem concerns all calendars.
>>>
>>> The process :
>>> -----
>>> For each date in the calendar database which is concerned we have, when
>>> the calendar has to be used (any date), the call to the “open calendar ”
>>> function, which will convert all the dates of the full data of the
>>> calendar, this automatically (4 calls of date_format and -not yet
>>> analysed- calls for Timezone).
>>>
>>> Each time that a component of a page uses a calendar the getcalendar
>>> function of calendarlib is called.
>>>
>>> This leads to a great time used for date conversions and can make
>>> explode the CPU need by tiki (95 % of the time after explosion spent to
>>> calculate the date conversions when a calendar with 9,000 dates is
>>> called, 50 sec. to show a page for less than five without calendar).
>>>
>>> In my test case, I was just using (the automatic recording of actions )
>>> near 9,000 dates (actions_calendar) but it is the same for any calendar.
>>>
>>> It is evident that, when we have only one calendar with just 1,000
>>> dates, the CPU is doubled...
>>>
>>>
>>> The most critical call stack (reverse) is :
>>>
>>> date_format
>>> << TikiCalendarLib -> list->tiki_items
>>> << TikiCalendarLib -> list_items_by_day
>>> << CalendardLib -> getCalendar
>>> << TikiCalendarLib -> getCalendar
>>> << module_xxxx_calendar or any calendar edit or show
>>> if module_action_calendar or module_calendar_new or any module_calendar
>>> << Modlib -> execute_module
>>> << include_once::tiki-modules.php
>>> << Smarty_tiki -> fetch
>>> << Smarty_internal_templateBase -> display
>>> << Smarty_tiki-> display
>>> << tiki_index.php
>>>
>>> Conclusion :
>>> -----
>>> So calendars are not currently practically usable for calendars with
>>> more than a few dates.
>>>
>>> The Calendars are not usable for real use in tiki sites with a normal
>>> number of dates in calendars opened, the feature must be forgotten for
>>> most of practical applications.
>>>
>>> The solution is obviously
>>> ---------
>>> 1- to organize the software so that calls to the conversions (format and
>>> timezone) should be performed only for the dates that are to be
>>> displayed in the current window.
>>> May be a short term solution could be to use a getCalendarTWd ( get
>>> calendar for a window in the time) which will return only the array
>>> between the limits of the dates that are to be displayed. But it is only
>>> a partial workaround, if the span of time is the year the problem can
>>> remain identical.
>>>
>>> 2- the dates that are got for calendar management and their filters must
>>> be reverse converted from the immediate input.
>>>
>>> 3- any calculus of dates are made in absolute time with the parameters
>>> of timezone concerned (we keep date as a couple of the absolute date and
>>> the timezone associated)
>>>
>>> There is job.
>>>
>>> Best regards
>>>
>>> Trebly
>>>
>>> On 07/03/2013 03:40, Bernard TREMBLAY wrote:
>>>> Hi,
>>>>
>>>> Recently I got an incredible increase of answer time of my server (from
>>>> a few seconds till 50 sec. for home page).
>>>>
>>>> After a check using Xdebug:profiler I discovered that it was the
>>>> module_action_calendar which was using 95% of the CPU working 50 seconds
>>>> to produce near 50,000 date conversions (date_format and timezone) with
>>>> a database containing 8,000 action_log records... for a maximum of 5
>>>> sec. really useful.
>>>>
>>>> I checked the reason : I had just changed the ui language from en to fr
>>>> and timezone Paris, this seems to be the direct cause which generates an
>>>> incredible number of conversions of dates (all the data base x times  ?).
>>>>
>>>> I think that :
>>>> -----------------
>>>> - It should be useful to find this problem. -
>>>> -----------------
>>>>
>>>> The module cannot be used.
>>>>
>>>> For him, the module_calendar_new uses only 0.1 sec. CPU to be generated
>>>>
>>>> Best regards
>>>>
>>>> Trebly
>>>>
>>>> Data form XDebug Profiler to show the module :
>>>> 12355 calls of tikilib::date_format for all uses 19.7s
>>>> 29479 calls of Tikidate::TimezonelsValid for 5.3s
>>>>
>>>> module_action_calendar uses : 34,0s
>>>> module_calendar_new uses : 00,108s
>>>>
>>>> Some others elements linked to the module himself, more fine not yet
>>>> analyzed, uses twice the time of the need for the full page without the
>>>> module.
>>>>
>>>>
>
>
> --------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and “remains a good choice” in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

--------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


Quick note... I do not see the action calendar module on keycontent.

--
LP


On Wed, Mar 13, 2013 at 8:34 AM, Rick Sapir <rick@ricksapir.com> wrote:

>
>
> On 2013-03-12 22:08, Bernard TREMBLAY wrote:
> > Hi, Rick
> >
> > Thanks.
> >
> > I have gone to each the url that you have given.
> >
> > I will go further and contact you for details.
> >
> > Here I have questions of general interest.
> >
> > With which processor on the server do you have such good results ?
> >
>
> KeyContent.org runs basic shared hosting from BlueHost.... nothing
> special at all.
>
> -R
>
> ---
> Creating content — Managing information
> www.ricksapir.com
> Twitter: @ricksapir
>
>
> --------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

That’s correct. As stated earlier, I’m only using calendar_new and
upcoming_events

-R


Creating content — Managing information
www.ricksapir.com
Twitter: @ricksapir

On 2013-03-13 11:32, Louis-Philippe Huberdeau wrote:
> Quick note... I do not see the action calendar module on keycontent.
>
> --
> LP
>
> On Wed, Mar 13, 2013 at 8:34 AM, Rick Sapir <rick@ricksapir.com>
> wrote:
>
>> On 2013-03-12 22:08, Bernard TREMBLAY wrote:
>> > Hi, Rick
>> >
>> > Thanks.
>> >
>> > I have gone to each the url that you have given.
>> >
>> > I will go further and contact you for details.
>> >
>> > Here I have questions of general interest.
>> >
>> > With which processor on the server do you have such good results ?
>> >
>>
>> KeyContent.org runs basic shared hosting from BlueHost.... nothing
>> special at all.
>>
>> -R
>>
>> ---
>> Creating content — Managing information
>> www.ricksapir.com 1
>> Twitter: @ricksapir
>>
>>
>> --------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar 2
>> ___
>> TikiWiki-devel mailing list
>> TikiWiki-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel 3

--------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

posts: 1768 Catalan Countries

Mmm, in that site where adding event to the calendar is so slow, *I have
no module related to calendars* (other than since_last_visit_new; i.e.
no side module for calendar, or upcoming events, etc).

So to me, this looks like some slooow process in either calendar
internals, or email sending (from user and group watches) internals.
I should definitely learn how to use the xDebug and the trace that you
say, Bernard... (maybe my goal for a next tiki fest...)

Regarding email sending... I’m curious to understand then why sending
newsletters from a tiki site can be so fast (many emails sent per
second, according to the log shown in the newsletter interface), and
adding a simple event to a calendar is so slow in my sites...

If I’m able to find some time to learn howto setup the whole xdebug and
trace thing, I’ll do it. (no time currently, unluckily)

Cheers, and thanks for feedback so far.

Xavi


On 13/03/13 18:55, Rick Sapir wrote:
> That’s correct. As stated earlier, I’m only using calendar_new and
> upcoming_events
>
> -R
>
> ---
> Creating content — Managing information
> www.ricksapir.com
> Twitter: @ricksapir
>
> On 2013-03-13 11:32, Louis-Philippe Huberdeau wrote:
>> Quick note... I do not see the action calendar module on keycontent.
>>
>> --
>> LP
>>
>> On Wed, Mar 13, 2013 at 8:34 AM, Rick Sapir <rick@ricksapir.com>
>> wrote:
>>
>>> On 2013-03-12 22:08, Bernard TREMBLAY wrote:
>>>> Hi, Rick
>>>>
>>>> Thanks.
>>>>
>>>> I have gone to each the url that you have given.
>>>>
>>>> I will go further and contact you for details.
>>>>
>>>> Here I have questions of general interest.
>>>>
>>>> With which processor on the server do you have such good results ?
>>>>
>>> KeyContent.org runs basic shared hosting from BlueHost.... nothing
>>> special at all.
>>>
>>> -R
>>>
>>> ---
>>> Creating content — Managing information
>>> www.ricksapir.com 1
>>> Twitter: @ricksapir
>>>


Hi, Xavier

For xDebug, xDebug profiler and analyzer I will produce here when needed
all the parameters to set in php.ini (their meaning with links to
documentation) and way to activate.
I have done it only for Windows XP and Win7, for php everything is
identical on unix servers the difference is only for the analyzer which
is not the same. But it is not a problem, it is a simple software
installation in a few minutes.
With these informations, everything can be done in half an hour, and
another hour for the use of analyzer and get results.

The alone problem has been for me to install a private server (I have it
near me) because I was before in the mode of shared hosting resources by
OVH and they don’t provide xDebug.

Best regards,

Trebly

On 14/03/2013 11:02, Xavier de Pedro wrote:
> Mmm, in that site where adding event to the calendar is so slow, *I have
> no module related to calendars* (other than since_last_visit_new; i.e.
> no side module for calendar, or upcoming events, etc).
>
> So to me, this looks like some slooow process in either calendar
> internals, or email sending (from user and group watches) internals.
> I should definitely learn how to use the xDebug and the trace that you
> say, Bernard... (maybe my goal for a next tiki fest...)
>
> Regarding email sending... I’m curious to understand then why sending
> newsletters from a tiki site can be so fast (many emails sent per
> second, according to the log shown in the newsletter interface), and
> adding a simple event to a calendar is so slow in my sites...
>
> If I’m able to find some time to learn howto setup the whole xdebug and
> trace thing, I’ll do it. (no time currently, unluckily)
>
> Cheers, and thanks for feedback so far.
>
> Xavi
>
>
> On 13/03/13 18:55, Rick Sapir wrote:
>> That’s correct. As stated earlier, I’m only using calendar_new and
>> upcoming_events
>>
>> -R
>>
>> ---
>> Creating content — Managing information
>> www.ricksapir.com
>> Twitter: @ricksapir
>>
>> On 2013-03-13 11:32, Louis-Philippe Huberdeau wrote:
>>> Quick note... I do not see the action calendar module on keycontent.
>>>
>>> --
>>> LP
>>>
>>> On Wed, Mar 13, 2013 at 8:34 AM, Rick Sapir <rick@ricksapir.com>
>>> wrote:
>>>
>>>> On 2013-03-12 22:08, Bernard TREMBLAY wrote:
>>>>> Hi, Rick
>>>>>
>>>>> Thanks.
>>>>>
>>>>> I have gone to each the url that you have given.
>>>>>
>>>>> I will go further and contact you for details.
>>>>>
>>>>> Here I have questions of general interest.
>>>>>
>>>>> With which processor on the server do you have such good results ?
>>>>>
>>>> KeyContent.org runs basic shared hosting from BlueHost.... nothing
>>>> special at all.
>>>>
>>>> -R
>>>>
>>>> ---
>>>> Creating content — Managing information
>>>> www.ricksapir.com 1
>>>> Twitter: @ricksapir
>>>>
>
>
>
> --------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
>
>
>
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

--------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Hi, Xavier

a second part of answer :

- may be the event creation runs a setCalendar but as there is no
related display of calendar the window in time is set to begin(first)
and end (last) dates of calendar, then setCalendar converts the whole
calendar. In event creation not any format should not be called, only
the converted date of event to absolute datetime should be inserted.
XDebug will tell this.

Best regards

trebly

On 14/03/2013 11:02, Xavier de Pedro wrote:
> Mmm, in that site where adding event to the calendar is so slow, *I have
> no module related to calendars* (other than since_last_visit_new; i.e.
> no side module for calendar, or upcoming events, etc).
>
> So to me, this looks like some slooow process in either calendar
> internals, or email sending (from user and group watches) internals.
> I should definitely learn how to use the xDebug and the trace that you
> say, Bernard... (maybe my goal for a next tiki fest...)
>
> Regarding email sending... I’m curious to understand then why sending
> newsletters from a tiki site can be so fast (many emails sent per
> second, according to the log shown in the newsletter interface), and
> adding a simple event to a calendar is so slow in my sites...
>
> If I’m able to find some time to learn howto setup the whole xdebug and
> trace thing, I’ll do it. (no time currently, unluckily)
>
> Cheers, and thanks for feedback so far.
>
> Xavi
>
>
> On 13/03/13 18:55, Rick Sapir wrote:
>> That’s correct. As stated earlier, I’m only using calendar_new and
>> upcoming_events
>>
>> -R
>>
>> ---
>> Creating content — Managing information
>> www.ricksapir.com
>> Twitter: @ricksapir
>>
>> On 2013-03-13 11:32, Louis-Philippe Huberdeau wrote:
>>> Quick note... I do not see the action calendar module on keycontent.
>>>
>>> --
>>> LP
>>>
>>> On Wed, Mar 13, 2013 at 8:34 AM, Rick Sapir <rick@ricksapir.com>
>>> wrote:
>>>
>>>> On 2013-03-12 22:08, Bernard TREMBLAY wrote:
>>>>> Hi, Rick
>>>>>
>>>>> Thanks.
>>>>>
>>>>> I have gone to each the url that you have given.
>>>>>
>>>>> I will go further and contact you for details.
>>>>>
>>>>> Here I have questions of general interest.
>>>>>
>>>>> With which processor on the server do you have such good results ?
>>>>>
>>>> KeyContent.org runs basic shared hosting from BlueHost.... nothing
>>>> special at all.
>>>>
>>>> -R
>>>>
>>>> ---
>>>> Creating content — Managing information
>>>> www.ricksapir.com 1
>>>> Twitter: @ricksapir
>>>>
>
>
>
> --------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
>
>
>
> ___
> TikiWiki-devel mailing list
> TikiWiki-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

--------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
TikiWiki-devel mailing list
TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


Why Register?

Register at tiki.org and you'll be able to use the account at any *.tiki.org site, thanks to the InterTiki feature. A valid email address is required to receive site notifications and occasional newsletters. You can opt out of these items at any time.