[revServer] process timeout issue
Jim Ault
jimaultwins at yahoo.com
Fri Aug 6 16:55:05 EDT 2010
Thanks for this confirmation for Rev coding. Very good info for
planning work flows.
My log file limitation is on the system that I do not control, where
the log files don't 'roll forward' unless that other operating system
is rebooted. It runs for 6 months, then reboots. If they switch to a
daily reboot, then I need to relaunch and test sockets between my
programs every morning at 5 AM, seven days a week... ouch!
Jim Ault
Las Vegas
On Aug 6, 2010, at 10:49 AM, Richard Gaskin wrote:
> Jim Ault wrote:
>> Most log file logic is to add new transactions to the end of an
>> existing file, thus 2 Mb requires more time than 100K. Some servers
>> start new log files every calendar day, but others may have a much
>> lower frequency.
>
> Limiting unnecessary frequency is useful for many reasons, but with
> regard to logs I was just running some experiments last night using
> "open file <filename> for append" and it seems that with the append
> option the time to write is independent of the original file size;
> it seems to operate like the seek command in that regard.
>
> In my tests I was running 10,000 iterations, in which each one
> created a string 1k long and wrote it to the file after the file had
> been opened for append. Along the way, every 1000 times through the
> loop it gets the elapsed time since the last 1000 was done, with
> these results:
>
> 385
> 383
> 383
> 384
> 384
> 385
> 386
> 382
> 803
> 383
>
> The second-to-last item spiking is probably just some background
> process; the rest are consistent enough that I've gotten very
> confident about using append for logging.
>
> In fact, I repeated the same test a few times, so each time the data
> file is growing by 10 MBs, and each time the results are roughly the
> same.
>
> For example, the results above were done when the file was only
> about 30 MBs - here are the results when the file is well over 120
> MBs:
>
> 387
> 383
> 383
> 383
> 382
> 383
> 654
> 383
> 383
> 382
>
> --
> Richard Gaskin
More information about the use-livecode
mailing list