Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Slow performance
Message
De
08/04/2014 17:31:41
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Client/serveur
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows 7
Network:
Windows 2003 Server
Database:
MySQL
Application:
Desktop
Divers
Thread ID:
01598250
Message ID:
01598321
Vues:
58
This message has been marked as a message which has helped to the initial question of the thread.
>>>We have a client/server application that uses a MySQL database on the server. Some of the clients now connect to the network using an internet dongle, and we saw a real problem with performance on those machines, although the network speed is OK. We figured out that this network has a very slow ping, the traceroute shows it goes first to another island, then to the US, and then back to Aruba and it takes around 700ms to ping.
>>>
>>>What is the best way to improve performance of a client/server application in this situation? My thought so far was to try to create asynchronous transactions, but this is a lot of work and sometimes not possible.
>>
>>700ms ping is pretty bad. If you believe in fixing the problem rather than symptoms then that needs to be dealt with. If both clients and the server are on Aruba, find some way to keep the traffic on your island. You could get creative e.g. set up a VPN server which could be accessed from any public WiFi hotspot on the island. Balance the cost of what it might take to re-architect your app vs. putting in a $100 WiFi router.
>>
>>Another possibility would be to set up a local Terminal Server and have the dongle users connect to that. There would then be no performance issue between the TS and your backend server. But I imagine running RDP or some other remote protocol with 700ms ping times would be pretty brutal.
>>
>>I'm not sure in the general case you can solve that problem with changes to your app. Yes, async is one way to go but you end up with old-style mainframe batch processing, where you don't know the results until some time later. That may not be practical if you can't proceed with Transaction 2 until you know Transaction 1 completed or rolled back.
>>
>>Having a crappy Internet connection is their problem, not yours. You're pretty limited in what you can do to alleviate the symptoms. They (or you if you choose to take on that responsibility) need to fix the problem.
>
>Thanks for your info. I agree with your last sentence, I wonder if a web application would perform better in this situation or are the service calls likewise affected by slow pings as is the case with SQLEXEC() calls? The client somehow thinks if we would have a web client instead of an "old fashioned" client/server it would perform just fine.

A web client would be the same idea as a terminal server, as long as the web server was also local to the DB server backend. The web interface would be laggy with those ping times but there would be no performance issue between the web server and backend.

>I could make a change to the software to batch process at least part of the transactions that did not need an immediate call back, and those transactions I put into one statement (using the Options keyword in the MySQL connection to allow multiple queries). I created a separate executable that only processes these transactions and when the user clicks on save the program runs the executable and the user can continue working right away. Not an optimal solution but at least they are happy for now.
Regards. Al

"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov

Neither a despot, nor a doormat, be

Every app wants to be a database app when it grows up
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform