|
Home > Archive > SQL Anywhere Mobile > June 2005 > MobiLink load testing
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
MobiLink load testing
|
|
|
| We are using MobiLink 7.0.0.313 synching to an Oracle 8.0 consolidated (I
know..I know)
We want to hammer our ML server with 6 remote clients, syncing every 10
seconds and monitoring the performance of the consolidated updates.
Those 6 'remote' servers are not actually remote but are part of our HQ
infrastructure and reside on the same physical network as our consolidated
database. In a real world production environment those 6 servers would be
spread across the country and dial up to synchronize via a 56K modem.
Unfortunately we don't have the production environment in place so we're
using 6 remote servers on our physical network.
My question is this: Will it make a huge difference in our load testing if
we don't use a dial-up modem? We were planning on simply using the backbone
to sync over but we fear this may give us a skewed view of our performance.
Should we use modems to better simulate the real world? Will it make a
discernable difference?
| |
| Breck Carter [TeamSybase] 2005-06-09, 8:24 pm |
| *Please* upgrade to 7.0.something.later at the very least.
IMO a highspeed link will stress the Oracle and MobiLink servers more
than dialup because they won't be loafing while the data is
transferred. A commit is performed between the upload and download
stages so Oracle locks won't be held any longer one way or t'other.
FWIW V9 has VERY MANY improvements over 7.original.release, in
MobiLink performance and every other area.
Breck
On 9 Jun 2005 11:54:50 -0700, "Doug" < doogie414removethis@
yahoo.com>
wrote:
>We are using MobiLink 7.0.0.313 synching to an Oracle 8.0 consolidated (I
>know..I know)
>
>We want to hammer our ML server with 6 remote clients, syncing every 10
>seconds and monitoring the performance of the consolidated updates.
>
>Those 6 'remote' servers are not actually remote but are part of our HQ
>infrastructure and reside on the same physical network as our consolidated
>database. In a real world production environment those 6 servers would be
>spread across the country and dial up to synchronize via a 56K modem.
>Unfortunately we don't have the production environment in place so we're
>using 6 remote servers on our physical network.
>
>My question is this: Will it make a huge difference in our load testing if
>we don't use a dial-up modem? We were planning on simply using the backbone
>to sync over but we fear this may give us a skewed view of our performance.
>Should we use modems to better simulate the real world? Will it make a
>discernable difference?
>
>
>
--
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/A...7/risingroad-20
bcarter@risingroad.com
RisingRoad SQL Anywhere and MobiLink Professional Services
www.risingroad.com
| |
| Graham Hurst 2005-06-10, 8:24 pm |
| Have you (Doug) read the MobiLink Performance whitepaper? It's here:
http://www.ianywhere.com/whitepaper...nce
.html
Those tests used version 7.0.1. After that whitepaper we did more tests
which simulated slow remotes (1000) using slow dialup connections. We
were able to get close to the throughput observed with fast remotes when
we had a large number of worker threads (-w) but put a limit on the
number which could simultaneously apply uploads (via the -wu switch,
which was added in version 7.0.2 as a result of that testing).
For example, we got the best throughput for fast clients with -w 5. For
slow clients we got the best throughput with -w 200 -wu 5.
I strongly recommend upgrading. A newer version 7 will give you the -wu
option (essential with slow connections to remotes IMHO) and version 8
lets you use statement-based uploads (which typically more than double
the upload performance) as well as the ability to disable download
acknowledgments (which speeds up syncs with slow remotes, since a
consolidated connection can be freed earlier for another sync).
Cheers,
Graham
|
|
|
|
|