Alguna sugerencia sobre los uploads?

Community ES
1

Hola amigos, queria solicitarles alguna sugerencia sobre un tema que me
trae
loco hace varios dias sobre la subida de archivos en mi aplicación,
tengo
entendido que la aplicacion tiene esperando a mongrel hasta que termine
de
procesar el archivo subido, por lo tanto ese mongrel no puede atender
mas
peticiones, hasta ahi lo tengo bien claro, lo que no se exactamente es
como
determinar cuando necesitaria de Merb(el cual ya lo he visto he usado y
es
realmente facil) para que me ayude en esto ya que Merb es multihilo y
todo
lo demas, aunque los archivos(imagenes) son realmente pequeños(menos de
1mb)
y el procesamiento no va mas alla de un redimensionamiento, para esto
empleo
attachment_fu y mini-magick, aparte de esto tambien tendre un buscador
trabajando con UltraSphinx, entonces asumiendo que tengo unos 5 mongrels
andando, cual seria aproximadamente la carga que podria soportar?.

Les agredeceria bastante si me pueden recomendar un buen libro|manual
donde
puede aprender mas sobre temas de pruebas de stress, ya que terminos
como
“request por segundo”, “conexiones concurrentes”, “conexiones abiertas”
realmente no los entiendo muy bien y creo que esto me limita bastante.

Muchas gracias por su tiempo.

2

1mb) y el procesamiento no va mas alla de un redimensionamiento,
para esto empleo attachment_fu y mini-magick, aparte de esto tambien
tendre un buscador trabajando con UltraSphinx, entonces asumiendo
que tengo unos 5 mongrels andando, cual seria aproximadamente la
carga que podria soportar?.

Les agredeceria bastante si me pueden recomendar un buen libro|
manual donde puede aprender mas sobre temas de pruebas de stress, ya
que terminos como “request por segundo”, “conexiones concurrentes”,
“conexiones abiertas” realmente no los entiendo muy bien y creo que
esto me limita bastante.

Buf, la verdad es que son demasiadas preguntas y yo bastante torpe de
todas formas en mis favoritos tenia estos dos enlaces que a lo mejor
te sirven un poco

Un saludo.

3

Hola alarkspur, muchas gracias por los enlaces aunque ya los habia
revisado
anteriormente, por cierto ese manual para subir archivos con merb esta
desactualizado, ahorita estamos con merb 0.9.2, la parte para subir
archivos
con merb si la comprendo es mas tengo una pequeña app, el caso es que la
integracion con una aplicacion en Rails va mas alla de simplemente subir
un
archivo, ya que hay que insertar el registro en la tabla tambien, para
esto
he visto attachmerb_fu el cual solo funciona con DataMapper, asi que se
van
complicando las cosas un poco.

Saludos.

2008/3/26, alarkspur [email protected]:

4

Hola cartuchoGL, gracias por tu respuesta, justamente hace poco compre
ese
pdf ;), creo que he sido un poco extenso en mi consulta, para ser mas
consiso preguntaria lo siguiente:

Si te dijeran que crees una aplicación en la cual los usuarios pueden
opcionalmente subir hasta 3 imagenes, y ademas tienes que redimensionar
las
imagenes para que no rompa el diseño del sitio, pensarias en merb de
buenas
a primeras?

Creo que esa seria mi duda puntualmente, ahora creo que me estoy
haciendo
demasiados problemas sin antes empezar a hacer algo, asi que creo que
mejor
usare solo rails con attachment_fu sin mas complicaciones y luego ya que
venga la carga de usuarios estaria implementando algo en merb.

Saludos.

El día 26/03/08, cartuchoGL [email protected] escribió:

5

alguien cree que es buena idea generar alguna especie de proxy a una
acción
en php , me refiero a un recurso en php que suba el archivo y lo
optimize
con GD por ejemplo ?? digo , para optimizar el uso del mongrel…

por otro lado he hecho pruebas con merb dentro de una app en rails con
una
gema que hace de puente al programa GD y ahi hacer las optimizaciones a
la
imagen.

¿pero al hacer esta operacion con merb hay una cuota asegurada de
threads
por mongrel ? o hay que realizar otro tipo de optimizaciones a la
aplicacion
para que maneje apropiadamente los mongrel?

gracias

2008/3/26 Ruben. D. [email protected]:

6

Ruben. D. escribió:

Hola alarkspur, muchas gracias por los enlaces aunque ya los habia
revisado anteriormente, por cierto ese manual para subir archivos con
merb esta desactualizado, ahorita estamos con merb 0.9.2, la parte
para subir archivos con merb si la comprendo es mas tengo una pequeña
app, el caso es que la integracion con una aplicacion en Rails va mas
alla de simplemente subir un archivo, ya que hay que insertar el
registro en la tabla tambien, para esto he visto attachmerb_fu el cual
solo funciona con DataMapper, asi que se van complicando las cosas un
poco.

Supongo que lo bueno de usar merb, al menos en produccion, es usar
DataMapper ya que este, a diferencia de ActiveRecord, es thread-save,
que es el motivo por el que lo quieres usar para subir archivos.

De hecho, supongo que, para convivir los dos bastaria con que merb usara
para conectar DataMapper a una base de datos el mismo fichero de
configuracion de rails y un modelo parecido a:

class Attachment < DataMapper::Base
property :content_type, :string
property :filename, :string
property :size, :integer

used with thumbnails, always required

property :parent_id, :integer
property :thumbnail, :string

required for images only

property :width, :integer
property :height, :integer

required for db-based files only

property :db_file_id, :integer
end

y el resto supongo que no seria mas complicado.

Un saludo y suerte.

P.D. Tampoco estaria de mas que le hecharas un viste a pdf de peepcode
[1] sobre merb.

[1] https://peepcode.com/products/meet-merb-pdf-draft

7

Ruben. D. escribió:

haciendo demasiados problemas sin antes empezar a hacer algo, asi que
creo que mejor usare solo rails con attachment_fu sin mas
complicaciones y luego ya que venga la carga de usuarios estaria
implementando algo en merb.

Esto justamente es lo que recomendaria, primero prototipea con rails, y
cuando tengas toda la funcionalidad que buscas, haz pruebas de carga,
rendimiento, etc… estudia los problemas y adapta el prototipo a tus
exigencias. No hay peor enfermedad que la optimizacion prematura.

Por que muchas veces los prototipos no terminan de cuajar, la
interaccion con el usuario es demasiado compleja, los tiempos de espera
no son los adecuados, el disenyo lo hace todo confuso, etc…

Para mi una de las grandes virtudes de rails es precisamente esto,
prototipea rapido y si no funciona desechalo. Cuando tengas lo que estas
buscando, puedes optimizar las piezas que sean necesarias, cambiar la
filosofia de despliegue, el framework o incluso escribirlo enteramente
como cgis en C :wink:

Un saludo y suerte.

8

El 26/03/08, Ruben. D. [email protected]
escribió:> Les agredeceria bastante si me pueden recomendar un buen libro|manual donde

puede aprender mas sobre temas de pruebas de stress, ya que terminos como
“request por segundo”, “conexiones concurrentes”, “conexiones abiertas”
realmente no los entiendo muy bien y creo que esto me limita bastante.

Hola Rubén, hay muchas herramientas para pruebas de stress [1]. Échale
un vistazo a Siege [2], puedes “atacar” varias URL con conexiones
simultáneas y medir tiempos de respuesta y bastante más:

[1] http://www.opensourcetesting.org/performance.php
[2] Siege 3.0.3 and URL Encoding

9

Hola Jaime, muchas gracias por tu respuesta, sin duda hay un sin fin de
herramientas para hacer pruebas de stress, de las cuales creo que la mas
completa es httperf, el problema que tengo hasta ahora es que no
comprendo
muy bien ni he encontrado un buen manual que explqieu como es que
trabajan
por ejemplo el numero de usuarios concurrentes y el numero de
peticiones,
que son parametros que se comunmente se les pasa a estos programas, el
numero de concurrencia tengo entendido que es el numero de usuarios
conectados en ese mismo instante a la aplicacion, lo que no entiendo
bien es
como anda el numero de peticiones, osea son varios terminos que no me
quedan
muy claros de las pruebas de stress en general.

Saludos.

2008/3/29, Jaime I. [email protected]:

10

Vaya veo que en siege hay bastante documentacion, creo que al fin podre
aclarar muchas de mis dudas, muchas gracias nuevamente Jaime.

Saludos.

El día 29/03/08, Ruben. D. [email protected] escribió: