framework pour web service

hello,
j'ai une application web avec django qui tourne.
On veut maintenant ajouter des webservices pour aller poster ou recuperer des infos, tout ca bien sur sous https.
On ne veut pas mettre ce ws sur django, simplement pour réduire la charge sur le serveur.
On aura donc une machine spécifique au ws et traitement de données.

j'hesite donc la entre plusieurs solution : flask et pyramid, bottle me paraissant un peu limité quand la charge est trop énorme (taux d'erreurs croissants selon mes lectures) et Django etant AMA trop gros pour ce genre de service.

Une idée, suggestion ou retour d'XP ?

merci

Citation:

---

Envoyé par gorjuce

hello,
...
Une idée, suggestion ou retour d'XP ?

merci

---

Bonjour,

Voir ici:http://sametmax.com/utiliser-cherryp...amework-leger/

Prenez le temps de lire les commentaires de l'article. La solution présentée permet d'utiliser bottle servi par Cherrypy, dans les commentaires ils parlent aussi de twistted.

Bonne journée

Salut,

Quelle serait la charge attendue?
S'agit-il de Web services SOA ou REST?

Quelque part, le goulot d'étranglement sera plutôt côté entrées sorties disques: si vous voulez des "performances", il faudrait pouvoir:
- mettre ces données en cache ("mémoire" => beaucoup de RAM et un gestionnaire de cache (qui ne sera pas Python) à intégrer au service Web).
- gérer la cohérence entre les sessions et le cache,
- pouvoir avoir une distribution de la charge sur plusieurs cpu,

- W

merci phi65 pour le post, c'est trés instructif. Le probleme avec le web c'est qu'on trouve de tout concernant les avis et que bien souvent y'a un ou deux gars des devteam qui viennt dire que leur solution tabasse grave du poney.
Sur un post dont je retrouverai peut etre l'url plus tard, j'avais vu qu'il fallait plutot eviter cherrypy et utiliser gevent ou uwsgi, a voir donc :(

@wiztricks tu poses les bonnes questions :)
La charge, aucune idée pour le moment on est encore en phase R&D mai le projet se concretise et on peut esperer monter sur +10k connections (si dieu le veut :))
On essaie en parrallele de voir pour partir sur de l'asynchrone pour éviter de bloquer trop de ressources, mais dans le cas on à beacoup moins d'options.

Quand tu parles de gérer la cohérence entre les sessions et le cache tu veux dire quoi ?

Ca ne dit pas quel type de web service: rest peut être simple, SOA demandera "plus".

Citation:

---

Envoyé par gorjuce

Quand tu parles de gérer la cohérence entre les sessions et le cache tu veux dire quoi ?

---

Si un client modifie les données, il faudra que les autres clients puisse voir la modification (au bout d'un certain temps). Il faut écrire sur les disques (la base de donnée), mettre à jour le cache partagé et celui des autres sessions.

Côté dév, on fait rien (c'est compliqué: vaut mieux utiliser ce qui fonctionne et on a le choix) mais il faudra un framework(*) qui va intégrer ces différents niveaux de façon "cohérente".
(*) une intégration de bout en bout entre services http(s), session, cache, base de données. Le code de l'application (à écrire/développer) sera dans la boite "session".

10K connections est une indication sur le nombre de clients.
Mais l'intervalle de temps (par seconde, minute, heure) sera plus dimensionnant.

Il faudrait avoir aussi une idée des traitements correspondants: entre rien et balayer de grosses tables la charge ne sera pas la même sur la chaîne session/cache/bdd.
Et s'il faut ajouter des serveurs dans des couches pour améliorer les temps de réponses, tous les frameworks ne sont pas "égaux" côté flexibilité.
Il y a peut être aussi des questions de disponibilité et de tolérance au sinistre à intégrer.

Cela fait pas mal de sujets à intégrer dans le choix du framework.

- W

merci pour les indications.

C'est assez difficile de donner un ordre d'idée du nombre de user simultanés.

Pour faire simple on a pas un gros truc a pondre, globalement on va avoir :
- le.site.com/login/les-params-qui-vont-bien
- le.site.com/add/les-datas-a-ajouter-dans-un-nosql
- le.site.com/get/version-du-logiciel

C'est vraiment la un exemple de ce qu'on pourrait être amené a designer comme url, rien de fait, encore une fois on y reflechit.

Pour l'archi, on serait ptet plutot sur du rest, sans aucune certitude

Salut,

Citation:

---

Pour l'archi, on serait ptet plutot sur du rest, sans aucune certitude

---

C'est un point "structurant".

En fait ReST étant relativement simple, avec un framework qui se respecte sa mise en œuvre sera de la plomberie (quelques fichiers de scripts à éditer mais ce sera plutôt de la configuration que du code).

Le seul point délicat sera côté modèle de données (persistance).
Changer = remettre l'existant d'équerre.

Mais côté framework (a part les tests), c'est sans soucis.
=> démarrer avec celui qui vous convient le mieux, et changer plus tard si nécessaire est "jouable".

Bon courage,
- W

merci beaucoup pour tes réponses.

Effecivement pour les données, c'est un point crucial pour nous, avec deux types disctinct de données et d'utilisation :
- utilisation du model de nos Users definit dans notre application web, afin de gérer le login et les autorisations
- enregistrement des données sur du NoSQL

Donc oui c'est crucial pour nous, on va voir comment on va gérer ca.
merci