Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




eondev

#23088 ¿Pero entonces el problema puede ser causado a raíz de tener 900 conexiones abiertas a mysql aunque sea a otra base de datos? ¿Y por qué 2 servicios que apuntan a una misma base de datos, uno PHP y otro C#, cuando reinicio el de PHP el crítico de C# deja de tener problemas de acceso y timeouts exception?

Es que es raro de narices. La solución rápida que damos ahora mismo hasta descubrir que reiniciando el container del PHP casi siempre se soluciona es reiniciar el servicio MYSQL, y es muy LEL. xDDD

1 respuesta
desu

#23101 algo se queda bloqueado o pendiente de confirmacion o un recurso sin cerrar y se hace deadlock.

el php genera el problema.

el de C# esta mal escrito y se bloquea.

esa es mi primera intuicion.

si quieres saltamos a stream y hacemos pair programming debugando el problema.

1 respuesta
B

.

MTX_Anubis

#23086 En su día me leí el libro de Concurrency on the JVM. No recuerdo si quiera si hablaba de Akka pero bueno, ahí te explica más o menos de que va el tema y por qué es mejor que los otros modelos.

Pero vamos que si le das la JVM, pues pasate por la web de Akka y empieza a practicar, el concepto de modelo de actores es muy sencillo aunque como todo se puede complicar al máximo (clusters de actores distribuidos por varias máquinas)

Yo los he usado como te digo arriba porque necesitábamos mantener el estado de miles de conexiones simultáneas, era todo asíncrono y digamos que el proceso de creación de una conexión era una FSM bien definida. Se conectaba, se autenticaba, recibía unas cuantas configuraciones y el estado real, devolvía que todo estaba Ok y después el ACtor pasaba a un estado de Activo y ya podía enviar y recibir mensajes.

Todos los mensajes iban con su correspondiente Ack y además podía enviar los que quisiera en paralelo sin necesidad de recibir el Ack del anterior. Así que había que guardar el estado de cada mensaje por separado.

Ahí es donde brillaba el modelo de actores:

Se conectaba -> Crea ClientActor con el socket -> Pasaba por distintos estados hasta el Activo
Cliente enviaba mil mensajes
ClientActor creaba por cada Mensaje un RequestActor(clientActor, msg): Este actor se encarga de mantener el estado de esta request, la hacía, esperaba respuesta y si todo va bien devolvía al padre la respuesta
ClientActor mandaba por el socket la respuesta Ack/Nack y mataba al RequestActor correspondiente

Grosso modo era así y se podía hacer que el RequestActor respondiera por el socket directamente

3 1 respuesta
eondev

#23102 hombre, esa es la conclusión que saqué en base a ver como se comportaba todo. Pero claro, manda huevos que en otras instalaciones esto no ocurra y haya empezado a pasar derrepente en esta desde hace unos meses porque sí. Y luego pues eso, habrá que meterle un repaso a ver si realmente el servicio de PHP es el causante, porque únicamente hace consultas, pero a saber como está gestionando las conexiones. Para mí ahora mismo con cajas negras xD

2 respuestas
isvidal

#23105 Que version de PHP es?

1 respuesta
desu

#23105 lo primero que tienes que hacer es aislar los contenedores y detectar de manera individual que errores hay en cada uno. que no se comuniquen entre ellos.

empieza aislando la mysql y mirandotela. creando conexiones manuales y cerrandolas etc

1 respuesta
Leos

#23104 Pues no toco nada de la jvm, soy un pordiosero programador de php, pero me ha parecido algo interesante.

Últimamente ando trasteando cosas nuevas en mi tiempo libre, le daré un try a esto a ver que tal y así también veo si tiene una utilidad real en los proyectos del curro.

1 respuesta
eondev

#23106 Muy posiblemente PHP de cuando tu y yo no nacimos, pero programado hace 5 años. Mi empresa es muy de tener software relativamente nuevo con jquery y libs que ni su puta madre conoce ultra legacy que posiblemente encontrarian en algun tutorial de hace 15 años de un panchito en vimeo. Porque no me lo explico.
El PHP debe ser versión 4 o así, y la conexión a bbdd hecha a manivela.

3 respuestas
eondev

#23107 Eso empecé la semana pasada, primero que nada aislar el mysql y esa BBDD a ver como se comporta. Pero por trabajo aún no me he puesto.
Pregunto aquí por curiosidad, a ver qué buenas prácticas aplicar cuando haga limpieza a este berenjenal

Leos

#23109 Pues casi seguro que estan haciendo la conexión sin un pool y tampoco la cierran nunca, yo tiraria por ahí

desu

#23108 Esta presentacion esta bastante bien de CSP.

https://arild.github.io/csp-presentation/#10

1 1 respuesta
Naith

#23109 y que ha cambiado en los últimos meses? Ha aumentado la carga? Se ha actualizado algún software (php o mysql)?

1 respuesta
Leos

#23112 Gracias becario senior, siempre me descubres mundos nuevos <3

1 respuesta
eondev

#23113 Nada, no ha cambiado nada, los servidores y las instalaciones por norma general son invariables, hay problemas típicos de red, eléctricos y tal, algún que otro apagón. Pero en cuanto a nuestro software o el numero total de conexiones, es todo estándar y similar a hace unos meses y a otros sitios. Es lo que me trae de cabeza XD

isvidal

#23109 Supongo que sera PHP 5.6, ahi la PDO era una puta mierda pinchada en un palo aun.

Mucha suerte, yo intentaria migrar a PHP 7.4 (Incremento de performance del 30-40%, y muchas mejoras en la PDO). Ahora si el proyecto tiene 100mil lineas pues suerte.

1 respuesta
Fyn4r

#23116 Oye tu que sabes de teclados de modernos, donde se compran las keycaps? Es que las que veo me parecen carísimas (Aliexpress) no me creo que cuesten más que los switches, así que imagino que algo estoy haciendo mal xD

2 respuestas
desu

#23114 Si esta bien porque compara CSP y actor. Me gustaron esas 3 slides.

Lo que la grafica creo que esta un poco mal no?

Se bloquean el proceso 1 y el actor 1 en el read porque son ellos quienes inicializan y se quedan a la espera.

entiendo que seria asi no? XD esque el dibujo esta un poco raro. al ser la flecha del reves pero se inicializa antes en el tiempo. por tanto se bloquea y espera.

en el actor lo mismo. pero en el send el actor no bloquea.

eondev

#23117 pueden costar hasta 54985729475 veces más que los switches, xD. Por lo general +40 pavos te dejas fácil

1 respuesta
Fyn4r

#23119 Es que son los precios que estoy viendo, me quedo más tranquilo entonces xd

isvidal

#23117 Yo compre en Aliexpress, y te recomiendo que no seas barato, minimo + 30/40 euros.

Menos de eso recibiras chatarra.

1 respuesta
B

No me cuadra, gurus de la informatica comprando por ali express... si que va mal el pais.

Fyn4r

#23121 okok, por alguna razón pensé que serían piezas más baratas, pues un set de waifus por aquí

1 respuesta
isvidal

#23123 Comprate el pack entero de teclas:

https://es.aliexpress.com/item/1005002416614010.html?spm=a2g0o.search0302.0.0.6f8827d0bIIjQy&algo_pvid=1a548cd2-9f0d-4caf-9935-1aa70612d53d&algo_expid=1a548cd2-9f0d-4caf-9935-1aa70612d53d-1&btsid=0b0a050116208178133583333ea07e&ws_ab_test=searchweb0_0,searchweb201602,searchweb201603

1 respuesta
Kaledros

Hoy, en "nuevos lows de /feda/dev"...

Fyn4r

#23124 en eso estamos

https://www.amazon.es/Keycaps-sublimaci%C3%B3n-japon%C3%A9s-Gateron-mec%C3%A1nico/dp/B08G1VWKFM/ref=dp_prsubs_1?pd_rd_i=B08G1VWKFM&psc=1

Wei-Yu

pues yo esos keycaps me los pillaba, no porque me guste el anime si no porque soy un pedófilo

vivora

Suficiente /feda/dev por hoy

desu

2 respuestas
isvidal

#23129 Que cabron publicar nuestros whatsapps KEK

Usuarios habituales