[Kss-devel] Optimizing polling with kss timeout

[Balazs Ree]

> I'm busy writing an instant messenger client for Plone using kss.

The problem needs further investigation, I can only give some initial 
remarks.

> The messenger makes use of polling (using kss timeout) to ask the chat
> service (that stores the messages) whether there are any new messages
> for the currently logged in member.
> 
> The kss:
> 
> div#message-area:timeout {
>     evt-timeout-delay: 2000;
>     action-server: kss_update_message_area;
>     kss_update_message_area-contact: currentFormVar('contact_id');
> }
> 
> When I shutdown the zope server that the messenger is running on, the
> browser continues to poll. This causes the cpu usage of my pc to spike
> every time a timeout fires. 

The question is, what do you expect to happen when the server is shut 
down? At least, this is not considered as normal operation for the core 
plugin components. If this is eventually expected in your application, we 
can suggest several things for you, but it only makes sense to say 
anything if we understand what happens exactly.
 
> By compacting several kss entries into the
> one you see above and then calling only one script, 

This is good, because there must not be more then one calls at one time, 
the server should give all the responses from a single script.

> I've been able to
> bring these spikes down to about 50% (they were above 90% before) of
> total cpu usage.

100% CPU usage is normal and not a problem in itself. Problem is if there 
is large CPU usage where there should not be any. So we will look at this.

> Does anyone else have any advice of  suggestions on how to further
> reduce the cpu load on the client side?

I believe that anything more can be suggested depending on what we find, 
not before.
 
> AFAIK the trunk has been merged with comment stripped code. Can I use a
> checkout of the trunk as it is currently, for usage in a production
> environment and will it have a significant impact on the cpu issue?

As Godefroid said as well, not likely in this case. But you are 
encouraged to use the trunk and report if you discover issues. It should 
be as stable as before the merge.
 
I will let you know if poi is up and running and kindly ask you to file 
this issue then so that it does not get forgotten.

Thanks for your help in testing and calling our attention to this.

-- 
Balazs Ree