Fw: application slowing down

[Rich Mooney]

Dar, many thanks for your detailed response.  I've addressed your various
points below.

> On Tuesday, August 20, 2002, at 11:19 AM, Rich Mooney wrote:
>
> > I'm desperate and throwing myself on the mercy of this mail list.
> > I have an
> >> irate customer who wants this problem solved quickly.  I have used
> > MetaCard
> >> to create software which we use to monitor and control our distributed
> >> lighting control systems.  It does these things very well.  I
> >> currently
> > have
> >> a job which requires that I poll the status of all my controls
> >> every 30
> >> seconds.  I do this so I can catch any changes of state and a close
> >> approximation of the time at which that change occurred.  I also
> >> use this
> >> function to catch any errors in operation.  The problem is that
> >> the time
> > it
> >> takes to poll all the controls becomes increasingly longer the
> >> longer I
> > run
> >> the software.  Initially it will take 33 seconds to poll all of my
> > controls
> >> if the polling interval is set to 30 seconds.  After three hours
> >> it will
> >> take 43 seconds.  By the next day it will take 2 minutes.

> Is your network TCP/IP?  Besides the processor usage you can
> monitor network usage and this may give a clue.  A packet sniffer
> might also.

No. My commands are going out a serial port to a device we make which
converts from serial to our protocol which is similar to Appletalk.  I do
have the capability to send my commands through TCP/IP to a module which
converts from TCP/IP to our protocol and I've considered trying this onsite
to try to work around the problem.

> Is each poll run by a batch of "send in <time>"?  If it takes 33
> seconds and a poll is started every 30 seconds, does that mean
> there is an overlap?  That can cause a few problems.

There is just one send in time command keeping the software cycling (I
realize that I forgot about this when I responded to Jaqueline).  It isn't
invoked until after the polling cycle has completed so it polls then waits
30 seconds then polls again etc..

> Second, unless you carry all of your poll state in args of the
> handler spec'd in send (or other wise provide for this problem),
> you might have one send cycle messing up data from the next.

I'm doing this to handle timers on these controls (if a light is manually
turned on, I use the send in time command to automatically turn it back off
after a user configured amount of time) but, this functionality is currently
turned off and I still have the problem.  I'm not doing this with the send
in time command I'm using to poll every 30 seconds.  I'll look into this.

> For example, you might query several controls at once.
> In the long term, you might want to put polling on leaf nodes only
> and distribute these over the system.  They can communicate with
> concentrators and central control in better ways than polling.

This isn't possible with our system.

> Polling has killed many large system designs.

Hopefully not this time.  Thanks for the input.


Rich Mooney
Payne Sparkman Mfg.
shop at paynesparkman.com