ISTech Support Forum
http://www.istechforum.com/YaBB.pl Evo-ERP and DBA Classic >> Evo Menu & Evo-ERP >> Local storage of programs? http://www.istechforum.com/YaBB.pl?num=1176343539 Message started by kkmfg on 04/11/07 at 19:05:39 |
Title: Local storage of programs? Post by kkmfg on 04/11/07 at 19:05:39 I was trying out EvoERP tonight through a VPN connection. It works but very slowly. It got me to thinking that it might be nice if the .RUN and .RWN files were stored locally on each machine so that they don't need to be transferred over the connection each time they are run. It turns out that TAS7 can do such a thing. The only real catch seems to be that there must be a way to keep the local versions in sync with the server. That's easy enough using checksum calculations on the run files. But, is there anything I'm missing? If not would anyone else be interested in such a thing? I think it could really help over slower links (like VPN.) It might even be cool if rsync was used to keep the run files in sync between all of the machines. As a side question: Who else has tried using VPN to connect to EvoERP? What are your experiences with it? |
Title: Re: Local storage of programs? Post by kevind on 04/12/07 at 07:08:44 rsync almost seems like swat'n flies with a Buick for this application. A very simple makefile and a minimal make utility like GNU Make could check for newer files and copy them to the Client. Does rsync run as a daemon? |
Title: Re: Local storage of programs? Post by JNAPIER on 04/12/07 at 08:20:56 We run 4 shared desktops (Netmeeting) across a VPN (NetGear to NetGear Routers). DBA is obviously faster than EVO. EVO loads .RWN or .RUN files about as fast as the programs function in general. Key strokes take forever to see on screen. It works for our needs but I am sure it can be vastly improved upon...... John |
Title: Re: Local storage of programs? Post by kkmfg on 04/12/07 at 09:28:53 kevind wrote:
Well it IS overkill but I like rsync! :) Yes, make would probably work. It would still probably have to be cygwin make or something because I'm not aware of another GNU compatible free make utility for windows. |
Title: Re: Local storage of programs? Post by kkmfg on 04/12/07 at 09:35:25 JNAPIER wrote:
I'm using a linksys router with OpenWRT (running openvpn) and then computers on the other end, also running openvpn. Obviously, I'm an open source and linux geek. It takes a while to load up programs but once in it's not so bad typing wise. It's a little slow but usually only when in fields that auto search like when looking up a part number with F2. I'm trying to cut down on load times because they are one of the problems. Database access seems pretty slow as well. Really database access shouldn't be as bad as it seems to be. I think I can safely assume that the archaic btrieve interface is partly to blame. It issues way more function calls and takes way more round trips then an SQL connection would. Not that good ol' Tony at Addsum cares in the least bit. |
Title: Re: Local storage of programs? Post by kevind on 04/12/07 at 09:39:10 kkmfg wrote:
You should definately use what you know works! ;) |
Title: Re: Local storage of programs? Post by kkmfg on 04/12/07 at 12:29:51 kevind wrote:
You should definately use what you know works! ;)[/quote] Yeah, rsync would use less bandwidth on the network connection because it only sends the *difference* in each file from the copy you've already got. If the difference is small then the transfer is small. But it's potentially harder to get setup right. Makefiles would be easy as make does all the checking to see if the source file is newer but it will cause the whole changed file to be transferred. On a big EvoERP update that would be a lot of data to transfer. I have no proof but I'd bet that with the TAS compiler small changes in source code probably reliably yield small changes in bytecode. If that's the case then the actual difference between a fixed version and the old version could be very small. |
Title: Re: Local storage of programs? Post by kevind on 04/12/07 at 13:38:16 I noticed that it only shipped across deltas. I am still on Classic and the .RUN files are generally relatively small. I didn't realize till now that the TAS 7 .RWN files are generally so large. I can see where rsync would be a better choice. Depending on how rsync calculates it's deltas, a small change compiled into a RWN might very well result in most of the file getting transfered anyway. |
Title: Re: Local storage of programs? Post by Dave Miller on 04/12/07 at 14:19:41 I use EVO remotely through a VPN and it in nearly as fast as sitting in the office. |
Title: Re: Local storage of programs? Post by tdlugosh on 04/12/07 at 17:06:10 Posted by: Dave Miller Posted on: Today at 2:19pm I use EVO remotely through a VPN and it in nearly as fast as sitting in the office. What did you do to make it so fast? Since I no longer work at the office I use VPN to access DBA. Thankfully, since I no longer work at the office, I don't have to access DBA very much. If I did I would not be a happy camper because it's so sloooooow. Could you share your VPN setup? Tom Dlugosh |
Title: Re: Local storage of programs? Post by kkmfg on 04/13/07 at 04:29:22 kevind wrote:
Yeah, I have seen some stupid things that rsync does. It does sometimes seem to transfer an aweful lot to sync a small change. I haven't dug into how the rsync algo works though so I can only go by anecdotes and feelings. |
Title: Re: Local storage of programs? Post by kkmfg on 04/13/07 at 04:40:19 Yeah, I'd like to know too because it runs nowhere near full speed for me. Of course, our business is connected through one dedicated T-1 line so the max bandwidth is in the 190K/s range. (1.53mb/s) A T-1 line is significantly slower than 100BTX and the route time is significantly longer, on the order of 40-60MS as opposed to .5MS while in the office. If you think about it, 50ms round trips means that the two ends can exchange 20 packets a second (if communication is proceeding serially. Which, with TCP/IP it probably would for the most part). At some points there will be prolonged transfer in one direction but with TCP/IP you get a lot of overhead. I'm running the VPN through UDP to attempt to minimize the packet overhead but it's still slow. So I have to wonder, what sort of connection would you have to have at work and at home to be able to communicate at nearly full speed? Do you use encryption (i'd hope so!)? Do you use compression? It would be nice if someone could provide tips for speeding things up so that nobody has to go to the trouble of hacking extra stuff together (like rsync'ing the program files over to local or doing more drastic things.) If we can get some tips, tricks, and hints together I'll start a wiki page about VPN and Evo. For that matter, please, anyone who uses VPN with evo, please post your setup for me so that I can compile a list of hardware, software, etc. Thanks! tdlugosh wrote:
|
Title: Re: Local storage of programs? Post by Kelloggs on 04/13/07 at 06:46:34 We use Terminal Server. It works well, it is fast, and not very expensive. Why VPN? :-? Kelloggs |
Title: Re: Local storage of programs? Post by kkmfg on 04/13/07 at 09:15:17 Kelloggs wrote:
Because microsoft and citrix suck. ;) Seriously, VPN should work too. It allows one to basically be part of the office lan even when they are abroad. And... It appears Win2K3 server with a 5 pack of terminal server licenses is $1800. I don't consider that cheap. VPN was totally free for me (and I do consider that cheap). BIG difference. |
Title: Re: Local storage of programs? Post by kevind on 04/13/07 at 09:39:44 VPN and Terminal Services are two completely different animals. VPN: Server (with data) ------ Network ------- Client PC (execute programs) Programs execute on client PC (all applications must pass through the network) Data that programs request must pass through the network. (Remember that last GL-E you ran on all accounts for 1 day? Every record in that GL transaction file was read. ) Total data passing over the network is a huge amount not to mention the VPN overhead. Terminal Services: Server (with data and executes programs) -------- Network ------- Client PC (renders GDI) Programs execute on the Server. Only GDI (graphical device interface) API commands pass through the network and get rendered by all the horsepower of the client PC. All data gets requested and used internal to the server. No business data passes through the network. Total data passing over the network is limited to the GDI API. In terms of bytes per second, there is a significant difference. |
Title: Re: Local storage of programs? Post by kkmfg on 04/13/07 at 09:55:12 Yes, that's true. VPN is like actually being in the office but over a slower link. Terminal server is like running the program on your machine in the office and viewing it via video camera and remote mouse. You never run the program you just get the results. But it's a LOT more money in general and I don't think it's really the way to go. My preference would be for a true client/server architecture with a SQL backend. This would be sort of a hybrid approach. Let the server churn on the SQL queries itself and return the results. Let your local machine actually run the program and view the results. So, Evo could still work well if the thing was designed for it. SQL tends to take more time to parse but tends to also deal with less data. I guarantee that GL-E could be implemented in such a way that it need not send every record to the client. The DB server could easily sum up the data for previous records all by itself. Or, running balances on a day to day basis could be stored. Each would need 365 entries for each year. The entry would be a float probably so 4 bytes. Thats 1460 bytes per GL account per year. That's nothing. Things like that really speed the program up. I suppose I just live in fantasy land. It's great here, I'll say hi to the mermaids for all of you... kevind wrote:
|
Title: Re: Local storage of programs? Post by shadowcaster on 07/05/07 at 10:59:03 I use goto my PC works great forDBA and most other programs I even use autodesk inventor remotely not perfect but still it works great JW |
ISTech Support Forum » Powered by YaBB 2.1! YaBB © 2000-2005. All Rights Reserved. |