Cancelado el alta de nuevas cuentas / New accounts cancelled

ASP sabiendo php es muy sencillo, igual no para programarlo pero si como para pillar la idea de como funciona y si es posible usar algún método.

El renderizado... no se a más rapido que se devuelvan las páginas pienso yo que más rapido se liberarán conexiones, aunque no se consiguiera aumentar el caudal, creo que se aumentaría la velocidad de respuesta...

[www.learnasp.com]
[www.learnasp.com]
[www.somacon.com]
[www.somacon.com]

Ya te digo que todas ellas son para php, pero creo que hay métodos que pueden hacer que corra un poco más...

------------------------------
--- Yuck!

aqui el de sistemas, dando ideas de las suyas.

Visto que Round Robin DNS no es viable en la calidad de hosting, podríamos hacerlo a nivel de puerto, con dos juegos de instancias apache en puertos diferentes (81 y 82, pro ejemplo), balanceados mediante un software de reparto de carga en el puerto 80, como pen (http://directory.fsf.org/pen.html) o balance (http://www.inlab.de/balance.html).

Nunca lo he probado en entornos de alto estres, si de HA, quizás merezca la pena el intento...

... si los del hosting se dejan, claro

solo faltaría verificar que el mysql no se vuelve loco con dos instancias de apache dandole guerra a la vez, o si los bloqueos de la ddbb son efectivos y se mantiene la consistencia de los datos. En principio, no debería afectar a las partidas / gamelogs puesto que solo un jugador puede actuar sobre una partida a la vez (si se bloquea la ddbb registro de partida a registro de partida Y si los mensajes no interfieren), pero depende de como codifique el código la atomicidad de las operaciones.

my 0,02$

Hombre, al estar en la misma máquina es el mismo driver de la base de datos el que se encarga de gestionar los accesos, por lo que dos instancias de apache dandole leña no debería de afectar a los bloqueos, otra cosa es que tengas problemas de sobrecarga de la CPU por casi duplicar los accesos a base de datos, pero si el problema es de conexiones, sería otra opción.

------------------------------
--- Yuck!

¿Es un concurso?

He asumido que cuando hablábamos de tener dos instancias de apache completamente autónomas nos referíamos a un apache escuchando en 2 puertos distrintos, pues es la única manera que se me ocurre (también se puede tener una en apache1.3 y otra en apache2, pero es algo guarrillo)
(de hecho están corriendo los 2 apaches ahora mismo, cosas de la reciente actualización del sistema)

Achiles(X)

la idea original de yuck! eran en el msimo puerto, pero con dos IPs, la idea es misma IP (127.0.0.1 o la propia del hosting, la que dejen), y dos puertos (y misma versión), dejando el 80 para el LB. si el problema es de número de recursos, posiblemente vaya asociado al # de threads paralelas que el proceso puede gestionar "comodamente" (sin hacer swapping a disco y sin comerse la memoria o agotar los descriptores), el SW pensado para LB debería manejar estar diseñado precisamente para optimizar estos parámetros.

A ver, el problema no es solo de hebras de apache. La CPU tiene que atender a todas esas hebras (si no, simplemente subía el valor a 500 y listo). Cierto es que con 2 instancias distintas, ya sean ip's distintas, puertos o incluso apaches distintos, parte de esos procesos y de esa memoria se sharearán, pero no se si lo suficiente como para desahogar la CPU (es dificil de medir, antes era mysql el mayor comsumidor de recursos, pero ahora creo que apache+php le ganan)
En teoría eso se hace con mod_proxy, o uno de sus sucedaneos, no?
(siempre que consiga el dominio total de los httpd.conf)
Hay que tener en cuenta que hay otras webs hospedándose en el servidor (aunque su tráfico tienda a 0)

Achiles(X)

> Que recargue no consume tanto ya que el css ya está cacheado, el javascript ya está cacheado y las imágenes ya están cacheadas.

Aunque esté cacheado, eso lo único que reduce es el ancho de banda consumido. El navegador sigue enviado las peticiones al apache para comprobar que la fecha sigue siendo la misma y que no tiene que descargarlo.

Es decir, en una página con 10.000 imágenes, 10.000 CSSs y 10.000 ficheros JS, el navegador seguiría haciendo 30.000 peticiones al servidor, aunque luego no se descargara ninguno de esos ficheros porque ya los tiene cacheados.

Y eso es precisamente lo que te ahorras haciendo RS o Ajax, que sólo se realiza la petición de la función javascript y su respuesta.

Y ahora una pregunta: ¿qué diferencia hay entre ver como da vueltas la ruedecita del Firefox y ver como da vueltas una ruedecita puesta en medio de una página?

----
Loise: No pasa nada Superman. No es culpa tuya. El sistema funciona así, no puedes hacerte cargo de los problemas de todos.
Superman: Podría hacerme cargo de los problemas de todos si gobernara este país. Y a decir verdad, no hay ninguna buena razón por la que no debiera hacerlo.
Superman Red Son

Ese acceso a apache para ver si se la tiene que bajar solo dura un instante y luego libera la conexión. Lo que hace que la conexión tarde no es esa visita, ni las cosas ya cacheadas, sino el php+mysql (multiplicados por el número de jugadores conectados a las 12 de la mañana, más los graciosos que tienen un autorefresh en your_games.php cada 5 minutos). Y de eso no lo va a salvar tu ajax.
De verdad has usado aplicaciones remotas con carga de php+mysql con ajax? yo lo hago en el trabajo y me tiro de los pelos (y bien hechas, no como las hago yo )

Achiles(X)

Yo si las he hecho (.NET 2.0 y 3.0 es básicamente ajax) y estoy contigo Achiles, van muy bien para webs con paginados, que cargan fragmentos de tablas, pero para mostrar a 1000 personas las 80 partidas pendientes cada 30 segundos va a ser que no, sin contar que el mayor tráfico de todos debe de ser game.php que debe de ser un script del carajo y que consumirá maquina a cientos y además debe bloquear tablas para hacer inserciones a saco...

------------------------------
--- Yuck!

Sí. your_games.php y game.php son las que se llevan la palma.
En otro proyecto que realizo (que está algo parado) si estoy utilizando mas rs (de forma moderada), pero por que el juego está más distribuido. Aquí el proceso de juego está mucho más centralizado.
Quizá en su momento debí separar las fases o algo simiilar (aunque ni hoy en día me parece una buena idea), pero como el modelo de juego lo cogí del otro sitio, pues no me lo planteé.
Pero no es tan malo cuando soporta habitualmente 6000 partidas simultaneas (6695 en este momento) en una máquina cutre (a día de hoy).

Achiles(X)

Para nada es malo, es pesado o trabajoso, pero de malo no tiene nada, funciona de perlas!

Si la maquina es muy cutre ¿No se puede cambiar de modalidad a una un poco más potente por una diferencia módica?

------------------------------
--- Yuck!

Pero no es módica. Voy a buscar los precios (creo que los precios se mantienen, pero las máquinas se devaluan... no es justo...)

Achiles(X)

Como he leísdo por ahí, no sería interesante reducir el tiempo para que aparezcan los robots? Algunas partidas son eternas, y eso también pesa lo suyo.

Buen intento, pero no. Eso no influye para nada en la carga del sistema.
(las partidas paradas son un descanso para la pobre máquina...)

Achiles(X)

Quizá maronna se refiera a que dado que el número de partidas abiertas debería estar relacionado con las partidas en juego habitualmente. Por lo que si el robot entra antes cada jugador debería necesitar menos partidas abiertas. El coste de una búsqueda es como poco logarítmico, pero me pareció entenderte que algunas rutinas como "Siguiente partida" tienen coste lineal con el número de partidas abiertas. Por ende, me imagino que reduciendo el tiempo de partida se reduce el número de partidas abiertas por jugador, lo cual -me imagino- reducirá la carga de la CPU.

Sobre que el número de partidas abiertas por jugador se reduzca por la mayor rapidez de las partidas tengo mis dudas pero parece razonable si se supone que un jugador busca un determinado "número ideal" de movimientos al día.

Por otro lado el número de partidas con robot activo no debería ser importante ¿verdad? Y en cualquier caso sólo sería una solución provisional.

Bueno, para quitarte el máximo trabajo y facilitar el análisis intentaré modelizar el coste de la CPU.
Nuj: Número de usuarios jugando (en ese momento).
Nur: Número de usuarios refrescando (en ese momento).
nR: tanto por uno de jugadas tras las que interviene robot.
tR: 'coste de tiempo de CPU' medio adicional el jugadas de Robot.
npj: número medio de partidas jugadas por jugador.
tp(,): función 'coste de tiempo de CPU' medio para atender la jugada de un usuario. Dependiente de npj y de Nuj+Nur (numero total de usuarios conectados en ese momento).
tr(,): función 'coste de tiempo de CPU' medio para atender un usuario que está refrescando.
tcpu: 'coste de tiempo de CPU' en el momento en cuestión. (Limite superior del coste si se prefiere)

Así el coste en tiempo de la CPU será algo parecido a:
tcpu = (nR*tR+1)*tp(npj,Nuj+Nur)*Nuj + tr(npj,Nuj+Nur)*Nur

si nR*tR << 1 (razonable porque nR debe ser muy pequeño)
tcpu = tp(npj,Nuj+Nur)*Nuj + tr(npj,Nuj+Nur)*Nur

O_o

------------------------------------------------------------------------------------------------------------------------
"Tú lo que quieres es que yo haga el hipopótamo"
"Yo tengo un tallarín, un tallarín..."

Tiene coste algo más de lineal, pero para valores pequeños Ç(decenas)es casi lineal.
Pensé en limitar el número de partidas simultaneas a 50, pero no estoy seguro que redujese mucho el número de partidas (no todo el mundo tiene 100) y no falta el que se hace otra cuenta para poder jugar más.
(hay un mundo ahí fuera, creedme)
(hay drogas peores que esta, podeis desengancharos...)

(o le metes valores a esa pavorosa ecuación, o me quedo igual...)

Achiles(X)

Tio monta una página de parchis y a tomar por saco el ciudadelas!!

Si total lo que mola es la comunidad y destruirle cosas a catán, también me lo puedo comer y arreando.

Muni, tio, te vas a empachar...

------------------------------
--- Yuck!