
Recherche avancée
Autres articles (97)
-
MediaSPIP 0.1 Beta version
25 avril 2011, parMediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
The zip file provided here only contains the sources of MediaSPIP in its standalone version.
To get a working installation, you must manually install all-software dependencies on the server.
If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...) -
Multilang : améliorer l’interface pour les blocs multilingues
18 février 2011, parMultilang est un plugin supplémentaire qui n’est pas activé par défaut lors de l’initialisation de MediaSPIP.
Après son activation, une préconfiguration est mise en place automatiquement par MediaSPIP init permettant à la nouvelle fonctionnalité d’être automatiquement opérationnelle. Il n’est donc pas obligatoire de passer par une étape de configuration pour cela. -
MediaSPIP Core : La Configuration
9 novembre 2010, parMediaSPIP Core fournit par défaut trois pages différentes de configuration (ces pages utilisent le plugin de configuration CFG pour fonctionner) : une page spécifique à la configuration générale du squelettes ; une page spécifique à la configuration de la page d’accueil du site ; une page spécifique à la configuration des secteurs ;
Il fournit également une page supplémentaire qui n’apparait que lorsque certains plugins sont activés permettant de contrôler l’affichage et les fonctionnalités spécifiques (...)
Sur d’autres sites (7704)
-
Revision 50045 : Et le meilleur pour la fin ... on post sur seenthis ... qui pourrait être ...
28 juillet 2011, par kent1@… — LogEt le meilleur pour la fin ... on post sur seenthis ... qui pourrait être amélioré (les admins du site seenthis si vous nous lisez) :
Si l’utilisateur n’est pas connecté et pointe sur cette adresse, lui proposer un formulaire de login pleine page pour éviter qu’il ne comprenne rien...
Lorsque l’on pointe sur l’adresse en question, mettre le focus de la souris en js sur le champs d’ajout de contenu afin de voir le bouton pour valider et ajouter du contenu si nécessaire au post
-
Revision 50045 : Et le meilleur pour la fin ... on post sur seenthis ... qui pourrait être ...
28 juillet 2011, par kent1@… — LogEt le meilleur pour la fin ... on post sur seenthis ... qui pourrait être amélioré (les admins du site seenthis si vous nous lisez) :
Si l’utilisateur n’est pas connecté et pointe sur cette adresse, lui proposer un formulaire de login pleine page pour éviter qu’il ne comprenne rien...
Lorsque l’on pointe sur l’adresse en question, mettre le focus de la souris en js sur le champs d’ajout de contenu afin de voir le bouton pour valider et ajouter du contenu si nécessaire au post
-
Dealing with long conversion times on nginx, ffmpeg and Ruby on Rails
19 avril 2013, par GraemeI have developed a Ruby on Rails-based app which allows users to upload videos to one of our local servers (Ubunto 10.04 LTS). The server uses nginx.
Through the paperclip-ffmpeg gem, videos are converted to mp4 format using the ffmpeg library.
Everything appears to be working fine in production, except Rails' own 500 page (not the customised version I have provided - but that's a different issue) is displayed whenever certain videos are uploaded. Otherwise, videos are being converted as expected.
Having done a bit of investigation, I think the default 500 page is being displayed because a 502 error has occurred. I think what is happening, having uploaded the videos locally, is that some videos are taking an extensive amount of time to convert, and that an interruption is occurring on the server (I'm not a server expert by any means).
Using the excellent Railscasts episode on deployment, I use Capistrano to deploy the app. Here's the
unicorn.rb
file :root = "XXXXXXX"
working_directory root
pid "#{root}/tmp/pids/unicorn.pid"
stderr_path "#{root}/log/unicorn.log"
stdout_path "#{root}/log/unicorn.log"
listen "/tmp/unicorn.XXXXXXXXX.sock"
worker_processes 2
timeout 200And here's the
nginx.conf
file. Note thatclient_max_body_size
has been set to a fairly hefty 4Gb ! :upstream unicorn {
server unix:/tmp/unicorn.XXXXXXXXX.sock fail_timeout=0;
}
server {
listen 80 default deferred;
root XXXXXXXXX;
location ^~ /assets/ {
gzip_static on;
expires max;
add_header Cache-Control public;
}
try_files $uri/index.html $uri @unicorn;
location @unicorn {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_read_timeout 600;
proxy_redirect off;
proxy_pass http://unicorn;
}
error_page 500 502 503 504 /500.html;
client_max_body_size 4G;
keepalive_timeout 10;
}So, my question is...how could I edit (either of) the above two files to deal with the extensive time that certain videos take to convert through ffmpeg - possibly up to an hour, 2 hours or even more ?
Should I extend
timeout
in the former and/orkeepalive_timeout
in the latter - or is there a more efficient way (given that I've no idea how long certain videos will take to convert) ?Or, is there possibly a more significant issue I should consider - e.g. the amount of memory in the server ?
I'm not an nginx/server expert, so any advice would be useful (particularly where to put extra lines of code) - however, as the rest of the app just "works", I'm not keen to make a huge amount of changes !