stack on server very very slow
andreas at medone.ch
Wed Oct 5 13:06:58 CDT 2005
thanks for your hint. In this case, the save command works speedy.
take very long. There is a lot of text-processing going on, on many
fields on many cards.
What surprises me, is exactly this: Why should this take longer than
with the local stack?
Both, local, as remote, stack should be processed in memory. As the
RunRev manual states.
-> But: if a stack is sucked in clients memory on opening - then
there should not be a speed
issue for me. So there is some sort of communication to the remote
stack. I can see it
on my network gauge!
Client and server are both running OS X 10.4.2, so its using AFS,
Apple File Sharing.
Yes, it seems, that there is some sort of failure, hope we can track
(Tested my AFS connection with other applications. Those have no
Am 05.10.2005 um 16:58 schrieb Phil Jimmieson:
>> In several posts one can read, that a stack, when networked, can
>> be slow, due to the "save"
>> I have a solution on a client computer and the stack is (now) on a
>> Setup is OS X 10.4
>> After porting this stack to the server machine, it behaves very
>> slow (more than 1000! times
>> slower, than when this stack was on the client. There is no save
>> command used.
>> I assume that the whole stack is read in memory? There are less
>> than 1000 cards in it
>> (but they are procecessed a lot).
>> Thanks for your hints! I should port this Tutorial-Game as server
>> solution soon.
> Hi Andreas,
> there is a bugzilla report for slow saving, but its marked as
> Resolved, because Tuviah could not verify the bug, although it
> still exists for me (and now possibly you too).
> In our setup, the server is a Unix system using Samba (not a true
> Windows server). What sort of server are you using?
> Phil Jimmieson phil at csc.liv.ac.uk (UK) 0151 794 3689 (Mobile)
> 07976 983164
> Computer Science Dept., Liverpool University, Chadwick Building,
> Peach Street
> Liverpool L69 7ZF http://www.csc.liv.ac.uk/~phil/
> I used to sit on a special medical board... ...but now I use this
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the use-livecode