Rails - Sep 2007 - ActiveRecord, blocking or async, logging, syslog/udp

Here''s a gedanken experiment for those w/ far more knowledge than I
about
ActiveRecord, etc.:

Let''s say my database is very remote and on a very slow machine. 
Let''s
further say that my app has an action that leads to a very simple insert
into the "impressions" table of the db, a la "INSERT INTO
impressions(docid)
VALUES($docid);" - and let''s say the db automatically adds
created_at as
now() and autoincrements primary key.

Will RoR/AR block on this insert?  If so is there a way to make it
non-blocking (asynchronous)?

Alternatively, let''s say I wanted to log such impressions on a remote
log
server using UDP and syslog - any guidance on doing that?  (Not all logging
mind you, but just this specific case).

Thanks,


Marc

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

In general ActiveRecord will block on this kind of request.

There''s a product called BackgroundDB that was built for offloading
slow
pages.
I''m not sure what the status is on that product, or if there''s
anything
newer.


This tends to be problematic but you can also do this.

If you want to return the page quickly without waiting for the outcome, 
you can fork a thread to handle the mysql insert, and return a page that 
doesn''t contain the results of that insert.

From past experience the mysql driver doesn''t deal well with threads. 
(One of the reasons why Rails is single threaded), so YMMV.



Marc Byrd wrote:
> Here''s a gedanken experiment for those w/ far more knowledge than
I
> about
> ActiveRecord, etc.:
> 
> Let''s say my database is very remote and on a very slow machine. 
Let''s
> further say that my app has an action that leads to a very simple insert
> into the "impressions" table of the db, a la "INSERT INTO 
> impressions(docid)
> VALUES($docid);" - and let''s say the db automatically adds
created_at as
> now() and autoincrements primary key.
> 
> Will RoR/AR block on this insert?  If so is there a way to make it
> non-blocking (asynchronous)?
> 
> Alternatively, let''s say I wanted to log such impressions on a
remote
> log
> server using UDP and syslog - any guidance on doing that?  (Not all 
> logging
> mind you, but just this specific case).
> 
> Thanks,
> 
> 
> Marc
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

What about mysql''s "INSERT DELAYED" - that would allow the
server to take
over, let the client proceed (non-blocking, asynchronous) - and/or perhaps
INSERT IGNORE ?

m


On 9/11/07, David Harkness
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
>
> In general ActiveRecord will block on this kind of request.
>
> There''s a product called BackgroundDB that was built for
offloading slow
> pages.
> I''m not sure what the status is on that product, or if
there''s anything
> newer.
>
>
> This tends to be problematic but you can also do this.
>
> If you want to return the page quickly without waiting for the outcome,
> you can fork a thread to handle the mysql insert, and return a page that
> doesn''t contain the results of that insert.
>
> From past experience the mysql driver doesn''t deal well with
threads.
> (One of the reasons why Rails is single threaded), so YMMV.
>
>
>
> Marc Byrd wrote:
> > Here''s a gedanken experiment for those w/ far more knowledge
than I
> > about
> > ActiveRecord, etc.:
> >
> > Let''s say my database is very remote and on a very slow
machine.  Let''s
> > further say that my app has an action that leads to a very simple
insert
> > into the "impressions" table of the db, a la "INSERT
INTO
> > impressions(docid)
> > VALUES($docid);" - and let''s say the db automatically
adds created_at as
> > now() and autoincrements primary key.
> >
> > Will RoR/AR block on this insert?  If so is there a way to make it
> > non-blocking (asynchronous)?
> >
> > Alternatively, let''s say I wanted to log such impressions on
a remote
> > log
> > server using UDP and syslog - any guidance on doing that?  (Not all
> > logging
> > mind you, but just this specific case).
> >
> > Thanks,
> >
> >
> > Marc
>
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

insert delayed only work with myisam talbes, and you are surely using 
innodb table.

a cool work around can came form mysql-proxy, wich can hold the loging, 
and return imediatly.
http://forge.mysql.com/wiki/MySQL_Proxy

mysql-proxy can be used to scale your database with master slave, using 
slave to do the read, and master for the write.
far more better than balance and other tcp load balancer.



Marc Byrd a écrit :
> What about mysql''s "INSERT DELAYED" - that would allow
the server to
> take over, let the client proceed (non-blocking, asynchronous) - 
> and/or perhaps INSERT IGNORE ?
>
> m
>
>
> On 9/11/07, *David Harkness*
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org
>
<mailto:rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>>
wrote:
>
>
>     In general ActiveRecord will block on this kind of request.
>
>     There''s a product called BackgroundDB that was built for
>     offloading slow
>     pages.
>     I''m not sure what the status is on that product, or if
there''s
>     anything
>     newer.
>
>
>     This tends to be problematic but you can also do this.
>
>     If you want to return the page quickly without waiting for the
>     outcome,
>     you can fork a thread to handle the mysql insert, and return a
>     page that
>     doesn''t contain the results of that insert.
>
>     From past experience the mysql driver doesn''t deal well with
threads.
>     (One of the reasons why Rails is single threaded), so YMMV.
>
>
>
>     Marc Byrd wrote:
>     > Here''s a gedanken experiment for those w/ far more
knowledge than I
>     > about
>     > ActiveRecord, etc.:
>     >
>     > Let''s say my database is very remote and on a very slow
>     machine.  Let''s
>     > further say that my app has an action that leads to a very
>     simple insert
>     > into the "impressions" table of the db, a la
"INSERT INTO
>     > impressions(docid)
>     > VALUES($docid);" - and let''s say the db
automatically adds
>     created_at as
>     > now() and autoincrements primary key.
>     >
>     > Will RoR/AR block on this insert?  If so is there a way to make it
>     > non-blocking (asynchronous)?
>     >
>     > Alternatively, let''s say I wanted to log such impressions
on a
>     remote
>     > log
>     > server using UDP and syslog - any guidance on doing that?  (Not
all
>     > logging
>     > mind you, but just this specific case).
>     >
>     > Thanks,
>     >
>     >
>     > Marc
>
>     --
>     Posted via http://www.ruby-forum.com/.
>
>
>
>
>
> >

NEW: Artprice Images(R): your access to past, present and upcoming auction
catalogues from 2,900 auction houses worldwide and to the largest art auction
library of 290,000 catalogues spanning from 1960 to the present days.

NOUVEAU: avec Artprice Images(R) accédez à tous les catalogues de ventes futures
de 2 900 maisons de ventes et au plus grand fonds documentaire sur le marché de
l''art avec 290 000 catalogues de vente de 1960 à nos jours.

NEU: Artprice Images(R) : Einsicht in sämtliche Kataloge kommender Auktionen von
weltweit 2.900 Auktionshäusern sowie in unser bis 1960 zurückreichendes Archiv
mit 290.000 Katalogen.

NUEVO: Artprice Images(R), acceda a todos los catálogos de las próximas subastas
de 2.900 subastadoras, y al fondo documentario más completo sobre el mercado del
arte con 290.000 catálogos de subastas desde 1960 hasta el día de hoy.

NUOVO: Artprice Images(R) le permetterà di accedere a tutti i cataloghi delle
vendite future delle 2.900 case d''aste e proporrà il piú importante
fondo documentario sul mercato dell''arte grazie ali 290.000 cataloghi
di vendita dal 1960 ad oggi.


"Ce message et toutes les pièces jointes sont des informations
strictement confidentielles et réservées au(x) destinataire(s). Ce
courriel n''a pas de valeur contractuelle et son contenu ne constitue ni
une acceptation, ni un engagement de la part de l''auteur et des
sociétés
du groupe Serveur et Artprice, sauf dans le cas où cela aurait été prévu
avec le destinataire par un accord écrit. Le contenu de ce message et
les pièces jointes ne peuvent constituer une preuve au sens de
l''article
1316-1 du Code Civil. L''auteur et les sociétés du groupe Serveur et
Artprice déclinent toute responsabilité au titre de ce courriel s''il a
été altéré, déformé, falsifié ou indûment utilisé par des tiers ou
encore s''il a causé tout dommage ou perte de toute nature. Si vous
n''êtes pas le bon destinataire, merci de nous contacter et de ne pas le
divulguer."

"This message including any attachments are confidential and privileged
material intended solely for the addressees. Its contents do not
constitute a commitment by groupe Serveur sas and Artprice SA, except
when provided for in a written agreement with the addressees. The
contents of this message cannot constitute neither the proof nor the
acceptance of any agreement as per article 1316-1 of the French civil code.
Groupe Serveur sas and Artprice SA shall not be rendered liable in any
manner whatsoever for the delay and/or loss in transit of this message,
for corruption, alteration, falsification, misuse or fraudulent use
(which may be made) of this message. If you receive this message in
error, please delete it and immediately notify the sender. If the reader
of this message is not the intended recipient, you are hereby notified
that any unauthorized use, copying or dissemination is prohibited."

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---