D
dbeavon
Guest
>> My question is that is it normal to see this much lag in the remote connections YES! Basically every database record you work on must involve coordinated (blocking) effort between the client and the server, often involving two round trips. (The exception is FOR EACH NO-LOCK as I mentioned earlier.) You should definitely investigate your network activity so you are at least able to *quantify* the unicasts involved in your workload. Also google is your friend. There are lots of KB's about this stuff that you might want to read, starting with this one: knowledgebase.progress.com/.../18342 . It answers some of the questions you've been asking here. >> and if yes then please let me know if the application is migrated to use appservers rather remote connections, will it make any difference If the appservers run with "shared memory" connections to the database then that will be fast (like you are used to). Even the new PASOE can use "shared memory" connections to the database. Hope this helps. Remember that most challenges with client/server development can be overcome, but they require some planning and effort. As I mentioned before, Progress knows that they need to do some work to improve client/server development and they have planned changes for OE 12. Client/server database connectivity is never going away. These days (with docker, load-balanced appservers, etc) it is critical that application code can execute in a *separate* tier from the database. The concept of "sharing memory" with a database server is one that has worn out its welcome!
Continue reading...
Continue reading...