Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Re: Remote Connection - Very Slow Speed

3 posts in General Discussion Last posting was on 2003-08-08 05:33:47.0Z
Nick Elson Posted on 2003-08-07 15:20:37.0Z
From: "Nick Elson" <no_spam_nicelson@sybase.com>
Newsgroups: ianywhere.public.general
Subject: Re: Remote Connection - Very Slow Speed
Lines: 127
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
NNTP-Posting-Host: nicelson-xp.sybase.com
X-Original-NNTP-Posting-Host: nicelson-xp.sybase.com
Message-ID: <3f326e45$1@forums-1-dub>
Date: 7 Aug 2003 08:20:37 -0700
X-Trace: forums-1-dub 1060269637 172.31.143.50 (7 Aug 2003 08:20:37 -0700)
X-Original-Trace: 7 Aug 2003 08:20:37 -0700, nicelson-xp.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1541
Article PK: 3771

Oh ... all that ... and ...

DSL speeds are always specified as UP TO 384kbps ...

There is no guarantees there .... so speed tests on your line is
probably the first thing you should look at.

"Nick Elson" <no_spam_nicelson@sybase.com> wrote in message news:...
> If your result set rows are only 100 bytes in size each then you are
> seeing about an 82Kbps throughput (or about 25% of your bandwidth).
>
> The short answer is probably going to be ... "It could very well be
normal."
>
> Reasons (possibly many more but these will do for starters):
>
> 384Kbps download speed is **30** times slower than standard LAN
10BaseT
>
> Any firewalls or VPN layers (You are securing this link? Right?) will
> slow this
> down further.
>
> No matter how fast the link, the number of routing points involved
will
> often have a greater impact on throughput (as will the slowest link
> along any
> leg). Just compare a tracert in your DSL situation verses your LAN
> and
> you start getting a measure of this factor. Network speed tests
> outside
> of our software (comparing DSL verses LAN) will tell you more about
> your environment.
>
> Internet bandwidth fluctuations and is shared -- (try it a 3:00 a.m.
> instead
> of 3:00 p.m. and you will see what I mean here)
>
> General I find Client/Server a la Internet is less than satisfactory for
> these and
> many other reasons. If you must, you will be more happy with it if you
> reduce
> the result set sizes to someone much smaller.
>
> Data synchronization is another approach that often make more sense under
> limited bandwidth conditions (such as this question implies). You should
> probably
> see what MobiLink does for you.
>
> Any way to speed this up? LOTS OF WAYS .... maybe. . . .
>
> Cable access in some locales (and extra $$) can sometimes give you
> greater
> (download) bandwidth ... some companies also offer T1 access at a
> reasonable
> rate (US mostly I believe).
>
> Of course you can reduce the volume of the data fetched across the
> network
> by getting fewer rows, fewer columns in the select-list and working
with
> smaller
> rows (design). If Blobs/Clobs are involved then only fetching part of
> the blob
> [or only when the user drills down on the column] is often good
design.
>
> The way you or your development environment uses the API (ODBC, ESQL,
> OLEDB, ....) in question, can play a major role in performance. Check
> out what
> tracing options you have and see if you are taking full advantage of
any
> caching
> and prefetch buffering features (bindings etc) available to you.
>
> Larger network packet sizes tend to play less of a beneficial role
> across the internet
> but you can try that out too
>
> Of course query complexity may also play a role. If the LAN
performance
> is also
> poor then you will want to consider this.
>
> If your LAN (local) performance is poor, then you may need to give the
> server more
> cache to work with. [also always measure the 2nd query since the
> first instance
> will tend to prime-the-cache for you ... the 2nd tune for the same
query
> will tend
> to run a little faster because of this, and can confound your
> performance measurements
> a bit]. And if there is no way to speed this up, then you may need
to
> do some
> redesign to tune up the system.
>
> Lots to consider but it takes more detailed analysis to identify your
> specific
> problems
>
>
>
> "M. Ravari" <majid@lablogics.com> wrote in message
> news:3f3185bd$1@forums-1-dub...
> > Hello All,
> >
> > I'm using iAnywhere 7.0 and created a remote connection to the server
via
> > vpn on dsl (384/128). While running the application (visual c++) on the
> > remote, it takes a huge amount of time (more than a minute) to load a
list
> > of 5000 customers from a table residing on the server. Is this a normal
> > behavior and is there any way of speeding this up?
> >
> > Thank you in advance for all that you can contribute.
> >
> > M. Ravari
> >
> >
>
>


M. Ravari Posted on 2003-08-07 23:45:28.0Z
From: "M. Ravari" <majid@lablogics.com>
Newsgroups: ianywhere.public.general
References: <3f326e45$1@forums-1-dub>
Subject: Re: Remote Connection - Very Slow Speed
Lines: 152
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
NNTP-Posting-Host: adsl-67-127-109-33.dsl.irvnca.pacbell.net
X-Original-NNTP-Posting-Host: adsl-67-127-109-33.dsl.irvnca.pacbell.net
Message-ID: <3f32e498$1@forums-1-dub>
Date: 7 Aug 2003 16:45:28 -0700
X-Trace: forums-1-dub 1060299928 67.127.109.33 (7 Aug 2003 16:45:28 -0700)
X-Original-Trace: 7 Aug 2003 16:45:28 -0700, adsl-67-127-109-33.dsl.irvnca.pacbell.net
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1550
Article PK: 3779

Thank you very much for all the info Nick.That gives me a lot to test and
think about.

Have you had any experience in using Thin Boxes and Terminal Services on
Advanced 2000 Server? Is that maybe a better way of connecting remotely (by
letting the application run on the server)?

Thanks again.

M. Ravari

"Nick Elson" <no_spam_nicelson@sybase.com> wrote in message
news:3f326e45$1@forums-1-dub...
> Oh ... all that ... and ...
>
> DSL speeds are always specified as UP TO 384kbps ...
>
> There is no guarantees there .... so speed tests on your line is
> probably the first thing you should look at.
>
>
>
> "Nick Elson" <no_spam_nicelson@sybase.com> wrote in message news:...
> > If your result set rows are only 100 bytes in size each then you are
> > seeing about an 82Kbps throughput (or about 25% of your bandwidth).
> >
> > The short answer is probably going to be ... "It could very well be
> normal."
> >
> > Reasons (possibly many more but these will do for starters):
> >
> > 384Kbps download speed is **30** times slower than standard LAN
> 10BaseT
> >
> > Any firewalls or VPN layers (You are securing this link? Right?)
will
> > slow this
> > down further.
> >
> > No matter how fast the link, the number of routing points involved
> will
> > often have a greater impact on throughput (as will the slowest link
> > along any
> > leg). Just compare a tracert in your DSL situation verses your
LAN
> > and
> > you start getting a measure of this factor. Network speed tests
> > outside
> > of our software (comparing DSL verses LAN) will tell you more about
> > your environment.
> >
> > Internet bandwidth fluctuations and is shared -- (try it a 3:00 a.m.
> > instead
> > of 3:00 p.m. and you will see what I mean here)
> >
> > General I find Client/Server a la Internet is less than satisfactory for
> > these and
> > many other reasons. If you must, you will be more happy with it if you
> > reduce
> > the result set sizes to someone much smaller.
> >
> > Data synchronization is another approach that often make more sense
under
> > limited bandwidth conditions (such as this question implies). You should
> > probably
> > see what MobiLink does for you.
> >
> > Any way to speed this up? LOTS OF WAYS .... maybe. . . .
> >
> > Cable access in some locales (and extra $$) can sometimes give you
> > greater
> > (download) bandwidth ... some companies also offer T1 access at a
> > reasonable
> > rate (US mostly I believe).
> >
> > Of course you can reduce the volume of the data fetched across the
> > network
> > by getting fewer rows, fewer columns in the select-list and working
> with
> > smaller
> > rows (design). If Blobs/Clobs are involved then only fetching part
of
> > the blob
> > [or only when the user drills down on the column] is often good
> design.
> >
> > The way you or your development environment uses the API (ODBC,
ESQL,
> > OLEDB, ....) in question, can play a major role in performance.
Check
> > out what
> > tracing options you have and see if you are taking full advantage of
> any
> > caching
> > and prefetch buffering features (bindings etc) available to you.
> >
> > Larger network packet sizes tend to play less of a beneficial role
> > across the internet
> > but you can try that out too
> >
> > Of course query complexity may also play a role. If the LAN
> performance
> > is also
> > poor then you will want to consider this.
> >
> > If your LAN (local) performance is poor, then you may need to give
the
> > server more
> > cache to work with. [also always measure the 2nd query since the
> > first instance
> > will tend to prime-the-cache for you ... the 2nd tune for the same
> query
> > will tend
> > to run a little faster because of this, and can confound your
> > performance measurements
> > a bit]. And if there is no way to speed this up, then you may need
> to
> > do some
> > redesign to tune up the system.
> >
> > Lots to consider but it takes more detailed analysis to identify your
> > specific
> > problems
> >
> >
> >
> > "M. Ravari" <majid@lablogics.com> wrote in message
> > news:3f3185bd$1@forums-1-dub...
> > > Hello All,
> > >
> > > I'm using iAnywhere 7.0 and created a remote connection to the server
> via
> > > vpn on dsl (384/128). While running the application (visual c++) on
the
> > > remote, it takes a huge amount of time (more than a minute) to load a
> list
> > > of 5000 customers from a table residing on the server. Is this a
normal
> > > behavior and is there any way of speeding this up?
> > >
> > > Thank you in advance for all that you can contribute.
> > >
> > > M. Ravari
> > >
> > >
> >
> >
>
>


Nick Elson Posted on 2003-08-08 05:33:47.0Z
From: "Nick Elson" <no_spam_nicelson@sybase.com>
Newsgroups: ianywhere.public.general
References: <3f326e45$1@forums-1-dub> <3f32e498$1@forums-1-dub>
Subject: Re: Remote Connection - Very Slow Speed
Lines: 186
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
NNTP-Posting-Host: vpn-dub-109.sybase.com
X-Original-NNTP-Posting-Host: vpn-dub-109.sybase.com
Message-ID: <3f33363b@forums-1-dub>
Date: 7 Aug 2003 22:33:47 -0700
X-Trace: forums-1-dub 1060320827 10.22.120.109 (7 Aug 2003 22:33:47 -0700)
X-Original-Trace: 7 Aug 2003 22:33:47 -0700, vpn-dub-109.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1551
Article PK: 3780

Remote terminal access type of access can sometimes
bridge the difference (for fat applications) but they too
have a performance cost and so that tends to be another
'it depends' technology answer.

Typically it's okay for someone like the developer to
dial in to diagnose a problem, or a system admin to 'see
what is happening' but the normal user is usually served
better by having closer access to that back end system.

That's why I suggest MobiLink. A local database that
is occasionally synchronized (or replicated as in SQL Remote)
with [to] the central system can often be a better performing
answer with little extra overhead.

"M. Ravari" <majid@lablogics.com> wrote in message
news:3f32e498$1@forums-1-dub...
> Thank you very much for all the info Nick.That gives me a lot to test and
> think about.
>
> Have you had any experience in using Thin Boxes and Terminal Services on
> Advanced 2000 Server? Is that maybe a better way of connecting remotely
(by
> letting the application run on the server)?
>
> Thanks again.
>
> M. Ravari
>
>
> "Nick Elson" <no_spam_nicelson@sybase.com> wrote in message
> news:3f326e45$1@forums-1-dub...
> > Oh ... all that ... and ...
> >
> > DSL speeds are always specified as UP TO 384kbps ...
> >
> > There is no guarantees there .... so speed tests on your line is
> > probably the first thing you should look at.
> >
> >
> >
> > "Nick Elson" <no_spam_nicelson@sybase.com> wrote in message news:...
> > > If your result set rows are only 100 bytes in size each then you are
> > > seeing about an 82Kbps throughput (or about 25% of your bandwidth).
> > >
> > > The short answer is probably going to be ... "It could very well be
> > normal."
> > >
> > > Reasons (possibly many more but these will do for starters):
> > >
> > > 384Kbps download speed is **30** times slower than standard LAN
> > 10BaseT
> > >
> > > Any firewalls or VPN layers (You are securing this link? Right?)
> will
> > > slow this
> > > down further.
> > >
> > > No matter how fast the link, the number of routing points involved
> > will
> > > often have a greater impact on throughput (as will the slowest
link
> > > along any
> > > leg). Just compare a tracert in your DSL situation verses your
> LAN
> > > and
> > > you start getting a measure of this factor. Network speed tests
> > > outside
> > > of our software (comparing DSL verses LAN) will tell you more
about
> > > your environment.
> > >
> > > Internet bandwidth fluctuations and is shared -- (try it a 3:00
a.m.
> > > instead
> > > of 3:00 p.m. and you will see what I mean here)
> > >
> > > General I find Client/Server a la Internet is less than satisfactory
for
> > > these and
> > > many other reasons. If you must, you will be more happy with it if
you
> > > reduce
> > > the result set sizes to someone much smaller.
> > >
> > > Data synchronization is another approach that often make more sense
> under
> > > limited bandwidth conditions (such as this question implies). You
should
> > > probably
> > > see what MobiLink does for you.
> > >
> > > Any way to speed this up? LOTS OF WAYS .... maybe. . . .
> > >
> > > Cable access in some locales (and extra $$) can sometimes give you
> > > greater
> > > (download) bandwidth ... some companies also offer T1 access at a
> > > reasonable
> > > rate (US mostly I believe).
> > >
> > > Of course you can reduce the volume of the data fetched across the
> > > network
> > > by getting fewer rows, fewer columns in the select-list and
working
> > with
> > > smaller
> > > rows (design). If Blobs/Clobs are involved then only fetching
part
> of
> > > the blob
> > > [or only when the user drills down on the column] is often good
> > design.
> > >
> > > The way you or your development environment uses the API (ODBC,
> ESQL,
> > > OLEDB, ....) in question, can play a major role in performance.
> Check
> > > out what
> > > tracing options you have and see if you are taking full advantage
of
> > any
> > > caching
> > > and prefetch buffering features (bindings etc) available to you.
> > >
> > > Larger network packet sizes tend to play less of a beneficial role
> > > across the internet
> > > but you can try that out too
> > >
> > > Of course query complexity may also play a role. If the LAN
> > performance
> > > is also
> > > poor then you will want to consider this.
> > >
> > > If your LAN (local) performance is poor, then you may need to give
> the
> > > server more
> > > cache to work with. [also always measure the 2nd query since
the
> > > first instance
> > > will tend to prime-the-cache for you ... the 2nd tune for the same
> > query
> > > will tend
> > > to run a little faster because of this, and can confound your
> > > performance measurements
> > > a bit]. And if there is no way to speed this up, then you may
need
> > to
> > > do some
> > > redesign to tune up the system.
> > >
> > > Lots to consider but it takes more detailed analysis to identify your
> > > specific
> > > problems
> > >
> > >
> > >
> > > "M. Ravari" <majid@lablogics.com> wrote in message
> > > news:3f3185bd$1@forums-1-dub...
> > > > Hello All,
> > > >
> > > > I'm using iAnywhere 7.0 and created a remote connection to the
server
> > via
> > > > vpn on dsl (384/128). While running the application (visual c++) on
> the
> > > > remote, it takes a huge amount of time (more than a minute) to load
a
> > list
> > > > of 5000 customers from a table residing on the server. Is this a
> normal
> > > > behavior and is there any way of speeding this up?
> > > >
> > > > Thank you in advance for all that you can contribute.
> > > >
> > > > M. Ravari
> > > >
> > > >
> > >
> > >
> >
> >
>
>