I am from iAnywhere's salesforce and post a customer
question. Hope it is in good hands here...
The customer (OEM-partner) has some performance problems
with FTP under DBRemote and asks if we can recommend a
From: Thomas Waniek
Subject: FTP-Server for DBRemote
X-Mailer: WebNews to Mail Gateway v1.1t
Date: 20 Aug 2007 08:11:08 -0700
X-Trace: forums-1-dub 1187622668 10.22.241.41 (20 Aug 2007 08:11:08 -0700)
X-Original-Trace: 20 Aug 2007 08:11:08 -0700, 10.22.241.41
Xref: forums-1-dub ianywhere.public.general:6220
Article PK: 4662
Subject: Re: FTP-Server for DBRemote
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
Date: 21 Aug 2007 11:42:48 -0700
X-Trace: forums-1-dub 1187721768 10.25.98.247 (21 Aug 2007 11:42:48 -0700)
X-Original-Trace: 21 Aug 2007 11:42:48 -0700, nicelson-d620.sybase.com
Xref: forums-1-dub ianywhere.public.general:6221
Article PK: 2631
We don't certify any FTP servers. Most just work AFAIK.
If it helps, one option to increase performance (that a few
customers have used) is to place the FTP server on the
same LAN as the Consolidated SQL Anywhere server and
change the remote addresses to point to the file server
instead of going through the FTP server.
That suggestion speeds up the accesses for the consolidated
message agent [especially on writing]. The remotes still
access those via the FTP protocol but the consolidated
message agent can forego that overhead. This requires
some administration but can be a real savings for the
heaviest user of the ftp server for which the ftp server
performance is often the bottleneck.
Of course going straight to a purely file-base message
transport is probably your fastest option whenever that
Using larger message sizes (-l) can sometimes help. So
can grouping more smaller transactions together (-g).
These two can help reduce the number of messages and
thus reduce the directory and put overhead. So too can
increasing the message agents working memory
(-m) which may also need to be adjusted when increasing
the -l settings. But one needs to test how much of an
impact these will have in the particular case.
Another performance tip may be to split the phases and run
separately and continuously. This is especially helpful when
the inbound volume is high and prevents dbremote from from
falling too far behind. It also reduces the amount of I/O doing
regular log scanning if running -s -b (ie. send and stop) and
can reduce the number of small messages sent due to starting up.