Dans quelle mesure Parse est-il évolutif?
J'ai envisagé d'utiliser le service Parse.com pour mon backend, mais je suis sceptique quant à son évolutivité.
Peut-il vraiment gérer plusieurs milliers d'utilisateurs simultanés? Sinon, est-ce que leur bon moyen s'en éloigne?
Je sais que la question est peut-être ancienne, mais je voulais fournir mes 2 cents pour les autres qui envisagent d'analyser ...
Dans le plus simple des scénarios, l'analyse peut bien fonctionner. Dès que vous devez évoluer vers des requêtes plus complexes, je n'ai personnellement trouvé que des maux de tête.
Les requêtes sont limitées à 1 000 enregistrements. Au début, vous pensez peut-être que ce n'est pas un problème, jusqu'à ce que vous commenciez à traiter les sous-requêtes et que vous réalisiez que des données étranges sont renvoyées car la sous-requête coupe les enregistrements sans avertissement ni erreur. (Pour info, la valeur par défaut est 100 enregistrements sauf si vous spécifiez une limite jusqu'à 1000, donc le problème est encore pire si vous ne faites pas attention).
Pour une raison étrange, il y a une limite au nombre de fois que vous pouvez émettre une requête de comptage en une minute. (et cette limite semble être vraiment basse). Soyez prêt à essayer de limiter votre code afin de ne pas atteindre cette limite, sinon des erreurs sont levées.
Contexte Les travaux ne s'exécutent pas de manière fiable. Un travail d'arrière-plan a été défini pour s'exécuter toutes les 5 minutes, et il faut parfois plus de 20 minutes avant que le travail ne démarre.
Beaucoup de délais d'attente. C'est celui qui me donne le plus de brûlures d'estomac. R. Si vous avez une fonction cloud qui prend du temps à traiter, vous avez environ 6 ou 7 secondes pour le faire ou cela vous coupera.
B. J'ai l'impression qu'il y a une instabilité générale avec le système. Périodiquement, je rencontre des problèmes qui semblent durer environ une heure environ, où les délais d'attente se produisent plus fréquemment (et avec des fonctions relativement simples qui devraient revenir immédiatement).
Je regrette profondément ma décision d'utiliser l'analyse, et je fais tout ce que je peux pour maintenir l'application en vie assez longtemps pour que nous puissions obtenir un financement, afin que nous puissions quitter la plate-forme. Si quelqu'un a de meilleures alternatives à analyser, je suis tous à l'écoute.
[Edit: après trois années incroyables avec l'équipe, j'ai décidé de passer à autre chose et je ne suis plus un employé Parse ou Facebook. L'équipe est entre de bonnes mains et a fait des choses incroyables. L'ensemble du backend a été réécrit pour augmenter considérablement les performances et la fiabilité. La feuille de route est incroyable et j'attends de grandes choses de la part de l'équipe. Au moment de mon départ, Parse a généré plus de 600 000 applications et a répondu chaque jour à un nombre ahurissant de demandes. Si chaque Parse Push devait être envoyé à une personne unique, ils pourraient former le quatrième plus grand pays du monde en une journée. Pour une aide future avec Parse, veuillez publier vos questions ici avec la balise parse.com ou les envoyer au groupe Google de parse-developers.]
Divulgation complète: je suis ingénieur Parse.
Parse héberge déjà des milliers d'applications , sans parler des utilisateurs. Lorsque nous avons quitté la version bêta fin mars, nous annoncé plus de 10 000 applications fonctionnant sur Parse avec un taux de croissance de 40% d'un mois à l'autre. Parse est doté d'une équipe de classe mondiale, dont beaucoup ont des années d'expérience dans les mégadonnées et le trafic à volume élevé.
Nous accueillons votre trafic à bras ouverts; vous serez en compagnie de grandes équipes comme Band of the Day et Hipmunk . Nous sommes tellement confiants dans nos services que nous avons construit notre système One Click Export pour que des gens comme vous puissent essayer Parse sans risque. Si vous pensez que Parse ne répond pas à vos attentes en matière de performances, nous vous enverrons volontiers toutes vos données intactes.
Nous avons choisi Parse comme backend pour notre application. Conclusion: NE PAS.
La stabilité est un désastre, les performances sont un désastre aussi, tout comme le support (probablement parce qu'ils ne peuvent pas vraiment vous aider car tous les problèmes ne sont pas reproductibles).
L'exécution même des fonctions les plus simples peut entraîner des délais d'attente aléatoires à l'intérieur de Parse (je parle par exemple d'appels de connexion PFUser simples):
Error: Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo=0x17e42480 {NSErrorFailingURLStringKey=https://api.parse.com/2/client_events, NSErrorFailingURLKey=https://api.parse.com/2/client_events, NSLocalizedDescription=The request timed out., NSUnderlyingError=0x17d10e60 "The request timed out."} (Code: 100, Version: 1.2.20)
Nous rencontrons quotidiennement des délais d'attente, et c'est avec une application que nous testons avec 10 utilisateurs maximum!
C'est le type que nous récupérons tout le temps, à des moments complètement arbitraires et impossibles à reproduire. Appeler une fonction Cloud Code qui fait quelques requêtes et quelques insertions:
{"code":124,"message":"Request timed out"}
Essayez la même chose 10 minutes plus tard et cela fonctionnera en moins d'une seconde. Réessayez 20 minutes plus tard et l'exécution prend 30 secondes.
Parce qu'il n'y a pas de transactionnalité, c'est vraiment très amusant de stocker par exemple 3 objets dans 1 fonction Cloud Code, où Parse décide de sortir de la fonction au hasard après, disons, avoir enregistré 2 des 3 objets. Idéal pour garder votre base de données cohérente.
Les "meilleurs" que nous ayons eu là-bas. Attention, ce sont les données réelles provenant d'une fonction Cloud Code:
{"code":107,"message":"Received an error with invalid JSON from Parse: <!DOCTYPE html>\n<html>\n<head>\n <title>We're sorry, but something went wrong (500)</title>\n <style type=\"text/css\">\n body { background-color: #fff; color: #666; text-align: center; font-family: arial, sans-serif; }\n div.dialog {\n width: 25em;\n padding: 0 4em;\n margin: 4em auto 0 auto;\n border: 1px solid #ccc;\n border-right-color: #999;\n border-bottom-color: #999;\n }\n h1 { font-size: 100%; color: #f00; line-height: 1.5em; }\n </style>\n</head>\n\n<body>\n <!-- This file lives in public/500.html -->\n <div class=\"dialog\">\n <h1>We're sorry, but something went wrong.</h1>\n <p>We've been notified about this issue and we'll take a look at it shortly.</p>\n </div>\n</body>\n</html>\n"}
Ce que je décris ici n'est pas quelque chose qui se produit une fois dans une lune bleue dans notre projet. À l'exception des 500 erreurs (que j'ai rencontrées deux fois en un mois), toutes les autres sont vues quotidiennement.
Alors oui, il est très facile de commencer, mais vous devez tenir compte du fait que vous travaillez sur une plate-forme instable, alors assurez-vous que vos tentatives et vos systèmes de suppression exponentielle sont opérationnels, car vous en aurez besoin!
Ce qui m'inquiète le plus, c'est que je n'ai aucune idée de ce qui se passerait lorsque 20 000 personnes commenceraient à utiliser mon application sur ce backend.
éditer:
En ce moment, je l'ai quand je fais une connexion PFUser:
Error: Error Domain=PF_AFNetworkingErrorDomain Code=-1011 "Expected status code in (200-299), got 502" UserInfo=0x165ec090 {NSLocalizedRecoverySuggestion=<html><body><h1>502 Bad Gateway</h1>
The server returned an invalid or incomplete response.
</body></html>
, PF_AFNetworkingOperationFailingURLResponseErrorKey=<NSHTTPURLResponse: 0x16615c10> { URL: https://api.parse.com/2/get } { status code: 502, headers {
"Cache-Control" = "no-cache";
Connection = "keep-alive";
"Content-Length" = 107;
"Content-Type" = "text/html; charset=utf-8";
Date = "Mon, 08 Sep 2014 13:16:46 GMT";
Server = "nginx/1.6.0";
} }, NSErrorFailingURLKey=https://api.parse.com/2/get, NSLocalizedDescription=Expected status code in (200-299), got 502, PF_AFNetworkingOperationFailingURLRequestErrorKey=<NSMutableURLRequest: 0x166f68b0> { URL: https://api.parse.com/2/get }} (Code: 100, Version: 1.2.20)
N'est-ce pas génial?
Si vous écrivez une petite/simple application (ou un prototype jetable) avec peu ou pas de logique sur le backend, allez-y, mais pour quelque chose de plus grand/évolutif, il vaut mieux l'éviter, je peux le dire par expérience de première main. Tout cela sonne bien avec leur gestion des utilisateurs, les notifications Push, le stockage abstrait et ce qui ne l'est pas, mais en fin de compte, cela ne vaut pas la peine. À savoir que je développais le backend pour une application sur Parse, les clients étaient tellement dedans parce que cela avait l'air cool et prometteur (marketing fort je suppose), étant acheté par Facebook et quoi d'autre, mais quelques semaines après la production, problèmes/limitations majeurs avec la plate-forme a commencé à apparaître, ce qui devrait être une simple application s'est avéré être un cauchemar à développer et à faire évoluer.
Le résultat/conclusion du projet: - a cassé la fenêtre de temps pour une application relativement simple - elle aurait dû durer 2-3 mois, elle a duré presque un an et n'est toujours pas stable/fiable, si nous utilisions une pile personnalisée, elle ' d être fait à l'intérieur de la fenêtre de temps pour sûr parce que j'ai fait un projet de démonstration similaire en 5-10 jours avec une pile de nœuds personnalisée - a perdu la confiance du client, ils sont en train de refaire l'application avec une autre équipe qui utilisera une pile personnalisée - perdu beaucoup d'argent pour avoir brisé la fenêtre de temps et essayé de le faire fonctionner - a fait tellement d'heures supplémentaires à cause de cela qu'il a commencé à réfléchir sur ma santé - n'utilisant jamais une plate-forme/solution qui promet de tout avoir, toujours avec une coutume/pile essayée
Premièrement, les problèmes de stabilité et les défaillances constantes de la plate-forme, comme les temps d'arrêt du serveur et les erreurs aléatoires, mais ils ont tout réglé (c'était au début de la mi-2014), mais les problèmes suivants demeurent:
- vous ne pouvez pas déboguer votre code, du moins pour le moment (il existe des moyens de le faire fonctionner avec un serveur de nœud supplémentaire et une bibliothèque obscure)
- les limites sont ridicules, une plate-forme évolutive qui peut faire 50 à 60 demandes d'API par seconde (ou plus selon votre abonnement), ce qui n'est pas aussi bas qu'il n'y paraît jusqu'à ce que vous commenciez à faire des tests de contrainte, et quand vous le frappez votre code échouera constamment
- Les appels API sont mesurés comme suit: appel d'une fonction serveur (travail d'analyse) - 1 appel, interrogation de la base de données - 1 appel, une autre requête (car ils n'ont pas de système de requête avancé/complexe en place, si vous avez un système plus complexe schéma de base de données, vous comprendrez très vite ce que je veux dire) - 1 appel, si vous avez besoin d'obtenir plus de 1000 requêtes devinez quoi - interroger à nouveau, etc., interroger pour compter (vous devez le faire comme une requête distincte) qui est peu fiable (a tendance à renvoyer une approximation pour quelques milliers d'entrées)
- créer/enregistrer ~ 1000 + objets simples est une pression sur la plate-forme/base de données, supprimer 1000 objets ou plus, encore plus, ce qui est ridiculement rapide pour les bases de données normales, mais sur Parse, cela prend généralement 5 à 10 minutes (si vous cochez il supprime de plus près 20 objets par lot)
- aucun moyen d'utiliser la plupart des packages npm (uniquement ceux JS purs en incluant directement la source)
- si vous allez lire les forums Parse, vous verrez les utilisateurs voter en bas/torréfier constamment l'équipe Parse pour le manque de fonctionnalités de la plate-forme et avoir besoin de sauter à travers des cerceaux pour une implémentation logique arbitraire comme la récupération d'entrées aléatoires et d'autres choses similaires
- ils prennent en charge l'intégration de Stripe, mais si vous souhaitez utiliser Paypal ou un autre service de paiement (nous avons décidé d'utiliser Paypal car il a un support pays largement supérieur à Stripe), vous ne pouvez pas le faire fonctionner sur Parse, pour l'intégration Paypal, je devais utiliser un serveur séparé pour le retirer
- pas de moyen facile de synchroniser les utilisateurs et de gérer les problèmes de simultanéité, vous devez utiliser des hacks et une logique amusante que vous n'utiliseriez ou n'admettriez jamais
- veulent 100+, encore moins 1000+ utilisateurs simultanés, bonne chance pour réussir
- lorsque vous voulez connaître le nombre d'entrées dans une table, vous pouvez atteindre la limite en appelant la requête de comptage qui est drôle, non documentée et totalement ridicule, et à la fin retourne un nombre approximatif
- la modularité est étrangère à la plate-forme, les fonctions que vous appelez à partir de vos travaux ne peuvent pas durer plus de quelques secondes (7 secondes je pense) et lorsque vous prenez en compte le temps de requête, cela se produira souvent avec des requêtes plus complexes et une logique complexe
- Vous pouvez avoir quelque chose comme des tâches Cron mais elles ne peuvent pas durer plus de 15 minutes (en raison des faibles performances de la plate-forme, comme plusieurs requêtes très, très courtes), elles sont limitées à 2-3-4 tâches simultanées en fonction de votre frais d'abonnement et avoir un système de planification très limité/médiocre en place (par exemple, vous ne pouvez pas le modifier à partir de votre code, il est très limité, vous devez donc utiliser des hacks pour exécuter le même travail à 2 heures précises pendant la journée ou quelque chose de similaire , il ne peut pas regarder pour gagner du temps, etc.)
- Lorsque vous obtenez une erreur sur le serveur, cela peut être totalement trompeur, consultez les forums pour cela, je ne me souviens de rien de ma tête
- Les notifications push sont régulièrement en retard de 20 à 30 minutes
Un exemple arbitraire: vous voulez récupérer un élément aléatoire de leur base de données, votre application appelle un travail qui le fournira (1 appel API), le travail interroge la base de données, mais vous devez faire 2 appels, d'abord pour obtenir le nombre d'éléments (1 appel API), puis un second pour obtenir un élément aléatoire (1 appel API), ce sont 3 appels API pour cette fonctionnalité, et avec 60 demandes par seconde, 20 utilisateurs peuvent effectuer cet appel à un certain temps avant d'atteindre la limite de demande et la plate-forme se détraquer, après avoir inclus d'autres utilisateurs parcourant les écrans d'application et d'autres choses, vous voyez où cela mène ...
Si c'était bon, Facebook ne l'aurait-il pas acheté à chaque mention en l'utilisant même pour certaines de leurs applications? Je suggérerais 3 choses: - d'abord - n'écoutez pas le gars de Parse, c'est sa plateforme donc il doit le promouvoir, écouter les gens qui l'ont utilisé pour faire quelque chose en l'utilisant
- deuxième - si vous avez besoin d'une plateforme sérieuse et évolutive et que vous ne voulez pas devenir entièrement personnalisé, optez pour les services Amazon Cloud ou quelque chose de similaire qui est testé et fiable - troisième - restez loin de la plateforme si vous en avez expérience côté serveur, si vous n'allez pas ensuite embaucher un développeur backend pour le projet, ce sera moins cher et vous obtiendrez une solution de travail à la fin
J'ai passé la journée à regarder parse.com et voici mon opinion actuelle basée sur ce que j'ai trouvé (veuillez garder à l'esprit que je n'ai qu'une très brève expérience de développement avec le SDK pour le moment).
Parse.com a clairement des points positifs très attractifs, c'est pourquoi je me suis retrouvé à le regarder, mais pour le débat, je vais me concentrer sur la critique car les grands points positifs sont tous répertoriés sur leur site Web. (Bravo parse.com pour avoir tenté de résoudre un si gros problème!) ...
- Dans les témoignages, Hipmunk est le plus grand nom que je dirais. Il est répertorié comme une application qui utilise la partie données du SDK. Sans approcher les développeurs Hipmunk, je ne peux pas être sûr mais je ne peux pas imaginer qu'ils stockent TOUTES leurs données dans le cloud parse.com.
- Après avoir essayé et parcouru la plupart des applications répertoriées. Aucun ne se démarque vraiment comme dépendant énormément d'un serveur principal, je trouve donc impossible de savoir si l'évolutivité a été résolue en utilisant parse.com sur la base de ceux-ci.
- Le site Web indique 40 000 applications et compte. Je pense (mais je ne sais pas) que sur la base de la galerie d'applications, ce chiffre est basé sur la quantité d'applications dans leur base d'utilisateurs, et non sur de vraies applications de production en direct dans les magasins d'applications. La galerie d'applications comporterait beaucoup plus de grands noms si autant d'applications utilisaient parse.com.
Parse.com est un tout nouveau concept, très différent même de ses plus proches concurrents. Donc, sans preuve concrète de son évolutivité et de sa stabilité (et de tout le reste), il est très difficile pour un développeur sur un projet d'envisager de s'y engager car il y a trop en jeu.
J'ai effectué des tests pour ma propre réponse à des questions similaires question et cela peut être TRÈS, TRÈS RAPIDE. Cependant, les résultats que vous obtenez peuvent dépendre des détails de votre implémentation ...
Test comparé Android SDK à Android utilisant la pile HTTP native pour effectuer des appels Parse/REST ...
Détails du test:
Environnement de test - la plus récente Android sur un téléphone âgé de 10 mois via une connexion WIFI rapide.
(téléchargez 63 photos où la taille de fichier moyenne = 80 Ko)
test 1 en utilisant le Android SDK RESULT = Ralentissement des performances
test 2 en utilisant REST appels sur Android RESULT = VERT FAST)
--EDIT-- car il y a un intérêt ici ....
En ce qui concerne http thruput, le SDK d'analyse (Android) et les performances, il se peut que parse.com n'ait pas optimisé les performances sur la façon dont ils implémentent Android asyncTask () dans le SDK parse.Android? Comment le travail qui a nécessité 8 minutes sur parse.sdk pourrait être fait en 3 secondes sur un REST, framework DIY optimisé (voir les liens pour plus de détails sur les implémentations), je ne sais vraiment pas. Si l'analyse n'a pas corrigé leur implémentation du SDK depuis l'exécution de ces tests de comparaison, alors vous ne voulez probablement pas que leur truc asnycTask du SDK par défaut fasse quoi que ce soit approchant une charge de travail réelle sur le réseau.
Le grand attrait de Parse (et des SaaS similaires) est que vous pouvez économiser des dizaines de milliers sur les coûts de développement back-end. Étant donné que le back-end est souvent l'aspect le plus cher d'une application Web; ce mal de tête est soudainement pouf.
Le problème avec Parse et la plupart (tous) SaaS est que la région, la puissance, la mémoire, la bande passante, l'évolutivité, les seuils, les alertes et diverses actions sont hors de votre contrôle.
Même chose avec Shopify. C'est un excellent Saas avec un contrôle complet sur les produits, les commandes, les stocks et l'esthétique - mais aucun contrôle sur la machine. Donc, le SaaS n'est pas vraiment différent de Godaddy. Ils surventent ou maximisent invariablement leurs machines pour gagner de l'argent; et vous êtes coincé si vous vous souciez vraiment du cul- vous ne pouvez même pas acheter ce niveau de service.
Je voudrais quelque chose AT MOINS aussi puissant et complet que la console AWS. La plupart des techniciens savent et acceptent que Heroku et Parse sont tous deux hébergés sur AWS. Peu importe. mais ne refusez pas l'accès à ces outils critiques de bas niveau qui rendent un site et une application et l'expérience utilisateur zing.
En tout cas, en réponse à la question:
L'API Parse est un simple JSON. Vous pouvez donc pomper les données dans le même format JSON qu'une application Parse attend.
Vous pourriez même être en mesure d'utiliser leur PFObject (iOS). À un moment donné, toute cette API de haut niveau va à une demande/réponse HTTP commune. La bonne chose à propos de la généralité de REST signifie un système standard; des choses comme http, url, chaînes et utf. Pas d'Orbe génial ici.
L'analyse est idéale pour commencer avec en particulier des fonctions/fonctionnalités d'assistance sur la gestion des utilisateurs. Mais j'ai commencé à rencontrer des problèmes ..
Longs temps d'exécution/ping, 1000 objets limite INCLUANT les sous-requêtes, pas de centres de données en Europe (pour autant que je sache)
Cela aurait été une plate-forme divine s'ils pouvaient trier les problèmes de performances et de stabilité. Je regrette en quelque sorte de l'avoir développé, mais j'ai mis plus de 5000 lignes de code, donc je vais m'en tenir.
Peut-être qu'ils devraient séparer leurs applications DEV et leurs environnements d'applications PROD, et n'autoriser les applications PROD qu'après une sorte de supervision, ou créer un environnement différent avec uniquement des clients payants?
Nous sommes en 2014, les serveurs à 20 $/mois peuvent gérer des sites Web non optimisés (60 requêtes de base de données non mises en cache sur la page d'accueil) avec 1 million de visites/mois, cela ne devrait pas être si difficile à venir sur Parse!
C'est ok pour prototyper les applications, surtout si le développeur iOS/Android ne sait pas comment construire lui-même un backend DB/API.
Ce n'est pas correct du tout, quand il s'agit de développer une application avec une logique qui nécessite des requêtes plus complexes que:
SELECT * FROM 'db' WHERE 'column' = 'value' LIMIT 100;
Les requêtes associées et les jointures internes n'existent pas sur Parse. Et bonne chance pour mettre à jour/supprimer 320 000 enregistrements si vous en avez besoin (c'est le nombre avec lequel je travaille maintenant).
La seule chose qui est vraiment utile est de gérer les utilisateurs via le SDK. Si je pouvais trouver un bon document ou même un tutoriel sur la façon de gérer/créer des utilisateurs via des applications iOS/Android en utilisant Django et DRF/Tastypie, je convertis instantanément tout ce qui est développé dans notre entreprise en Utiliser ça.