Reprise du message précédent :

C'est limité qu'à 2Mo? Pour les gifs ça apparait plus clairement quand la taille est plus importante (image avec marqué "image trop lourde pour notre service" )

Avec le problème d'il y a 2 semaines il va falloir que je retrouve l'image qui servait à ça c'est vrai tiens.
 
Mais oui c'est limité à 2 Mo depuis un moment

Bon je viens de fixer un bug, sur le rehosting, le serveur faisait la génération des preview et thumb sur les gifs animés, ça bouffait pas mal de CPU (surtout quand d'un coup y'en a 20 qui arrivent en même temps). Maintenant s'il détecte plus d'une frame dans un gif, il ne fait pas la génération ni le resize.

J'ai une petite question, ma bannière du topic casque à disparu, y'a moyen de la retrouver, ou il faut que j'en fasse une autre ?    
 
ici : http://forum.hardware.fr/hfr/Video [...] 1278_1.htm
 
PS : c'est mal tombé, car je l'ai pas sauvegardé dans mon PC, je viens d'installer win 8 et du coup j'ai supprimé mon ancienne partition.  

Je suis désolé mais c'est mort, j'ai passé 8 heures pour essayer de récupérer les données sans succès Depuis j'ai changés des choses dans la structure pour pouvoir backuper a minima les images uploadées.
 
J'ai cherché sur le cache google, il a bien la page, dans la preview y'a bien l'image, mais je n'arrive pas à avoir un cache pour l'image elle même
 
https://www.google.fr/#hl=fr&output [...] 37&bih=651

 
Ok, bon pas grave, j'en referait une autre ce soir.  
 
Cette fois je garderai une copie sur un CD, au cas ou.  
 
Edith : c'est bon, je l'ai refait rapidement (entre deux whisky / coca).
 
C'est pour ça que je garde paint shop pro 7, je le connais tellement que même déchiré, ça va vite...  

Ok, vu que ça affichait pas l'image comme quoi la taille max était dépassée, je pensais que c'était un bug avec dropbox

Et du coup avec le super nouveau système ya pas moyen d'augmenter la taille max des images?

On va y aller progressivement, ça va quand même vite à se remplir (50 Go en 1 semaine là)

Il y a un système de vérification genre via le Hash de l'image pour éviter d'uploader plusieurs fois la même image ?

Le système actuel génère le hash en fonction de la date ( microtime() ) et il n'y a pas de check de doublon sur les images uploadées. J'avais effectivement pensé à changer ça et à générer le hash en fonction du contenu de l'image lui même, mais j'ai peur que ça génère de la charge CPU. Je pense qu'à terme je le ferai quand même, parce que là je constate pour le moment que le très gros du trafic vient du rehost, pas de l'upload et qu'un hash ça va quand même assez vite même si c'est violent niveau CPU.
 
Je vais faire des tests pour voir, j'attends d'avoir un peu plus d'historique sur le CPU et le load après les modifs de ce WE avant de voir ça

Pour info pour les curieux, l'utilisation de l'espace par les images depuis 1 semaine que c'est relancé :

[root@node-b1] /data/sites/hfr-rehost/media> du -hs
53G     .
[root@node-b1] /data/sites/hfr-rehost/media> du -hs */*
387M    gifs/fullsize
12M     images/230
41M     images/600
1.6G    images/fullsize
5.1G    rehost/230
14G     rehost/600
32G     rehost/fullsize

gifs -> images uploadées en format gif
images -> autres images uploadées
rehost -> images proxifiées en rehosting

230 -> thumb
600 -> preview

Nombre d'images sur le serveur :
mysql> SELECT COUNT(*) FROM media_gif;
+----------+
| COUNT(*) |
+----------+
|      518 |
+----------+
1 row in set (0.00 sec)

mysql> SELECT COUNT(*) FROM media_images;
+----------+
| COUNT(*) |
+----------+
|    28536 |
+----------+
1 row in set (0.00 sec)

mysql> SELECT COUNT(*) FROM media_rehost;
+----------+
| COUNT(*) |
+----------+
|   169789 |
+----------+
1 row in set (0.00 sec)

mysql>

Les Thumbs et Previews ne pourraient pas être généré que si on s'en sert ?
 
Sur le rehost ca fait déjà 5Go de cramé pour un truc de doit servir de façon hyper anecdotique

C'est pour ça que je fais des stats en bdd pour voir le comportement et adaper en fonction.

Hello, quelques adaptations du WE, suite aux retours et aux analyses de comportement :

1) Réunification des url entre rehost et upload :

 - Pour rehost : /<url> pour l'image, /preview/<url> pour la preview et /thumb/<url> pour le thumb (avec ou sans http:// pour l'url)
  - Pour les gif uploadés : uniquement taille réelle en /gif/<hash>.gif
  - Pour les autres images uploadées : /self/<hash>.<ext> pour les images, /preview/self/<hash>.<ext> pour la preview et /thumb/self/<hash>.<ext> pour le thumb.

Peut-être les gifs vont repasser en /self/ aussi, ça sera plus pratique, mais j'ai eu la flemme de le faire là.

2) Génération des previews et thumbs à la première vue dans le format :

Avant les conversions étaient faites à l'upload et au moment du rehost de l'image réelle pour tous les formats. Comme remarqué, certaines images ne seront jamais demandées à un format réduit et on peut les générer quand on veut à partir de l'image d'origine qu'on a. Donc on génère les formats réduits un par un à leur première demande.

3) Génération du hash par rapport au fichier uploadé :

Le hash d'un fichier uploadé n'est plus en fonction de la microseconde du temps à laquelle il a été uploadé mais en fonction du fichier lui même (fonction sha1_file() ). Ca permet d'éviter les doublons d'une même image en ayant un hash identique et un seul fichier si plusieurs personnes ont uploadé la même image. Si vous avez l'image en local, vous pouvez aussi retrouver l'url en faisant le sha1 de votre fichier et savoir s'il est sur le serveur ou pas.

ok ça roule
 
tu peux aussi faire le point sur les urls "fullsize" / view / I ou autre ?
 
et sur le support des anciens format ?

 
Les urls fullsize /view/  et j'ai gardé tous les formats précédents compatibles

hum alors les lien fullsize ou view ne marche pas sur le rehost

fullsize

view

et le fullsize (ancien format) ne marche par sur l'upload

ni le view avec l'ancien format

(alors que les anciens format images fonctionnent dans les 2 cas)

c'est quoi exactement la limitre sur la taille des image en rehost et en upload ?

et aussi pour l'image de "c'est trop gros fuck you" ça en est où ? nazztazz doit bien l'avoir dans un coin, ou au pire en faire une autre, j'ai un script qu'est basé dessus et qui du coup fonctionne plus...

Désole d'être si curieux mais le serveur est en connexion 100Mbit ou 1000 ?  

2Mo c'est marqué au dessus

cette image fait 3,3 Mo
 

Ca me fait penser que justement, si on pouvait carrément empêcher l'affichage des images de plus de 1 ou 2Mo, ça serait merveilleux pour les très nombreux petits débits dont je fais parti.  

Le retaillage en fonction de la largeur d'affichage, c'est bien, mais ça ne change évidemment rien au chargement des images.    

Nan ça serait débile, ya des topic où toutes les images sont grosses (genre topic gif, ou topic photo peut-être)...
Par contre normalement les posteurs sont pas trop cons et use et abuse de la fonction 'preview'

 
   
 
 
Ceci dit, effectivement, le topic gif...    
 
nb : j'ai essayé 1 fois ou deux d'y aller. Bah je n'ai pas insisté plus.    

A la limite demande plutot à ceux qui font les extensions FF et Chrome de mettre par défaut le preview, et pas le full size
 
Mais obliger à utiliser une "fonction", c'est pas une solution

Ok je regarde ça ce soir ou demain soir c'est pas normal (mais j'ai effectivement pas testé et pensé que pour le rehosting ça pouvait être utilisé la page html)
 

1Gbps, mais de toute façon ça change rien vu qu'on utilise 50 Mbps au plus fort de la journée. Je devrais même le limiter à 100 Mbps par sécurité en fait.
 

Oui, elle est affichée depuis la source mais pas stockée sur le serveur normalement.
 

Dans l'optique de créer des comptes users pour les uploads, est-ce qu'éventuellement prévoir un profil enregistré où on peut définir qu'on veut pas afficher les images rehostées plus grosse qu'un certain format (preview ou intermédiaire entre preview et fullsize), ça pourrait le faire ?

Bah écoute, le technicien, c'est toi.
 
Moi l'utilisateur je dis juste que lorsqu'un nouveau (ou pas d'ailleurs) arrive sur le sujet image et balance quelques images de 4-5 Mo chacune, c'est l'enfer à charger pour nous.  

Je demande d'un point de vue utilisateur, s'il y a moyen de contrôler en fonction de l'utilisateur le format, ça te solutionnerait ton problème j'imagine ?

ok that's clever ... mais alors dans quel cas on obtient/obtenait l'image "trop gros fuck you" ? ... notamment sur gif d'ailleurs (en rehost)

Une case à cocher dans son profil, ou un champ de taille max à remplir ?
 
Pourquoi pas.  

Ca ne me dérangerait pas du tout cette "limitation" !

heh t'as aussi corrigé le probleme des urls qui contiennent thumb ou preview, s'cool

Yep, et je viens de corriger le problème des pages html "fullsize/", "I/" et "view/" (par contre faut forcément avoir /self/ derrière pour les images uploadées et /gif/ pour les gifs uploadés sinon ça marche pas, mais pas pour les urls)

Exemples :

URL :
hfr-rehost.net/view/https://fbcdn-sphotos-e-a.akamaihd.net/hphotos-ak-ash4/230515_10151175971512668_1860889455_n.jpg
hfr-rehost.net/fullsize/https://fbcdn-sphotos-e-a.akamaihd.net/hphotos-ak-ash4/230515_10151175971512668_1860889455_n.jpg

Images (hors gifs) :
hfr-rehost.net/view/self/b5b245bafee80c4ce394cffdaca8352c03ca1048.jpg
hfr-rehost.net/fullsize/self/b5b245bafee80c4ce394cffdaca8352c03ca1048.jpg
hfr-rehost.net/I/self/b5b245bafee80c4ce394cffdaca8352c03ca1048.jpg

Gifs :
hfr-rehost.net/view/gif/b8d4f4da8d2d83f0c1c18f61fbd141f4c9cc06a0.gif
hfr-rehost.net/fullsize/gif/b8d4f4da8d2d83f0c1c18f61fbd141f4c9cc06a0.gif

parfait

humour
'tain c'est à nouveau en rade, je ne vois pas les images du message de Sly  
/humour
 
Sacré travail, sly, un grand merci !
 

Merci
 
Je suis en train de préparer le support multiserveurs et caching, maintenant que c'est stabilisé (bonne visibilité sur la place et le charge)
 
Je viens de m'apercevoir qu'en fait la limite pour le rehost est à 4 Mo et non 2 Mo Et que toutes les plus grosses images (4 Mo) sont des gif...  (souvent débiles d'ailleurs )

Faire tout cela sur ton temps, pour un serveur bénévole .............. bravo    

attention car il y a des gros bourrins qui mettent 30 images en rehost, et valident sans faire preview... il suffit donc de 10 personnes qui cliquent sur leur drapeau et t'as 10x30 rehostages au "premier" affichage...
c'est ce qui tuait le serveur l'an dernier en tout cas ( http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0 )

moyenné sur combien de temps, l'intervalle de stat ?

donc hfr-rehost se comporte comme un anti-antileech, c'est ca ?

 
1) Bah de toute façon avant c'était pire, ça générait tous les formats à la première demande, là ça génère que le format demandé. De toute façon y'a pas de miracle sur le rehost, on peut pas anticiper la demande de l'image et précalculer comme à l'upload... C'est moins lourd maintenant.  
 
2) Si c'est au plus fort, je vois pas trop l'intérêt de la question et de parler de moyenne
 
3) C'est un effet de bord. Faut voir si ça reste, je pense à faire une conversion plutôt si l'image est trop grosse, mais ça pose le problème des gifs.

cool

ha bah si c'est le pic instantané effectivement jdisait ca car jme suis deja fait avoir par des moyennes de monitoring, alors qu'en pointe le truc perdait bel et bien des paquets

cet effet de bord est sympa, le probleme est que les hosteurs d'origine vont voir un nom de domaine en "*rehost*" plutot explicite et vont crier a l'institutionalisation du crime
pour que l'antiantileech marche, c'est que tu presentes pas de referer a la recuperation c'est ca ?

Yep, pas de referer, c'est un get direct. Eventuellement si ça commence à poser des problèmes je pourrais l'ajouter et ils feraient leur vie comme ça... Mais bon vu qu'autant que possible on cache l'image, les "dégats" sont limités, hormis pour le pbm de l'image trop grosse.

C'est pas des problèmes habituels le fonctionnement de rehost

Ah aussi, http://reho.st marche aussi, comme http://hfr-rehost.net à présent (pour les feignasses)