Сравнение HTTP и FTP для передачи файлов
Очевидно, что в Entity Framework CORE нет способа запустить миграцию. Еще несколько месяцев назад у опции публикации в Visual Studio был флажок «выполнить миграцию», но теперь этого нет.
Вы можете попытаться запустить
dotnet ef database update
или какой-либо подобный скрипт на сервере, но это вернуло слишком много ошибок, чтобы упомянуть. Поэтому вместо этого я попытался сгенерировать сценарии SQL, которые выполняются в соответствии с
dotnet ef migrations script
с различными переключателями и т. Д., Но это приводило к различным ошибкам. В конце концов я нашел это.
Script-Migration -from 20190306131332_migration1 -o fileName.sql
, который успешно генерирует SQL для запуска вручную с базой данных.
-from
- последний запуск миграции, поэтому, если я хочу получить все изменения, так как миграция1 (т.е. миграция2, миграция3 и т. Д.) - это миграция -from, критерии
. Это создаст файл. называется filename.sql в корневом каталоге, где находится файл .sln.
3 ответа
Вот сравнение производительности двух. HTTP является более быстро реагирующим для ответа запроса маленьких файлов, но FTP может быть лучше для больших файлов, если настроено правильно. FTP раньше обычно считался быстрее. FTP требует, чтобы канал управления и состояние сохранялись помимо состояния TCP, но HTTP не делает. Существует 6 передач пакетов, прежде чем данные начнут передавать в FTP, но только 4 в HTTP.
Я думаю, что правильно настроенный уровень TCP имел бы больше эффекта на скорость, чем различие между протоколами прикладного уровня. Понимание Проекта Sun, Настраивающее TCP, имеет детали.
Вот другое хорошее сравнение отдельных характеристик каждого протокола.
Много брандмауэров отбрасывают исходящие соединения, которые не являются к портам 80 или 443 (http и https); некоторые даже отбрасывают соединения с теми портами, которые не являются HTTP (S). FTP может или не может быть позволен, для не разговора о active/PASV режимах.
Кроме того, HTTP/1.1 допускает намного лучшие частичные запросы ("только отправляют от байта 123456 в конец файла"), условные запросы и кэширующийся ("только отправляют если содержание измененный/если last-modified-date, измененный"), и сжатие содержания (gzip).
HTTP намного легче использовать через прокси.
От моей неподтвержденной информации HTTP легче сделать работу с, отбрасывать/замедляться/облуплены соединения; например, это не нужно к (ре), устанавливают сессию входа в систему перед (ре) передача инициирования.
OTOH, HTTP является не сохраняющим состояние, таким образом, необходимо было бы сделать аутентификацию и создание следа, "кто сделал что когда" сами.
Единственная разница в скорости, которую я заметил, передает много маленьких файлов: HTTP с конвейерной обработкой быстрее (уменьшает распространения в прямом и обратном направлениях, особенно примечательные в сетях высокой задержки).
Обратите внимание, что HTTP/2 предлагает еще больше оптимизации, тогда как протокол FTP не видел обновлений в течение многих десятилетий (и даже расширения FTP имеют незначительное внедрение пользователями). Так, если Вы не передаете файлы через машину времени, HTTP, кажется, победил.
(Мимоходом: существуют протоколы, которые лучше подходят для передачи файлов, такой как rsync или БитТоррент, но у этого нет такого же количества доли завоеванного внимания, тогда как HTTP является Everywhere™),
Одно соображение состоит в том, что FTP может использовать нестандартные порты, которые могут сделать получение, хотя трудные брандмауэры (особенно, если Вы используете SSL). HTTP обычно находится на известном порте, таким образом, это редко - проблема.
Если Вы действительно решаете использовать FTP, удостоверьтесь, что Вы читаете об Активном и Пассивном FTP.
С точки зрения производительности в конце дня они оба извергают файлы, которыми непосредственно вниз соединения TCP так должны быть о том же.