stack on server very very slow: solution for workaround
Andreas Stämpfli
andreasstaempfli at mkz.ch
Wed Oct 5 15:26:18 EDT 2005
Hello Phil
strange workaround to gain back speed on server stored stacks: :-)
There are two ways to gain access to a remote stack:
I) The easy way: (NOT WORKING)
set the stackFiles of this stack to "deutsch1.rev," & ServerVerzeichnis
put "deutsch1.rev" into PlugIn
open stack PlugIn
-> This way the stack on the remote machine can be simply accessed by
calling: stack PlugIn
II) The ugly way: (WORKING FAST)
using the "Open Stack..." menue in the Revolution dev environment.
Why? I think this is a bug. I would expect the same result for both
possibilitys ( I. and II.).
(I am not sure if this could cure your problem also).
Kind regards
Andreas Stämpfli
Am 05.10.2005 um 20:06 schrieb andreas:
> Hello Phil
>
> thanks for your hint. In this case, the save command works speedy.
> Only stackoperations
> 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 this down.
> (Tested my AFS connection with other applications. Those have no
> speed issue).
>
> Kind regards
>
> Andreas Stämpfli
>
> 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"
>>> statement.
>>>
>>> I have a solution on a client computer and the stack is (now) on
>>> a server.
>>> 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).
>>
>> http://support.runrev.com/bugdatabase/show_bug.cgi?id=81
>>
>> 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 ointment.
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
More information about the use-livecode
mailing list