Python CMS pour créer un site de vidéos comme youtube?

Django est une bonne Python-Cadre, ainsi que CherryPy et Les pylônes. Toutefois, un cadre n'est pas un CMS.

Une vidéo open source CMS serait: Les Médias De Base

Voici quelques informations sur la façon de YouTube est de construire:

(source: Google Vidéo)

Plate-forme:

1. Apache
2. Python
3. Linux (SuSe)
4. MySQL
5. psyco, une dynamique python->le compilateur C
6. lighttpd pour la vidéo à la place d'Apache

Serveurs web:

1. NetScalar est utilisé pour l'équilibrage de la charge et de la mise en cache du contenu statique.
2. Exécuter Apache avec mod_fast_cgi.
3. Les requêtes sont dirigées pour un traitement par une application en Python serveur.
4. Serveur d'Application des pourparlers à diverses bases de données et autres sources d'informations afin d'obtenir toutes les données et les formats de la page html.
5. Pouvez généralement à l'échelle de la couche web par l'ajout de plus de machines.
6. Le web en Python code est généralement PAS le goulot d'étranglement, il passe la plupart de son temps bloqué sur Rpc.
7. Python permet rapide flexible de développement et de déploiement. Ceci est important en raison de la concurrence à laquelle ils sont confrontés.
8. Généralement moins de 100 ms page les délais de service.
9. Utilisation psyco, une dynamique python->le compilateur C qui utilise un compilateur JIT approche pour optimiser les boucles internes.
10. Pour la haute CPU intensive des activités telles que le chiffrement, ils utilisent des extensions C.
11. Certains pré-généré le cache HTML pour cher pour le rendu des blocs.
12. Ligne de niveau de la mise en cache dans la base de données.
13. Entièrement formé Python objets sont mis en cache.
14. Certaines données sont calculées et envoyées à chaque application, de sorte que les valeurs sont mises en cache dans la mémoire locale. C'est un sous-utilisées de la stratégie. La manière la plus rapide de la cache de votre serveur d'application, et il ne prend pas beaucoup de temps pour envoyer des données précalculées pour l'ensemble de vos serveurs. Juste un agent de montres pour les changements, precalculates, et l'envoie.

Vidéo portion:

1. Coûts comprennent les coûts de la bande passante, le matériel, et la consommation d'énergie.

2. Chaque vidéo est hébergée par un mini-cluster. Chaque vidéo est desservie par plus d'une machine.

3. À l'aide d'un un cluster signifie:

   • Plus de disques servant de contenu qui signifie plus de vitesse.
   • De la marge. Si un ordinateur tombe en panne les autres peuvent prendre le relais.
   • Il y a des sauvegardes en ligne.

4. Serveurs utilisent le serveur web lighttpd pour la vidéo:

   • Apache avait trop de frais généraux.
   • Utilise epoll attendre sur plusieurs fds.
   • De commutation de processus unique à de multiples processus de configuration pour gérer plusieurs connexions.

5. Contenu le plus populaire est déplacé vers un CDN (content delivery network):

   • Cdn répliquer le contenu en plusieurs endroits. Il y a une meilleure chance de contenu, plus près de l'utilisateur, avec moins de houblon, et le contenu sera exécuté sur une réseau amical.
   • CDN machines principalement servir de mémoire parce que le contenu est si populaire il y a une petite dérouillée de contenu en mémoire.

6. Moins de contenu populaire (1-20 vues par jour) utilise les serveurs YouTube en divers colo sites.

   • Il y a une longue queue d'effet. Une vidéo a peut-être quelques pièces de théâtre, mais beaucoup de vidéos sont en cours de lecture. Aléatoire des disques blocs sont en cours d'accès.
   • La mise en cache ne fait pas beaucoup de bon dans ce scénario, donc dépenser de l'argent sur plus de cache ne peut faire sens. C'est un point très intéressant. Si vous avez une longue queue de produits de mise en cache ne sera pas toujours vos performances sauveur.
   • Tune contrôleur RAID et de prêter attention à d'autres de niveau inférieur questions pour vous aider.
   • Tune mémoire, sur chaque machine, alors il n'y a pas trop et pas trop peu.

Siégeant En Vidéo Les Principaux Points Suivants:

1. Rester simple et bon marché.
2. Garder un simple chemin d'accès réseau. Pas trop de périphériques entre le contenu et les utilisateurs. Les routeurs, les commutateurs et les autres appareils peuvent ne pas être en mesure de suivre avec autant de charge.
3. Utilisation du matériel de base. Plus cher, le matériel devient le plus cher de tout le reste devient trop (contrats de support). Vous êtes également moins susceptibles de trouver de l'aide sur le net.
4. À l'aide de simples outils communs. Ils utilisent la plupart des outils de construire en Linux, et la couche sur le dessus de ceux-ci.
5. Poignée aléatoire cherche bien (SATA, réglages).

Servir Vignettes:

1. Étonnamment difficile de le faire efficacement.
2. Il y a 4 vignettes pour chaque vidéo il y a donc beaucoup plus de vignettes de vidéos.
3. Les vignettes sont hébergés sur un petit nombre de machines.
4. Vu les problèmes associés à servir un grand nombre de petits objets:
   • Beaucoup de recherches disque et des problèmes avec l'inode de caches et de la page des caches au niveau de l'OS.
   • Couru dans chaque répertoire limite de fichier. Ext3 en particulier. Rapprochés de la structure hiérarchique. Les améliorations récentes dans le noyau 2.6 peut améliorer Ext3 grand répertoire de la manipulation jusqu'à 100 fois, encore stocker beaucoup de fichiers dans un fichier système n'est toujours pas une bonne idée.
   • Un nombre élevé de requêtes/s comme les pages web peuvent afficher 60 vignettes sur la page.
   • En vertu de telles charges élevées Apache effectuée mal.
   • Utilisé squid (proxy inverse) en face de Apache. Cela a fonctionné pendant un certain temps, mais que la charge a augmenté de performance éventuellement diminué. Est passé de 300 requêtes/seconde à 20.
   • Essayé d'utiliser lighttpd, mais avec un seul thread, il a décroché. Courir dans des problèmes avec multiprocesses mode parce qu'ils tiennent un cache distinct.
   • Avec autant d'images de la configuration d'une nouvelle machine a fallu plus de 24 heures.
   • Le redémarrage de la machine a pris 6 à 10 heures pour le cache à chaud jusqu'à ne pas aller sur le disque.
5. Pour résoudre tous leurs problèmes, ils ont commencé à l'aide de BigTable de Google, un distribué magasin de données:
   • Évite petit problème de fichier, car il touffes fichiers ensemble.
   • Rapide, à tolérance de pannes. Assume son travail sur un réseau non fiable.
   • Latence plus faible, car il utilise un système distribué plusieurs niveaux de cache. Ce cache fonctionne à travers les différents collocation sites.

Bases de données:

1. Le Début Des Années
   • Utiliser MySQL pour stocker les méta-données comme les utilisateurs, les tags et descriptions.
   • Servi données à partir d'un monolithique Volume RAID 10 avec 10 disques.
   • Vivant hors des cartes de crédit afin qu'ils matériel loué. Quand ils ont besoin de plus de matériel pour gérer la charge il a fallu quelques jours pour commander et vous faire livrer.
   • Ils sont allés à travers une évolution commune: un seul serveur, est allé à un maître unique avec plusieurs de lire des esclaves, puis partitionnée de la base de données, puis s'installe sur une fragmentation de l'approche.
   • Souffert de la réplique de retard. Le maître est multi-thread et s'exécute sur une machine de grande taille de sorte qu'il peut gérer beaucoup de travail. Les esclaves sont mono-thread et l'habitude de courir sur la moindre des machines et la réplication asynchrone, les esclaves peuvent accusent beaucoup de retard le maître.
   • Les mises à jour de causer des défauts de cache qui va sur le disque où d'e/S lent provoque un ralentissement de la réplication.
   • À l'aide d'une réplication de l'architecture, vous devez dépenser beaucoup d'argent pour des bits de la performance d'écriture.
   • Un de leurs solutions de hiérarchiser le trafic par diviser les données en deux groupes: une vidéo montre piscine et d'un cluster. L'idée est que les gens veulent regarder la vidéo, de sorte que la fonction doit obtenir le plus de ressources. Les fonctionnalités de réseau social de YouTube sont moins importants, de sorte qu'ils peuvent être acheminés à un moins capable de cluster.
2. Années plus tard:
   • Suis allé à la base de données de partitionnement.
   • Divisé en éclats avec les utilisateurs affectés à des fragments différents.
   • Écarts de lit et écrit.
   • Beaucoup mieux la localité de cache ce qui signifie moins de IO.
   • Entraîné dans une 30% de matériel de réduction.
   • Réduit réplique de latence de 0.
   • Pouvez maintenant à l'échelle de la base de données presque arbitrairement.

Centre De Données De La Stratégie

1. Utilisé gérer les fournisseurs d'hébergement au premier abord. Vivre à crédit alors que c'était la seule façon.
2. De gestion d'hébergement ne peut évoluer avec vous. Vous ne pouvez pas contrôler le matériel ou de le rendre favorable de la mise en réseau des accords.
3. Alors ils sont allés à une colocation arrangement. Maintenant, ils peuvent personnaliser tout et la négociation de leurs contrats.
4. L'utilisation de 5 ou 6 centres de données en plus de la CDN.
5. Vidéos proviennent de tout centre de données. Pas plus proche ou quoi que ce soit. Si une vidéo est assez populaire, il se déplace dans le CAN.
6. Dépendant de la largeur de bande vidéo, pas vraiment le temps de latence dépend. Peut venir d'une colo.
7. Pour les images de latence important, surtout quand vous avez 60 images sur une page.
8. Images sont répliquées vers les différents centres de données à l'aide de BigTable. Le Code prend en compte différents paramètres pour savoir qui est le plus proche.

OriginalL'auteur Wouter Dorgelo

Vous pourriez tak ea regarder zencoder pour l'encodage vidéo.....

OriginalL'auteur Ben Hughes

Même si n'est pas un CMS, Django pourrait être très utile.

OriginalL'auteur Jorge Guberte