Que tipo de servidor eu preciso para lidar com 10 milhões de solicitações e consultas mySQL por dia? [fechadas]

Sou iniciante em administração de servidores e estou procurando um serviço de hospedagem poderoso para hospedar meu novo site. Este site é basicamente um back-end de um jogo on-line para celular e:

• processa até 10 milhões de solicitações HTTPS e consultas mySQL por dia
• armazene arquivos de até 2000 GB no disco rígido
• transferir provavelmente 5000 GB de dados dentro e fora por mês
• roda em PHP e mySQL
• possui 10 milhões de registros no banco de dados mySQL, para cada registro existem 5 a 10 campos, cerca de 100 bytes cada

Realmente não sei que tipo de servidor preciso para lidar com esses requisitos, minha pergunta é:

1. De que CPU / RAM eu preciso para um servidor dedicado ou VPS?
2. Quais empresas de hospedagem são capazes de oferecer esse tipo de servidor dedicado ou VPS?
3. E a computação em nuvem? Eu pesquisei o Amazon EC2, mas me parece complicado. E entrei em contato com a Rackspace, mas estranhamente eles disseram que o Cloudsites não é adequado para meus requisitos. Gostaria de saber se existe outra empresa de hospedagem em nuvem.
4. Algum outro método alternativo?

Um desktop barato?

Vamos entrar na matemática.

• 10 milhões de pedidos.
• Isso divide em 416667 solicitações por hora.
• Isso divide em 6944 solicitações por minuto.
• Isso divide em 116 solicitações por segundo.

O dobro disso (pico de carga) e falamos de uma carga que um desktop quad core barato pode suportar SE as consultas forem simples o suficiente e você não disser realmente o quão complexas elas são.

• 5000 GB por mês é trivial - sério, a mesma matemática se aplica.
• Que divide em 208 GB / dia
• Isso divide em 8 GB / hora
• Isso divide em 148 MB / minuto

• Isso divide em 2,5 MB / segundo, 25Mbit. O dobro do pico - 50Mbit, trivial para qualquer centro de hospedagem. Vai custar-lhe, no entanto.

• Armazene 2000 GB no disco rígido. Ou seja, discos rígidos de 2x2000 GB em um RAID? A menos que: seja para o banco de dados, tenha muitas E / S complexas, existe algo entre algumas dezenas de discos e MUITOS discos SAS de 73GB a 15.000 RPM em um RAID 10 (cerca de 60 discos) para obter a E / S necessária - isso A pergunta não é respondida sem muito mais informações sobre padrões de acesso a dados.

• Executa PHP e MySQL - Meu celular pode fazer isso;) A questão é quão complexa é a aplicação. O MySQL PODE ou NÃO PODER ser uma solução aceitável aqui, BTW l. - isso exigiria mais testes. Há uma razão pela qual algumas pessoas ainda usam outros bancos de dados comerciais maiores.

• De que CPU / Ram eu preciso para um Servidor Dedicado ou VPS?

Pode-se dizer que isso depende da lógica (quantos cálculos na parte do PHP, inteligência ou falta de programadores e muitas outras perguntas.

Sério, essa é uma configuração não trivial. Peça a alguns especialistas que analisem o assunto.

Basicamente, você precisa descer e fazer sua lição de casa. Muitas perguntas não são respondidas neste formulário. Especialmente porque você parece não se importar com seus dados ...

• Backups?
• Nenhum plano de contingência? Quero dizer, os servidores morrem - então você está bem com o site inativo por dias enquanto a substituição está configurada?

Para adicionar um pouco da minha experiência que pode ser útil:

• Como a TomTom mencionou, é difícil / impossível fornecer especificações exatas, pois muitas delas dependem do design e da implementação do seu aplicativo. O hardware que solicita a mim ou a outra pessoa X / s pode não funcionar bem para você.
• Eu tenho um servidor MySQL dedicado de baixo custo (Intel Core2 Duo E4600 de 2,40 GHz, 4 GB de RAM) que atende a uma média de 100 solicitações / s (quase 10 milhões / dia) com uma taxa de ociosidade da CPU de 90%. Além de alguns ajustes básicos na configuração, ela está funcionando bem devido à leitura pesada (+ 95% de leituras) e o conjunto de registros ativos é facilmente contido na memória. Considere o tamanho do seu conjunto ativo ao escolher a quantidade de RAM do servidor, pois isso pode fazer uma grande diferença. Certifique-se de entender a diferença entre o tamanho do banco de dados e o tamanho do conjunto de registros ativos. Por exemplo, meus bancos de dados totalizam ~ 7 GB, mas o conjunto ativo provavelmente tem apenas alguns 100 MB.
• Da mesma forma, eu tenho um servidor Apache de especificações semelhantes que atende a ~ 1 milhão de solicitações por dia, com uma taxa média de ociosidade da CPU de ~ 95%. Os pedidos são uma combinação de consultas AJAX de dados de mapa muito simples e páginas mais complexas do MediaWiki.
• Fazer um benchmarking de seu aplicativo específico é um bom começo para tentar determinar exatamente o que você precisa. Você não deseja subestimar, mas superestimar pode ser tão ruim devido ao potencial desperdício de dinheiro e esforço.
• Considere não apenas a taxa média de solicitações, mas também a taxa de pico. Você não deseja um servidor que mal consiga lidar com a taxa média, pois as taxas de solicitação podem variar significativamente ao longo do dia, semana e mês. Por exemplo, posso obter 3-4x o tráfego durante o horário de pico nos fins de semana, como faço nas horas mínimas durante a semana. A variação varia dependendo do aplicativo e da base de usuários.
• Você pode armazenar em cache qualquer uma das suas solicitações de banco de dados / HTTP? Isso pode aumentar drasticamente sua taxa de solicitações com hardware mais barato / menos dependendo de quanto você pode armazenar em cache.
• Considere suas opções de dimensionamento para crescimento futuro agora e não mais tarde. Uma boa opção pode ser usar o dimensionamento horizontal, o que permitirá que você comece com o mínimo de hardware e aumente facilmente conforme necessário.
• O design adequado da camada de aplicação pode ter um efeito enorme no desempenho final. Uma consulta SQL incorreta em uma tabela sem índices pode ter ordens de magnitude mais lentas do que uma projetada corretamente. Da mesma forma, servidores Apache / MySQL mal configurados podem ser muitas vezes mais lentos do que quando configurados corretamente.