[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