stack on server very very slow: solution for workaround

[andreas]

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
>
>