Je ne saurais te conseiller d'avoir des env de staging et de prod identiques... Pour tester nginx / unicorn, les vms sont parfaites pour ce genre de tests (si tu as le temps).
Avoir la prod ET le staging sur le même serveur me parait "dangereux". Encore une fois, la virtualisation peut être une bonne solution pour utiliser une seule machine physique. Si tu veux "robustifier" ton application, jette un oeil sur postgresql éventuellement. Fais la chasse aux requetes sql pourries ou aux endroits ou on peut remplacer du ruby par du sql (sort / aggrégations ....), si tu restes sur mysql, évite les OR (qui n'utilisent pas les index) et remplace les la ou tu peux pas des IN ou force l'utilisation des index. Si tu restes sur mysql et que tu as du STI, change tes champs types (string) en enums. N'hésite pas à utiliser du memoize partout ou c'est utile (sur les taches longues), n'hésite pas non plus à utiliser du cache pour tes pages / fragments... Bref, y'a des milliards de choses à faire pour le scaling et des milliards de facon différentes d'y arriver. Tout dépend du contexte, des moyens, du temps, de la facon dont a été codé le projet. Difficile d'être très précis sans voir le code =). Cordialement. Le 5 juillet 2012 18:38, Louis Davin <[email protected]> a écrit : > Bonjour, > > Travaillant depuis peu dans une startup éditant une plateforme web > tournant évidemment sur RoR, je suis chargé de mettre en place > l'environnement de production et de "robustifier" l'application. > J'ai d'ailleurs entamé le bouquin "Deploying Rails" de pragprog… > La mise en production se fera en beta privée, avec environ 200 > utilisateurs. > > La boite dispose déjà d'un VPS sur lequel tourne l'environnement de > staging. > Pour le moment il est prévu de faire aussi tourner l'environnement de > production sur le même serveur (j'imagine que ce n'est pas idéal, mais > est-ce une économie qu'il faut arrêter d'envisager tout de suite?). > > Le VPS tourne sous un ubuntu, j'hérite donc d'un stack MySQL, > Apache/Passenger, et Sphinx. Le déploiement de l'appli se fait par > capistrano. > (Déjà, il y a-t-il des remarques quand au combo apache/passenger? Que > vaut-il face à nginx/unicorn? A ce stade, changer de l'un vers l'autre > est-il intéressant?) > > Pour l'instant mon plan de bataille se résume ainsi: > > D'un point de vue serveur / monitoring: > - Installer le service et la gem de New Relic pour monitorer l'appli ainsi > que le serveur. > - Utiliser Papertrail pour agréger tous les logs du serveur et de l'appli > rails. > - Rester avec exception_notification (mails) ou passer sur Airbrake pour > traquer les exceptions. > > D'un point de vue rails: > - J'ai achevé la transition de l'appli pour utiliser l'assets pipeline. > (Les assets sont précompilées au déploiement par capistrano) > - Migrer les assets sur Amazon S3 (réglage de l'host-name et utilisation > de la gem "asset_sync" pour les assets statiques, et utilisation de la gem > "fog" pour les uploads par carrierwave) > - Mettre en background les tâches longues (notamment les mails, y en > a-t'il d'autres à migrer direct?) avec "delayed_job" > - Passer par SendGrid pour les mails envoyés par l'application. > > Avez-vous des remarques, des suggestions ? > Y-a-t'il quelquechose qui vous tracasse concernant les choix (provisoires > bien sur!) de gems ou de services ? > Ai-je oublié des points importants ? > > Merci beaucoup! > Bonne soirée > > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de > Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse > [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected]
