Sei que esta é uma pergunta horrível e generalizada, sem uma boa resposta, e peço desculpas antecipadamente, mas me pergunto se alguém poderia tentar uma estimativa muito ampla.
Digamos que você tenha um servidor MySQL dedicado rodando em hardware moderno no valor de cerca de US$ 1 mil.
Digamos que o usuário médio faça 20 solicitações de leitura e 5 solicitações de gravação por minuto – todas consultas simples, sem junções; principalmente na linha de 'selecionar esta linha por UUID' em uma tabela indexada de aproximadamente 10.000.000 de linhas.
Muito, muito, muito, muito aproximadamente quantos usuários simultâneos você esperaria que um servidor como esse manuseasse antes de 'empurrá-lo'.
Responder1
Como você observou, esta é uma estimativa muito ampla.
A grande questão é o que você usa esses $ 1.000 para comprar. Desde que você consiga um pouco mais de memória e menos potência de processador com um disco rígido médio, eu diria que um aplicativo razoavelmente codificado (onde razoável = principalmente usando quaisquer bibliotecas de abstração que sua linguagem fornece) com esses parâmetros deve ser capaz de lidar com cerca de 500 Usuários concorrentes. Eu teria adivinhado mais, exceto pelo tamanho do conjunto de linhas (já que quanto mais linhas cabem diretamente na RAM, menos você precisa fazer no disco, mesmo para gravações imediatas).
O tipo de dados que estão nas linhas e a quantidade de RAM que você pode pagar serão com certeza os maiores fatores nesse cenário. Se você conseguisse sobreviver com menos gravações e diminuir o tamanho da tabela indexada, acho que você conseguiria 1.000 usuários simultaneamente.
Os dois problemas que você verá:
A quantidade de dados que você é capaz de armazenar em cache na RAM e, portanto, a quantidade de RAM que você tem acima do mínimo necessário para executar as operações básicas do sistema operacional e do servidor de banco de dados determinará o que você pode fazer. Mais RAM, menos necessidades de sistema operacional e uma menor quantidade útil de dados que devem ser mantidos na RAM para consultas e gravações significarão a diferença entre desempenho aceitável e muita, e muita sobrecarga.
O design do seu aplicativo é absolutamente crítico aqui. Uma gravação distribuída por 500 a 1.000 usuários tem um impacto enorme, enorme. Da mesma forma, se suas ligações não forem simples e eficientes, você causará um acidente de trem rapidamente. Baseei minha estimativa em vários aplicativos MySQL que vi em funcionamento, com um pouco de conhecimento de como eles funcionam. Se o aplicativo tiver problemas fundamentais, talvez você não chegue a 40 usuários. Se você codificá-lo com eficiência e levar em consideração os limites de hardware, poderá escalar além de 2.000 facilmente.
Responder2
Eu posso responder isso. Acabei de sair daquele passeio, vou pedalar novamente.
$ 650- $ 800 comprarão um AMD quad-core de 8 GB de RAM de velocidade moderada rodando um drive SATA2 de 1 TB. US$ 170 comprarão uma segunda unidade relativamente rápida de 1 TB. Tenha em mente que este é um hardware disponível na maioria dos locais de eletrônicos/lojas de escritório/best-buy. Você pode obter mais retorno em outro lugar, mas nada mal pelo dinheiro. Você pode obter um quad core mais rápido por pouco mais.
Agora, em relação ao aplicativo, presumo que você esteja executando Linux/BSD/unix para o sistema operacional e evitarei o debate ms vs unix. Aqui está o que encontrei:
Não temos problemas em especificar mais de 200 usuários/sessões ativos em qualquer um de nossos aplicativos sem piscar, não importa o quão fraco o aplicativo seja. Na verdade, não conseguimos derrubar/travar/paralisar um aplicativo em nenhum servidor quad-core que executamos há algum tempo... mas aprendemos algumas lições na época de 200 MHz de núcleo único.
Por exemplo, nossa empresa irmã vende vários sistemas de monitoramento de comunicações baseados em MySQL com mais de 1.300 usuários por máquina e, em média, várias centenas de sessões simultâneas por hora. O registro e os relatórios são feitos em tempo real (bem, ocorre algum buffer) e eles estão sendo executados em máquinas dual-core de 3 GHz em unidades PATA lentas [suspiro] ... Na verdade, unidades P-ATA de 133 MHz. O maior atraso na interface do usuário foi de cerca de 2 segundos. Eles trocaram o MSSQL pelo MySQL há uma década e obtiveram resultados imediatamente.
Tenha em mente que essas máquinas estão executando webapps + bancos de dados... então você faz as contas. Simplesmente funciona. Além disso, substituí vários aplicativos Oracle/MS/xxxx por eles e nunca cheguei perto de ficar sem energia. Além disso, deixe-me expandir o que o outro cara disse da perspectiva do dba... Aqui estão 6 dicas das trincheiras.
- As gravações prejudicarão o desempenho, especialmente se a penalidade de bloqueio for um conceito estranho para seus codificadores.
- Fazer tudo em uma mesa enorme vai te matar.
- Normalização excessiva não é sua amiga. Se seus codificadores estiverem na terceira forma normal, seu aplicativo funcionará mal. Os dados desnormalizados ocupam mais espaço, mas possibilitam realizar grandes coisas com consultas simples.
- Uma grande mesa engasgará com gravações frequentes. Veja 1.
- Se você escrever seu aplicativo para usar uma (ou mais) tabelas para exibição de dados e uma tabela diferente para gravações que podem ser sincronizadas com as tabelas de leitura quando o carregamento do sistema permitir, você poderá fazer todo tipo de coisa. Usamos um pequeno número de tabelas para armazenar gravações em buffer e somos capazes de lidar com um número incrível de transações porque ninguém é pisado.
- Use índices. De qualquer forma, se você souber quais partes das consultas são usadas como chaves.
- Ajuste a instalação do banco de dados com base na memória. Veja a documentação do MySQL on-line. Na verdade, se você tiver menos de 1.000 sessões ativas, muitas vezes você pode simplesmente aumentar o número de conexões e seguir em frente. http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html
Você pode ver o SQL estúpido em ação observando a maioria dos wordpress/etc. plug-ins. A maioria é escrita por pessoas que não entendem sql, e eles colocarão um servidor de joelhos rapidamente com apenas um punhado de usuários.
Responder3
Servidor de US$ 884, 8 GB de RAM, dual quadcore xeon, unidade SATA de 300 GB e 7200 rpm, 40% inativo, 5% iowait
Uptime: 780727 Threads: 276 Questions: 1884267879 Slow queries: 3964303 Opens: 60474
Flush tables: 1 Open tables: 440 Queries per second avg: 2413.478
enquanto serve 220mb/seg