Originariamente inviato da IfElseIf
Il tempo della select (int $tv_sec , int $tv_usec) varia da 1 a 30 secondi in base a cosa si aspetta il server.
di solito conviene piuttosto mettere i millisecondi (usec) su 10 e i secondi su zero.

questo perché tenere bloccato il processo inutilmente non conviene ... ovviamente se usi un sistema basato su un singolo processo e ti serve nel contempo effettuare altre operazioni

se invece utilizzi il fork per gestire singolarmente le socket e poi utilizzi una socket unix/shared memory/pipe per comunicare con il processo principale non ha molta importanza la durata del bloccaggio del select perché tanto se gli arriva roba dalla socket usata per comunicare scatta il select e prosegue

i miei quesiti sono questi:
Quanto è affidabile php? E le funzioni per la gestione dei socket quanto sono affidabili?
Quanti utenti riesce a mantenere un server come questo,
tenendo conto che invia a tutti gli utenti loggati una media di 20 bytes ogni 5 secondi e riceve da tutti gli utenti un media 10 bytes ogni 10 secondi?
Quanti utenti riesce a tenere non avendo problemi di banda?
Per quanto tempo mi resta bloccata l'applicazione nel momento in cui il server deve inviare a 1000 utenti 10 bytes, avendo il server una velocità di upload di 100 Kbytes/s e tralasciando quella in download dei client?
Facendo 2 calcoli abbiamo 9.766 kbytes da inviare, quindi l'applicazioni dovrebbe impiegare un decimo di secondo + il tempo per l'istruzione send + il tempo per il ciclo!
Quanto tempo ci vuole per l'esecuzione del send?
E la domanda più importante......quanto mi conviene riscrivere il server in C# utilizzando l'invio e la ricenzione di dati in modo asincrono?
.
.
.
Peccato che php non supporta la programmazione multi-thread...
Beh, in realtà PHP ha un estensione nel pecl per utilizzare i thread, anche se forse è stata un pò messa da parte, perché il suo core è thread safe a differenza di alcune estensioni (estensioni che ad es su IIS fanno impazzire tutto)

detto questo, php è affidabile fin quando non raggiungi il limite di memoria prefissato per l'esecuzione, a meno di disabilitarlo, ed è affidabile sempre ricordandosi che NON E' codice macchina eseguito ma un bytecode interpretato a differenza di C# che è un bytecode compilato in codice macchina (tramite JIT, o AOT)

Se sei in grado di scriverlo in C#, bene, allora ti consiglio C# (ci programmo pure io) tanto mono su linux funziona perfettamente per queste cose

detto questo ... perché scrivere un server? XML-RPC o WSDL/SOAP e php come backend su apache e ti risolvi il problema

è vero che il sistema è stateless ma ti basta controllare dopo quanto ricevi le informazioni usando le sessioni (su database non quelle di php, se cerchi sul forum c'è tutto e di più) e ti risolvi subito il problema

è molto meno complesso di scrivere un server (fatto bene intendo) e nel contempo è anche più flessibile e manutentibile!

esiste un assembly per C# per interfacciarsi con XML-RPC che è estremamente comodo e per php esistono svariate classi per gestire server xml-rpc che sono estremamente facili da usare