Conselhos sobre hardware para o servidor de processamento de imagem bitmap / openGL?

Question

Estou tentando desenvolver uma versão para um servidor de processamento para manipular o processamento de bitmap, bem como a renderização openGL para imagens com codificação de croma e automação do Photoshop. Minhas pesquisas aqui e no Google mostraram surpreendentemente poucos resultados e, como não há tags para bitmap ou processamento de imagens, considero que esse é um aplicativo especializado.

O processamento de bitmap é muito intensivo em CPU, enquanto o recurso de chroma-keying e Photoshop é intensivo em gpu. Duvido que este seja um caso de otimização excessiva, pois a nossa empresa agrupa milhares de imagens por dia (atualmente em estações de trabalho individuais) e qualquer economia no tempo de processamento e no tempo de inatividade da estação de trabalho seria benéfica.

Alguém tem alguma experiência com esse tipo de servidor de processamento? Alguma consideração especial que entraria em uma compilação como essa ou estou pensando demais?

Para processamento de bitmap, estamos usando classes C # System.Drawing.Imaging e System.Drawing.Drawing2D , que são bibliotecas GDI +. Estamos executando este multi-threaded usando System.Threading . Para a chroma-keying, usamos o Primatte, que é o openGL, mas não estou familiarizado com as outras bibliotecas que ele usa.

    

Answer 1

Eu administrei um cluster de servidores um pouco semelhante (cluster de dois membros) há pouco tempo, e minha abordagem básica era ~ CPU bottleneck... max out processor speed and core count . Ele também estava em servidores high-end com muita RAM, SSDs de alta capacidade (para acessar rapidamente as imagens que eram armazenadas temporariamente durante o processamento) e várias NICs de 1 Gbit, novamente para maximizar o desempenho e, portanto, a taxa de processamento de imagens.

Trabalhou muito bem e com uma alta carga de trabalho para o que era uma função crítica para os negócios, os MBAs e outros ternos estavam felizes em investir um extra de $ 25.000 em hardware para fazer as coisas funcionarem sem problemas. Uma vez eu alimentei os benefícios da minha recomendação para eles, pelo menos. E sim, acho que você está pensando demais nisso, pelo menos um pouco. Comece por "apenas" lançar hardware potente no problema. Se isso não fornecer o desempenho necessário, você precisará se preocupar com a otimização do código e o exame do fluxo do processo para gargalos.

Antes de entrar no meu processo básico para criar e "vender" minha recomendação, deixe-me apontar um adágio SA:

It's better to over-engineer than under-engineer.

• (neste caso particular, é melhor errar do lado de "muito" de um servidor do que o lado de "muito pouco").

Eu diria que sua situação parece muito semelhante à mínima e aconselharia uma abordagem semelhante. E eu acho que nenhum dos abaixo é estritamente "Administração de Sistemas", então você provavelmente pode parar de ler aqui, mas está tudo muito relacionado, e se você não pode vender suas recomendações efetivamente para as unidades de negócios, administração de sistemas e arquitetura é um inferno ... se você puder, você pode se chamar de engenheiro de sistemas / arquiteto e exigir mais dinheiro para essencialmente o mesmo trabalho, porque você tem a habilidade de colocar suas idéias em números simples para as "crianças lentas". (Executivos e MBAs.)

Meu processo:

1. Faça benchmarks básicos e use projeções simples para obter uma estimativa básica de qual desempenho será necessário.
   
   • Cria uma estimativa e me ajuda a selecionar qual hardware (em um sentido geral) obter, e eu irei criar 3 especificações.
     • No mínimo, acho que funcionará (o que é realmente o mínimo + ~ 15% para me dar uma margem de buffer / segurança se meus números estiverem um pouco fora)
     • Um máximo razoável / configuração "melhor" possível
     • Um valor médio, que é algo entre os dois.
   • Com base nas prioridades do negócio (Economizando dinheiro? Saída máxima / desempenho nesse sistema? Algum compromisso?), farei uma recomendação minha, e as outras duas opções incluídas que devem funcionar, se minha recomendação não for aceita por qualquer motivo.
2. Eu vou dividir o custo de cada solução e fazer uma análise de custo / benefício rudimentar, quantitativa sempre que possível. Nesse caso, do meu passado, era um processo de negócios gerador de receita, então era uma questão simples de ~ we made $[x] from this last year, on [y] images processed, for a profit of $[z]/image processed, or $[i]/day. Em seguida, converti o custo do hardware em unidades semelhantes - $[x] total CapEx, or $[z]/image processed or $[i]/day . (E quando existe uma "projeção" futura diferente, faça o mesmo com os futuros números "projetados").
3. E uma vez que você tenha feito os custos, é para computar ou quebrar os benefícios. Usar essas cifras do dólar e comparações de custo para informar sua decisão (e defender sua recomendação final) é realmente útil e, na minha experiência, geralmente justifica gastar mais em hardware potencialmente subutilizado.
   • no caso que eu estou aludindo, o custo de recomendação "%" extra$25,000 sobre a sugestão inicial de ~ buy a single mid-range server and slap our image processing stuff on that quebrou para cerca de $70 a day e <10 cents an image processed ... e fizemos < strong> muito mais de 10 cents em cada imagem processada.
4. E para ter certeza absoluta de que os ternos receberam minha recomendação redundante de cluster (que seria muito mais fácil para mim suportar e administrar), explodi os custos de não ter recursos de computação suficientes no servidor - perda potencial de receita por falta de capacidade, custos por hora de fazê-lo "manualmente" nas estações de trabalho ( several hundred dollars an hour ) e adicionados os benefícios qualitativos ( supportability , ease of management , etc.) e custos ( reputation damage , angry clients , etc) como a cereja no topo. E, em seguida, ressaltou, mais uma vez, que minha solução recomendada custa apenas $70 a day .

De qualquer forma, isso é muito mais longo e menos técnico do que eu estava antecipando ... mas espero que seja útil.