FTPS desempenho com pequenos arquivos XML, mas com volume muito alto

Question

Nossa empresa está criando uma integração b2b com outra parte que exige que eles entreguem para nós um grande número de ~ 100.000 arquivos XML com cerca de 10-15 KB cada um ao longo de uma janela de três horas todos os dias. Planejamos usar nosso servidor FTPS (TLS / SSL) altamente disponível e executado no Linux, para essa troca.

A outra parte levantou algumas preocupações sobre as despesas gerais de leitura / gravação do FTPS, afirmando que é provável que a transferência se estenda além da janela permitida. Nossos especialistas em infra-estrutura me asseguram que não há nenhum problema com esse número de arquivos sobre FTPS, especialmente em um servidor HA Linux, desde que excluamos após a coleta de arquivos.

Eu quero substanciar a abordagem acima. Alguém implementou uma transferência de alto volume sobre FTPS? Esta é uma má ideia e devemos implementar uma abordagem baseada em filas?

Será muito tarde para descobrir problemas durante nosso teste de carga. Desculpas se a pergunta for um pouco aberta. Talvez, se você precisar de detalhes específicos, eu possa fornecer isso. Muito obrigado

    

Answer 1

Resposta curta: Se os servidores estiverem próximos, você poderá fazê-lo. Se estiverem muito longe, você provavelmente explodirá sua janela de transferência. De qualquer forma, no entanto, é uma má ideia para a implementação "simples".

A resposta mais completa:

Eu não acho que este site seja apropriado para o tipo de pergunta - a resposta correta será "depende" e "você deve executar seus próprios testes". (Também talvez o Serverfault seja um fórum melhor, já que este fórum é mais para hobbiests).

Dito isso, questiono o FTPS como uma boa solução, pois parece ter uma sobrecarga muito alta - o FTP já é ruim o suficiente antes de adicionar a sobrecarga de criptografia adicional.

Quanto a saber se isso é tecnicamente factível dependerá significativamente da velocidade do seu pipe, da distância entre os servidores e do número de conexões simultâneas que você faz [várias conexões podem atenuar a alta latência até certo ponto]

Se você puder mesclar vários arquivos em um arquivo maior, transferi-los e, em seguida, descompactá-los, obterá ganhos de desempenho substanciais muito grandes porque:

1. Você reduz os problemas com a latência (e os custos computacionais de criptografia, mas permite ignorá-los, pois eles não são substantivos em relação ao restante do problema)
2. Você compacta os arquivos reduzindo a quantidade de dados que precisam ser transferidos.

Você não especificou como as transferências funcionariam - seria uma única sessão FTPS com vários arquivos sendo carregados ou uma sessão de ftps separados para cada arquivo.

A última solução - que seria mais fácil de programar suspeito - incorreria em uma grande sobrecarga, já que todas as conexões precisariam ser negociadas, e essa negociação é cara em relação a um pequeno arquivo. (Não sou especialista em FTPS, mas o TLS normalmente adiciona cerca de 6 a 7k de overhead a cada solicitação e FTPS é uma sessão FTP envolvida em um TLS ine).

A latência por solicitação, supondo que a carga útil fosse insignificante, aumentaria em cerca de 3 vezes. Isso pode não ser importante se os sites estiverem na mesma rede, mas se, por exemplo, você tiver um lado da conexão em Nova York e o outro em LA 80ms, você está olhando para problemas substanciais de latência ao multiplicá-lo pelo número de arquivos, e você provavelmente vai explodir sua janela de transferência - mesmo que o NAS possa lidar com isso.

    

Answer 2

Vou oferecer uma resposta aqui que quantifica o problema que você provavelmente enfrentará. Eu também votei na resposta davidgo porque ela descreve corretamente o problema.

Considere que 100.000 transferências ao longo de três horas equivale a uma média de aproximadamente 10 transferências por segundo . Isso é 100 milissegundos por transferência.

A latência de servidor para servidor teria que ser uma ordem de grandeza menor do que, digamos, 10 ms, para que houvesse alguma esperança de acompanhar a taxa de transferência.

Se os servidores estiverem conectados via WAN, você pode considerar isso quase impossível. A menos que você vá com várias conexões simultâneas, mas, em seguida, se as transações em si forem consecutivas, isso efetivamente negará quaisquer ofertas de simultaneidade de ganhos potenciais.