Как улучшить Производительность FtpWebRequest?

KeepAlive работает. FtpWebRequest кеширует соединения внутри, чтобы их можно было повторно использовать через некоторое время. Для получения подробной информации и объяснения этого механизма вы можете обратиться к ServicePoint .

Другой хороший источник информации - поискать в источнике FtpWebRequest (вы можете сделать это на VS2008).

Лично я перевел все наши приложения с использования FTP для загрузки / скачивания файлов и вместо этого развернул решение на основе веб-служб XML в ASP.NET.

Производительность значительно улучшена, безопасность настолько велика или минимальна, насколько вы хотите кодировать (и вы можете использовать вещи, встроенные в .NET), и все это может проходить через SSL без проблем.

Наши показатели успеха по установлению соединений наших клиентов через их собственные брандмауэры НАМНОГО лучше, чем использование FTP.

Вам обязательно стоит попробовать BITS , что является большим улучшением по сравнению с FTP. Пароли в открытом виде - не единственная слабость FTP. Также существует проблема прогнозирования порта, который он откроет для пассивной загрузки или скачивания, и просто общая сложность, когда клиенты используют NAT или брандмауэры.

BITS работает через HTTP / HTTPS с использованием расширений IIS и поддерживает отправку и загрузку в очереди, которые могут быть запланировано с низким приоритетом. В целом он намного более гибкий, чем FTP, если вы используете Windows на клиенте и сервере.

БИТЫ для PowerShell

БИТЫ для .NET

Неважно, если для соединения отдельных подключений требуется много времени, если вы можете запускать несколько параллельно. Если вам нужно передать много элементов (скажем, сотни), то имеет смысл запускать десятки и даже сотни WebRequest параллельно, используя асинхронные методы, такие как BeginGetRequestStream и BeginGetResponse . Я работал над проектами, которые сталкивались с аналогичными проблемами (длительное время подключения / аутентификации), но из-за параллельного выполнения множества вызовов общая пропускная способность на самом деле была очень хорошей.

Также огромная разница, если вы используете методы async или синхронный, как только у вас будет много (десятки, сотни) запросов. Это относится не только к вашим методам WebRequests, но и к вашим методам Stream read / write , которые вы ' Буду использовать после получения потока загрузки / скачивания. Книга «Улучшение производительности и масштабируемости .Net» немного устарела, но большая часть ее советов все еще актуальна и их можно бесплатно прочитать в Интернете.

Следует учитывать, что ServicePointManager ] сидит там, скрываясь во Framwork с единственной целью: испортить вашу производительность. Убедитесь, что вы получили ServicePoint своего URL-адреса и изменили ConnectionLimit на разумное значение (по крайней мере, такое же, как количество одновременных запросов, которое вы намереваетесь).

Следует учитывать, что класс ServicePointManager скрывается во Framwork с единственной целью: испортить вашу производительность. Убедитесь, что вы получили ServicePoint своего URL-адреса и изменили ConnectionLimit на разумное значение (по крайней мере, такое же, как количество одновременных запросов, которое вы намереваетесь).

Следует учитывать, что класс ServicePointManager скрывается во Framwork с единственной целью: испортить вашу производительность. Убедитесь, что вы получили ServicePoint своего URL-адреса и изменили ConnectionLimit на разумное значение (по крайней мере, такое же, как количество одновременных запросов, которое вы намереваетесь).

У меня хорошие результаты с ftp-библиотекой EDT:

http://www.enterprisedt.com/products/edtftpnet/overview.html

AFAIK, каждый запрос FtpWebRequest должен устанавливать новое соединение, включая вход на сервер. Если вы хотите ускорить передачу по FTP, я бы порекомендовал вам использовать альтернативный FTP-клиент. Некоторые из этих альтернативных клиентов могут входить в систему, а затем выполнять несколько действий, используя одно и то же командное соединение.

Примеры таких клиентов включают: http://www.codeproject.com/KB/IP/FtpClient.aspx который также включает хорошее объяснение того, почему эти библиотеки могут работать быстрее, чем стандартный FtpWebRequest и http://www.codeproject.com/KB/macros/ftp_class_library.aspx , который также выглядит достаточно простой реализацией .

Лично я откатил свою собственную реализацию FTP обратно в .NET 1.1 за несколько дней до появления FtpWebRequest, и это все еще хорошо работает для .NET 2.0 и более поздних версий.

Эта книга мне тоже далась нелегко. Мы использовали его в университете, в котором я учился, и мне часто приходилось обращаться к другим источникам, чтобы получить более простые объяснения, когда я находил CLRS немного не по себе. Как только я получил объяснение из Википедии прямо в моей голове и заработал образец кода (которого часто не хватает CLRS), я обнаружил, что могу вернуться к тексту и разобраться в нем.

Не беспокойтесь о том, что делать. все упражнения. Даже суперэлитным студентам MIT необязательно делать все. Делай то, что можешь, и двигайся дальше. Если вам понадобится концепция в следующей главе, которую вы не заметили, вы все равно сможете вернуться к ней.

MIT OpenCourseWare также сделал доступными старые лекции для Введение в алгоритмы (SMA 5503) .

Проверка API

Медленный сеанс FTP в командной строке сообщит вам, что проблема не связана с используемым вами FTP API. Это не исключает API как потенциальную проблему, но, безусловно, снижает ее вероятность.

Сетевые ошибки

Если пакеты отбрасываются между источником и местом назначения, ping сообщит вам об этом. Возможно, вам придется увеличить размер пакета до 1500 байт, чтобы увидеть какие-либо ошибки.

Сервер очереди FTP

Если у вас нет контроля над конечным FTP-сервером, попросите промежуточный сервер получать загруженные файлы. Затем посредник отправляет файлы на удаленный сервер с любой возможной скоростью. Это создает иллюзию того, что файлы отправляются быстро. Однако, если файлы должны существовать на удаленном сервере сразу после их загрузки, это решение может оказаться нежизнеспособным.

Программное обеспечение FTP-сервера

Используйте другой FTP-демон на FTP-сервере, например ProFTPd в качестве службы Windows . (ProFTPd имеет плагины для различных баз данных, которые позволяют аутентификацию с использованием SQL-запросов.)

Операционная система FTP-сервера

Операционная система на основе Unix может быть лучшим вариантом, чем операционная система на базе Microsoft.

FTP-клиент Программное обеспечение

Существует несколько различных API для отправки и получения файлов через FTP. Может потребоваться некоторая работа, чтобы сделать ваше приложение достаточно модульным, чтобы вы могли просто подключить новую службу передачи файлов. Здесь приведены ответы на несколько различных API.

Альтернативный протокол

Если FTP не является абсолютным требованием, попробуйте:

• сетевой диск Windows
• HTTPS
• scp, rsync, или аналогичные программы (может потребоваться Cygwin )

Я бы рекомендовал перейти на rsync .
Плюсы:
Оптимизирован для сокращения времени передачи.
Поддерживает SSH для безопасной передачи
Использует TCP, что делает ваш ИТ-отдел / брандмауэр более счастливым

Минусы:
Нет встроенной поддержки .NET
Ориентирован на установку серверов Linux - хотя есть приличные порты Windows, такие как DeltaCopy

В целом, хотя это намного лучший выбор, чем FTP

Посмотрите на эту страницу - http://www.ietf.org/rfc/rfc959.txt

В нем говорится об использовании другого порта при подключении, чтобы иметь возможность повторно использовать подключение.
Это работает?

Я настоятельно рекомендую Компонент Starksoft FTP / FTPS для .NET и Mono . У него есть объект подключения, который можно кэшировать и использовать повторно.

Я провел несколько экспериментов (загрузил около 20 файлов разного размера) на FtpWebRequest со следующими факторами

KeepAlive = true/false

ftpRequest.KeepAlive = isKeepAlive;

Имя группы подключения = UserDefined или null

ftpRequest.ConnectionGroupName = "MyGroupName";

Лимит подключений = 2 (по умолчанию) или 4 или 8

ftpRequest.ServicePoint.ConnectionLimit = ConnectionLimit;

Режим = Synchronous или Async

см.этот пример

Мои результаты:

1. Use ConnectionGroupName,KeepAlive=true взял (21188. 62 мсек)

2. Использование ConnectionGroupName,KeepAlive=false заняло (53449. 00 мсек)

3. No ConnectionGroupName,KeepAlive=false took (40335.17 мсек)

4. Use ConnectionGroupName,KeepAlive=true;async=true,connections=2 took (11576.84 мсек)

5. Use ConnectionGroupName,KeepAlive=true;async=true,connections=4 took (10572. 56 мсек)

6. Use ConnectionGroupName,KeepAlive=true;async=true,connections=8 took (10598.76 msec)

Conclusions

1. FtpWebRequest был разработан для поддержки внутреннего пула соединений. Чтобы убедиться, что пул соединений используется, мы должны убедиться, что ConnectionGroupName установлен.

2. Установка соединения требует больших затрат. Если мы подключаемся к одному и тому же ftp-серверу, используя одни и те же учетные данные, установка флага keep alive в true сведет к минимуму количество устанавливаемых соединений.

3. Асинхронный способ рекомендуется, если у вас много файлов для ftp.

4. По умолчанию количество соединений равно 2. В моей среде ограничение количества соединений до 4 дает наибольший прирост производительности. Увеличение количества соединений может как улучшить, так и не улучшить производительность. Я бы рекомендовал установить ограничение на количество соединений в качестве параметра конфигурации, чтобы вы могли настроить этот параметр в своей среде.

Надеюсь, вы найдете это полезным.