Quanto bene un'app C ++ che comunica tramite Apache gestisce il traffico?

4

Sto scrivendo un gioco online che deve essere eseguito in un browser web e sono preoccupato che la mia architettura lato server sia in grado di gestire il carico.

Sto progettando per 1000-2000 client simultanei. Ogni client dovrà interrogare il server una volta ogni 2 secondi, quindi 500-1000 transazioni al secondo sono il mio obiettivo di progettazione.

Il mio server di gioco comunica con Apache tramite FastCGI. Per il momento sto eseguendo Apache su Windows. Tutto ciò funzionerà su un server dedicato "dual-core". L'applicazione del server di gioco è scritta in C ++ e le transazioni sono abbastanza semplici e hanno una larghezza di banda piuttosto bassa (forse 2k dati per) quindi non sono troppo preoccupato per il pezzo del server di gioco.

Il mio cliente è scritto in Javascript e utilizza XMLHTTP per comunicare con il server.

Quindi fumo qualcosa per pensare che posso ottenere da 500 a 1000 transazioni al secondo? Se sì, quale numero potrei aspettarmi?

    
posta Joe Rice 21.10.2011 - 03:01
fonte

1 risposta

2

Ho visto benchmark utilizzando ab per PHP eseguito a circa 500 richieste al secondo e 1200 volte al secondo per Python. Nota, tuttavia, che queste sono richieste di base che non fanno nulla di veramente spettacolare.

Quindi, il tuo collo di bottiglia sarà il tuo codice server: è sicuramente possibile raggiungere 1k richieste al secondo usando Apache / FastCGI / C ++, tutto dipende dall'hardware del tuo server e dalla complessità del tuo codice server (e dal lato server I / O, ecc.)

Da una nota a margine, c'è una ragione per cui stai usando questo particolare stack tecnologico? C ++ di solito non è un linguaggio molto carino per scrivere il codice del server in (al contrario di Java, ecc.). Potrei anche guardare una lingua come Erlang per il codice lato server per aggirare il requisito FastCGI per dare al tuo server ancora più spinta.

In risposta ai commenti dell'OP (un po 'troppo lungo per un commento):

@Joe Rice: TBH, troverei perfettamente accettabile che gli utenti di giochi siano obbligati a utilizzare i browser più aggiornati: non si possono usare vecchi client di gioco basati su PC nella maggior parte degli ambienti e si può sicuramente t nel mondo della console, quindi perché i giochi basati su browser dovrebbero essere diversi? Potresti iscriverti a un altro mondo di feriti, soprattutto considerando i tuoi limiti di budget.

Se le tue preoccupazioni riguardano il budget, perché non dare un'occhiata a node.js come server tech con le librerie socket.io sia lato client che server? Ci sono alcuni bonus qui:

  • Nessun cambio di contesto (bene, limitato). Lo stesso linguaggio usato sia dal lato client che dal lato server, quindi non è necessario cambiare continuamente mentalità.
  • Gestito in modo elegante per la degredation: socket.io ha una serie di meccanismi di fallback incorporati per gestire il supporto sulla maggior parte dei browser.
  • node.js supporta TCP e (AFAIK) UDP, quindi non devi preoccuparti del sovraccarico di HTTP (anche se ovviamente dovresti affrontare tu stesso i problemi di sincronizzazione di UDP se scegliessi di percorrere quella strada)
  • Dato che hai familiarità con C ++, se trovi un collo di bottiglia sul lato server, puoi tuffarti nel codice della biblioteca e aggiornarlo come richiesto.

Naturalmente, ci sono anche potenziali aspetti negativi. Non ho familiarità con i server di gioco ad alto utilizzo scritti interamente usando node.js. Puoi anche controllare hacknews per flame.js per ulteriori potenziali trucchi con l'uso del nodo.

    
risposta data 26.10.2011 - 00:11
fonte

Leggi altre domande sui tag