Consulta sobre bloqueos

fernan2 · July 10, 2008, 10:36am

Acabo de hacer que una lista de restaurantes se pueda ordenar por nÂº de
visitas:

El nÂº de visitas se actualiza en cada visita, en el show:
@producto.update_attribute(‘veces_visto’, 1 + (@producto.veces_visto ||
0))

Pero el problema es que mientras se estÃ¡ actualizando, que es algo
bastante frecuente, se produce un bloqueo, y si se intenta acceder justo
en ese instante darÃ¡ un error 500. De hecho, es fÃ¡cil hasta provocarlo
uno mismo: basta con entrar en uno de los restaurantes con mÃ¡s visitas:

Le das a recargar (F5) quince veces seguidas, rÃ¡pido, y te vas enseguida
a la lista ordenada por visitas… y enseguida tienes un error 500

Para tratar de solucionarlo, he intentado hacer que la actualizaciÃ³n se
haga retrasada:
spawn do
@producto.update_attribute(‘veces_visto’, 1 + (@producto.veces_visto
|| 0))
end

Pero lo Ãºnico que consigo es que el error 500 se produzca un poco
despuÃ©s… pero producirse, se produce igualmente.

Â¿Alguien se ha encontrado con este tipo de problemas? Â¿CÃ³mo pueden
solucionarse los conflictos de bloqueo, para campos que se actualizan
con mucha frecuencia?

PD: Y si encima se va a las Ãºltimas pÃ¡ginas, las probabilidades de
bloqueo se multiplican, pues MySQL recorre todos los registros hasta
llegar a los solicitados, y si alguno de los intermedios estÃ¡
bloqueado… E500.

s2

fernan2 · July 10, 2008, 3:03pm

On Jul 10, 2008, at 10:36 AM, Fernando C. wrote:

Pero lo único que consigo es que el error 500 se produzca un poco
después… pero producirse, se produce igualmente.

¿Alguien se ha encontrado con este tipo de problemas? ¿Cómo pueden
solucionarse los conflictos de bloqueo, para campos que se actualizan
con mucha frecuencia?

Puedes mandar el log de la aplicación cuando te da el error 500.

¿En que maquina tienes la aplicación funcionando?

fernan2 · July 11, 2008, 9:44am

Francesc E. wrote:

Puedes mandar el log de la aplicaciï¿½n cuando te da el error 500.

FLIPANTE EL LOG!!!

Fijaos en esto:

Processing RestaurantesController#lista
Parameters: {“action”=>“lista”, “controller”=>“restaurantes”,
“orden”=>“visitas”}

El cÃ³digo es este:

pagina = (params[:page] ||= 1).to_i
orden = (params[:orden]) || "comentarios"
orden = orden.sub('visitas', 'veces_visto')
orden += " Desc" if

[“puntuacion_media”,“contenidos_count”,“guardado_count”,
“veces_visto”].include?(orden)
join = @ver_provincia ? “inner join provincias p on p.id =
productos.provincia_id” : “”

@nproductos = Producto.count(:all, :joins => join )
@productos = Producto.paginate(:all, :per_page =>

Producto::PRODUCTOS_EN_LISTA, :page => pagina,
:select => “productos.nombre, productos.localidad,
#{@ver_provincia ? “p.nombre as provincia_,” : “”}
productos.puntuacion_media,
productos.contenidos_count, productos.guardado_count,
productos.id, productos.permalink,
productos.type, productos.anyo,
productos.id_publicado,
productos.veces_visto”,
:joins => join, :order => orden + “, nombre”,
:total_entries => @nproductos)

Normalmente esto funciona bien y genera esta consulta SQL:

SELECT productos.nombre, productos.localidad, p.nombre as provincia_,
productos.puntuacion_media, productos.contenidos_count,
productos.guardado_count, productos.id,
productos.permalink, productos.type, productos.anyo,
productos.id_publicado,
productos.veces_visto FROM productos inner join provincias p on
p.id = productos.provincia_id ORDER BY visitas, nombre LIMIT 0, 50

Y el error del log es este (lo he comprobado varias veces porque no me
lo creÃa):

ActiveRecord::StatementInvalid (Mysql::Error: Unknown column ‘visitas’
in ‘order clause’: SELECT productos.nombre, productos.localidad,
p.nombre as provincia_, productos.puntuacion_media,
productos.contenidos_count,
productos.guardado_count, productos.id,
productos.permalink, productos.type, productos.anyo FROM productos
inner join provincias p on p.id = productos.provincia_id WHERE
(productos.subtipo_id = 41 ) ORDER BY visitas, nombre LIMIT 0, 50)

Es decir, que cuando no puede acceder al campo veces_visto porque se
estÃ¡ actualizando, me recorta los dos Ãºltimos campos del SELECT
(productos.id_publicado, productos.veces_visto) y no me hace el orden =
orden.sub(‘visitas’, ‘veces_visto’). EN VEZ DE UN ERROR DE BASE DE
DATOS, LO QUE FALLA ES EL RAILS!!

ï¿½En que maquina tienes la aplicaciï¿½n funcionando?

La aplicaciÃ³n corre sobre un servidor CentOS, en el que tambiÃ©n estÃ¡ la
BBDD MySQL.

s2

fernan2 · July 13, 2008, 12:56am

2008/7/10 Fernando C. [email protected]:

Pero el problema es que mientras se estÃ¡ actualizando, que es algo
bastante frecuente, se produce un bloqueo, y si se intenta acceder justo
en ese instante darÃ¡ un error 500.

Fernando averiguaste algo sobre esto?

fernan2 · July 13, 2008, 9:21am

Hola Fernando,

por lo que cuentas a mÃ me suena que puede ser un tema de que los
UPDATEs sobre la fila estÃ©n bloqueando los SELECT de esa misma fila.

Creo que es un pequeÃ±o error de diseÃ±o fÃ¡cilmente subsanable si sacas
las estadÃsticas a otra tabla o incluso a otra base de datos:

Si lo sacas a otra tabla puedes cachear el valor del contador de
visitas para que el SELECT no se efectÃºe directamente sino contra el
valor cacheado.

Y si lo sacas a otra tabla puedes usar una fantÃ¡stica funciÃ³n de
ActiveRecord un poco desconocida: stablish_connection.

Nosotros en unvlog.com, tenemos un modelo hit (pÃ¡gina vista) definido
asÃ:

class Hit < ActiveRecord::Base

Hit.establish_connection(‘stats’)

def self.create_hit!(post_id, user_id)
Hit.create(:post_id => post_id, :user_id => user_id)
end

end

Ten en cuenta que si estÃ¡ en otra tabla no puedes usar relaciones de
ActiveRecord, pero es un mal menor si defines mÃ©todos en las clases.

Espero que te sirva.

2008/7/10 Fernando C. [email protected]:

fernan2 · July 13, 2008, 9:35am

On Jul 13, 2008, at 9:21 AM, Fernando B. wrote:

Y si lo sacas a otra tabla puedes usar una fantástica función de
ActiveRecord un poco desconocida: stablish_connection.

Fernando … te falta el café de la mañana.

“Y si lo sacas a otra base de datos … un poco desconocida
establish_connection”

fernan2 · July 13, 2008, 10:57am

Me he colado, sÃ, es

Modelo.establish_connection

Â¿Te refieres a eso, no?

On Sun, Jul 13, 2008 at 9:34 AM, Francesc E.

fernan2 · July 13, 2008, 11:00am

On Jul 13, 2008, at 10:57 AM, Fernando B. wrote:

¿Te refieres a eso, no?

Si.

fernan2 · July 14, 2008, 1:01pm

Fernando B. wrote:

Hola Fernando,

por lo que cuentas a mÃ me suena que puede ser un tema de que los
UPDATEs sobre la fila estÃ©n bloqueando los SELECT de esa misma fila.

Creo que es un pequeÃ±o error de diseÃ±o fÃ¡cilmente subsanable si sacas
las estadÃsticas a otra tabla o incluso a otra base de datos:

Si lo sacas a otra tabla puedes cachear el valor del contador de
visitas para que el SELECT no se efectÃºe directamente sino contra el
valor cacheado.

Y si lo sacas a otra tabla puedes usar una fantÃ¡stica funciÃ³n de
ActiveRecord un poco desconocida: stablish_connection.

Nosotros en unvlog.com, tenemos un modelo hit (pÃ¡gina vista) definido
asÃ:

class Hit < ActiveRecord::Base

Hit.establish_connection(‘stats’)

def self.create_hit!(post_id, user_id)
Hit.create(:post_id => post_id, :user_id => user_id)
end

end

Ten en cuenta que si estÃ¡ en otra tabla no puedes usar relaciones de
ActiveRecord, pero es un mal menor si defines mÃ©todos en las clases.

Espero que te sirva.

2008/7/10 Fernando C. [email protected]:

El tema de cachear ya me lo habÃa planteado… de hecho, en realidad
para cachear no necesitarÃa ni siquiera otra tabla, me bastarÃa con otro
campo de la misma tabla: uno de los campos serÃa para escritura, y otro
serÃa el cachÃ© que utilizarÃa para lectura; y una vez al dÃa, cargar los
datos al cachÃ©. Pero claro, al no ser en tiempo real, es una soluciÃ³n
menos buena…

Utilizar distintas tablas o incluso distintas BBDD, entiendo que serÃa
para aÃ±adir un registro por cada visita, y no como hasta ahora
incrementar un contador; pero entiendo que o vamos a cacheado (que se
puede hacer igual en la misma tabla, aÃ±adiendo un campo), o si vamos a
tiempo real puede que el rendimiento de consultar una tabla con tantos
registros sea muy bajo, Â¿no?

s2

fernan2 · July 13, 2008, 11:07am

Gracias, me faltaban dos cafÃ©s, sÃ

On Sun, Jul 13, 2008 at 10:59 AM, Francesc E.

fernan2 · July 14, 2008, 2:27pm

On Jul 14, 2008, at 1:01 PM, Fernando C. wrote:

El tema de cachear ya me lo había planteado… de hecho, en realidad
para cachear no necesitaría ni siquiera otra tabla, me bastaría con
otro
campo de la misma tabla: uno de los campos sería para escritura, y
otro
sería el caché que utilizaría para lectura; y una vez al día, cargar
los
datos al caché. Pero claro, al no ser en tiempo real, es una solución
menos buena…

Y no has pensado en inesertar todas los visualizaciones en algun
sistema de colas
que vayas procesando cada X tiempo, no es en tiempo real, pero no es
mala
solución.

Se visualiza una url.
Metes esa visualización en la cola.
Cada minuto procesas la cola.

fernan2 · July 14, 2008, 8:14pm

Francesc E. wrote:

Y no has pensado en inesertar todas los visualizaciones en algun
sistema de colas
que vayas procesando cada X tiempo, no es en tiempo real, pero no es
mala
soluciï¿½n.

Se visualiza una url.

Metes esa visualizaciï¿½n en la cola.

Cada minuto procesas la cola.

Lo de las colas suena bien… Â¿tienes alguna URL donde expliquen cÃ³mo
funciona?

fernan2 · July 14, 2008, 7:41pm

TambiÃ©n hay que tener en cuenta que segÃºn el esquema de la tabla el
bloque se produce a nivel de fila (Innodb) o de tabla entera (MyISAM).

2008/7/14 Francesc E. [email protected]:

fernan2 · July 14, 2008, 8:16pm

Fernando B. wrote:

TambiÃ©n hay que tener en cuenta que segÃºn el esquema de la tabla el
bloque se produce a nivel de fila (Innodb) o de tabla entera (MyISAM).

2008/7/14 Francesc E. [email protected]:

En este caso el bloqueo es a nivel de fila, es Innodb, pero en una lista
en las que hay que consultar muchas filas la probabilidad de colisiÃ³n no
es lo suficientemente baja como para darla por aceptable…

fernan2 · July 14, 2008, 8:30pm

Nosotros en La Coctelera y unvlog.com tenemos Delayed Jobs:

http://blog.leetsoft.com/2008/2/17/delayed-job-dj

2008/7/14 Fernando C. [email protected]:

fernan2 · July 14, 2008, 9:30pm

On Jul 14, 2008, at 8:30 PM, Fernando B. wrote:

Nosotros en La Coctelera y unvlog.com tenemos Delayed Jobs:

http://blog.leetsoft.com/2008/2/17/delayed-job-dj

Ostras … yo lo estuve valorando, pero es que me pareciÃ³ bastante feo
hacer inserts de los jobs en la base de datos. Lo interesante de
Delayed Jobs es que al estar los jobs dentro de la base de datos es
“mÃ¡s fÃ¡cil” meter sistemas de prioridades, horas de ejecuciÃ³n. Si a
veces ya hay problemas con el rendimiento de la base de datos, Â¿meter
Delayed Jobs no es meterle un poco mÃ¡s de carga a la base de datos?

Que lo hayan extraido de Shopify es un punto a favor.
Que los jobs sean persistentes es un punto a favor.

Despues de haber utilizado BackgroundRb … y haberme acordado del
desarrollador varias veces por cambios en la API, al final valorÃ© las
opciones de Beanstalkd y Starling, y por necesidades de persistencia
al final optÃ© por Starling. Como ya comentÃ© extraje un plugin que se
llama simplified_starling [1] que creo que simplifica bastante la
gestion de colas y es super facil de integrar en una aplicaciÃ³n.

[1] http://github.com/fesplugas/simplified_starling/tree/master

fernan2 · July 14, 2008, 8:46pm

Yo uso Amazon SQS, el sistema de colas que proporciona Amazon Web
Services [1], con la gema right_aws [2].

[1] http://aws.amazon.com/
[2] http://rightaws.rubyforge.org/

Salu2,

fernan2 · July 14, 2008, 9:46pm

Por que es una cola solucion a este problema?

fernan2 · July 14, 2008, 10:18pm

Xavier N. wrote:

Por que es una cola solucion a este problema?

Entiendo que la idea es que ya que se van a hacer muchÃsimas
actualizaciones, que puntualmente provocarÃ¡n colisiones con lecturas de
forma mÃ¡s o menos aleatoria… si se pueden agrupar las actualizaciones,
y llevarlas a cabo en un momento de menor carga, se reduce la
probabilidad de colisiones.

De todos modos, estÃ¡ claro que meter una tabla especÃfica con un
registro por cada pÃ¡gina vista serÃa una soluciÃ³n mÃ¡s efectiva, pues
segÃºn lo veo yo la cola amortiguarÃa pero no resolverÃa del todo el
problema; pero falta ver si eso no serÃa un poco “matar moscas a
caÃ±onazos”…

Aunque no tengo claro si realmente, mediante colas, se puede conseguir
una soluciÃ³n al 100% del problema, o sÃ³lo una mejora (como yo veo).

s2

fernan2 · July 14, 2008, 10:23pm

On Jul 14, 2008, at 9:45 PM, Xavier N. wrote:

Por que es una cola solucion a este problema?

Cada vez que alguien carga una página se contabiliza y se guarda en la
base de datos. Eso no deberia ser un problema, pero Fernando C.
tiene problemas con los bloqueos de la base de datos.

Entre las opciones que se le han dado, yo comenté tener una cola donde
se fueran contabilizando todas estas consultas y que cada X minutos se
fuera procesando. Quizas una cola no es una solución a este problema,
pero es una opción para solucionarlo. ¿No?

Yo hice el comentario, Fernando B. comentó como lo hacen en La
Coctelera, y yo he continuado hablando de colas.

Lo que seria interesante saber es que tipo de tablas está utilizando,
como está el servidor de carga, etc …