humm ... comment a tu fait tes tests ?
avec quel injecteur ??
qu'est-ce qu'un UTILISATEUR pour ton injecteur ?
parce que simuler ne serai-ce que 1000 requetes simultanées c'est pas une chose aisée ... il faut plusieurs machines en parallèle ...
de plus 1 requete != 1 utilisateur:
sur une page web souvent il y a des images ... donc plusieurs requetes HTTP.
quand il y a des saisies, un utilisateur qui par pisser au milieu d'un écran de saisie ca peut bloquer sa session du cote du serveur ... et quand tu as 1000 utilisateurs simultanés, tu peux avoir beaucoup de sessions en attente ...
bref prenons des pincettes pour manipuler ces chiffres.
Bon je rebondis de suite sur cette phrase: Java c'est lourd,c'est lent, ....
Je ne suis pas un trolleur fou et je vais donc argumenter.
Java est une solution technique (c'est pas seulement un language) forcement lourde puisque le code généré n'est pas adapté au CPU mais à une machine virtuelle [quand on a pas un cpu JAVA]. Ca ressemble à executer du code pour x86 sur un macIntosh dans un emulateur.
Les fanatiques de JAVA vont dire que ca marche quand meme et ils auront raison. Mais le même programme compilé pour l'architecture cible et écrit correctement sera forcement moins gourmand en ressources CPU/RAM/... et donc potentiellement plus rapide puique seul l'algo utile tournera.
Ensuite les mêmes fanatiques de JAVA nous reparleront des tests qui ont montré un code JAVA tourner aussi vite que son homologue en C, mais ils oublieront que cela depend de la charge de la machine, que en JAVA sur beaucoup de plateformes c'est la JVM qui gère le scheduling des threads JAVA [et elle est moins douée que le scheduleur de l'OS, ca peut même bloquer tous les threads JAVA sur un seul CPU !!] et enfin que dans le cadre de ces tests, le code JAVA avait été soigné [de vous à moi, entre un développeur C et un développeur JAVA, lequel des deux risque de mieux soigner son algo ? celui qui ne se pose même pas la question de libérer la mémoire et espère le passage d'un garbage collector à un moment ou son appli n'aura pas besoin de trop de CPU ??]
Je ne suis pas un fanatique de JAVA, mais je vois bien les avantages des solutions JAVA quand même:
Un seul package qui s'installe sur toutes les plateformes. C'est le seul avantage mais il est de taille pour tous ceux qui ont déjà VRAIMENT produit du logiciel, cela supprime des hommes/mois de boulot de packaging, tests ...
Ce package multiplateforme est donc tout indiqué pour le web ou l'architecture du client est inconnue (applets). Pour les servlets ca se discute plus, mais ca fait le bonheur des vendeurs de serveurs ... et des developpeurs. Si JAVA est plutot une solution d'architecture, il a su séduire beaucoup de développeurs en tant que langage. Du coup il y a souvent confusion ...
Il y a aussi un autre phénomène qui entre en jeu:
Les entreprises ne sont pas encore habituées à l'idée des logiciels libres et/ou gratuits. La maintenance réalisée par la communautée les intrigue (dépasse ?). Les décideurs en place aujourd'hui ont souvent trop baigné dans l'univers commercial des logiciels (ca risque de changer petit à petit ...)
Tout ca pour dire que convaincre son employeur d'installer un BSD ou Linux comme serveur d'impression c'est facile. Lui prouver que les performances en tant que serveur HTTP sont la c'est faisable avec un test ... mais démontrer la pertinance de la solution en termes de sécurité c'est quasiment impossible. Le décideur à esprit ouvert qui aura intégré Linux dans son entreprise ne PEUT PAS se permettre de mettre OpenSSH ou Netfilter pour assurer la sécurité ...
Attendons encore 5/10 ans. Les décideurs seront des gens plus familiers des logiciels libres et le mouvement fera son chemin. Les logiciels propriétaires seront alors obligé d'assurer la qualité en plus des fonctionnalités pour supporter la comparaison.
Ta préparation etait nickel, je reviens sur mon avis de tout à l'heure :-))
Par contre je ne comprends pas ton probleme pour les joindre puisque tu avais un mec au bout du fil lors de la modification ?
Quand aux tarifs, à mon avis ils se sont tous mis d'accord :-) c'est le même partout quoi.
qui va tu consulter ? ATT, Oleane, Colt, ...
Il faut aussi garder à l'esprit que ca arrive de se planter... En ce moment, la plupart des mecs sur site sont surement des back-up à cause des congés ... Tu devrais surtout mettre en avant la pub qu'ils sont en train de se faire sur ton site frequenté principalement par des informaticiens ... clients potentiels, consultants, techniciens !! pas bon pour eux ca !!
Bonne chance en tout cas. Une journée sans linuxfr c'etait long :-) [et pourtant je consulte avec un lien UUNET ... ca devrait rouleze c'est quasi de l'intranet :-)]
Cet anonyme à bien parlé...
aviez vous reduit le TTL de vos enregistrements DNS pour que les caches s'adaptent plus vite ?
ne pouviez vous pas garder la meme IP en doublon sur votre DNS primaire le temps du switch ?
ne pouviez vous pas demander une seconde plage d'adresse IP au lieu de changer d'adresses juste pour en avoir plus ?
Avez vous fait le changement avec un technicien de UUNET en ligne ?
Quand je fais des modifs avec UUNET et ATT, je decris les operations dans un doc par mail et je leur donne RV au telephone pour que les manips soient faites en meme temps de leur coté et du mien ...
Ces boites (UUNET, ATT, ...) ne font rien qui ne soit pas explicitement demandé par le client. Si vous ne leurs soufflez pas des idées, ils ne proposeront rien ...
PLuG qui pense que UUNET a bien merdé, mais que l'opération aurait pu être mieux préparée...
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par PLuG . En réponse à la dépêche Comparatif jsp/php. Évalué à 1.
avec quel injecteur ??
qu'est-ce qu'un UTILISATEUR pour ton injecteur ?
parce que simuler ne serai-ce que 1000 requetes simultanées c'est pas une chose aisée ... il faut plusieurs machines en parallèle ...
de plus 1 requete != 1 utilisateur:
sur une page web souvent il y a des images ... donc plusieurs requetes HTTP.
quand il y a des saisies, un utilisateur qui par pisser au milieu d'un écran de saisie ca peut bloquer sa session du cote du serveur ... et quand tu as 1000 utilisateurs simultanés, tu peux avoir beaucoup de sessions en attente ...
bref prenons des pincettes pour manipuler ces chiffres.
PLuG
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par PLuG . En réponse à la dépêche Comparatif jsp/php. Évalué à 1.
Java c'est lourd,c'est lent, ....
Je ne suis pas un trolleur fou et je vais donc argumenter.
Java est une solution technique (c'est pas seulement un language) forcement lourde puisque le code généré n'est pas adapté au CPU mais à une machine virtuelle [quand on a pas un cpu JAVA]. Ca ressemble à executer du code pour x86 sur un macIntosh dans un emulateur.
Les fanatiques de JAVA vont dire que ca marche quand meme et ils auront raison. Mais le même programme compilé pour l'architecture cible et écrit correctement sera forcement moins gourmand en ressources CPU/RAM/... et donc potentiellement plus rapide puique seul l'algo utile tournera.
Ensuite les mêmes fanatiques de JAVA nous reparleront des tests qui ont montré un code JAVA tourner aussi vite que son homologue en C, mais ils oublieront que cela depend de la charge de la machine, que en JAVA sur beaucoup de plateformes c'est la JVM qui gère le scheduling des threads JAVA [et elle est moins douée que le scheduleur de l'OS, ca peut même bloquer tous les threads JAVA sur un seul CPU !!] et enfin que dans le cadre de ces tests, le code JAVA avait été soigné [de vous à moi, entre un développeur C et un développeur JAVA, lequel des deux risque de mieux soigner son algo ? celui qui ne se pose même pas la question de libérer la mémoire et espère le passage d'un garbage collector à un moment ou son appli n'aura pas besoin de trop de CPU ??]
Je ne suis pas un fanatique de JAVA, mais je vois bien les avantages des solutions JAVA quand même:
Un seul package qui s'installe sur toutes les plateformes. C'est le seul avantage mais il est de taille pour tous ceux qui ont déjà VRAIMENT produit du logiciel, cela supprime des hommes/mois de boulot de packaging, tests ...
Ce package multiplateforme est donc tout indiqué pour le web ou l'architecture du client est inconnue (applets). Pour les servlets ca se discute plus, mais ca fait le bonheur des vendeurs de serveurs ... et des developpeurs. Si JAVA est plutot une solution d'architecture, il a su séduire beaucoup de développeurs en tant que langage. Du coup il y a souvent confusion ...
PLuG
[^] # Re: La raison est simple
Posté par PLuG . En réponse à la dépêche Trou dans SSH 3.0.0. Évalué à 2.
Les entreprises ne sont pas encore habituées à l'idée des logiciels libres et/ou gratuits. La maintenance réalisée par la communautée les intrigue (dépasse ?). Les décideurs en place aujourd'hui ont souvent trop baigné dans l'univers commercial des logiciels (ca risque de changer petit à petit ...)
Tout ca pour dire que convaincre son employeur d'installer un BSD ou Linux comme serveur d'impression c'est facile. Lui prouver que les performances en tant que serveur HTTP sont la c'est faisable avec un test ... mais démontrer la pertinance de la solution en termes de sécurité c'est quasiment impossible. Le décideur à esprit ouvert qui aura intégré Linux dans son entreprise ne PEUT PAS se permettre de mettre OpenSSH ou Netfilter pour assurer la sécurité ...
Attendons encore 5/10 ans. Les décideurs seront des gens plus familiers des logiciels libres et le mouvement fera son chemin. Les logiciels propriétaires seront alors obligé d'assurer la qualité en plus des fonctionnalités pour supporter la comparaison.
PLuG
[^] # Re: Methodologie
Posté par PLuG . En réponse à la dépêche UUNet (update). Évalué à 1.
Par contre je ne comprends pas ton probleme pour les joindre puisque tu avais un mec au bout du fil lors de la modification ?
Quand aux tarifs, à mon avis ils se sont tous mis d'accord :-) c'est le même partout quoi.
qui va tu consulter ? ATT, Oleane, Colt, ...
Il faut aussi garder à l'esprit que ca arrive de se planter... En ce moment, la plupart des mecs sur site sont surement des back-up à cause des congés ... Tu devrais surtout mettre en avant la pub qu'ils sont en train de se faire sur ton site frequenté principalement par des informaticiens ... clients potentiels, consultants, techniciens !! pas bon pour eux ca !!
Bonne chance en tout cas. Une journée sans linuxfr c'etait long :-) [et pourtant je consulte avec un lien UUNET ... ca devrait rouleze c'est quasi de l'intranet :-)]
[^] # Re: Methodologie
Posté par PLuG . En réponse à la dépêche UUNet (update). Évalué à 1.
aviez vous reduit le TTL de vos enregistrements DNS pour que les caches s'adaptent plus vite ?
ne pouviez vous pas garder la meme IP en doublon sur votre DNS primaire le temps du switch ?
ne pouviez vous pas demander une seconde plage d'adresse IP au lieu de changer d'adresses juste pour en avoir plus ?
Avez vous fait le changement avec un technicien de UUNET en ligne ?
Quand je fais des modifs avec UUNET et ATT, je decris les operations dans un doc par mail et je leur donne RV au telephone pour que les manips soient faites en meme temps de leur coté et du mien ...
Ces boites (UUNET, ATT, ...) ne font rien qui ne soit pas explicitement demandé par le client. Si vous ne leurs soufflez pas des idées, ils ne proposeront rien ...
PLuG qui pense que UUNET a bien merdé, mais que l'opération aurait pu être mieux préparée...
[^] # Re: Le Boycott du rire
Posté par PLuG . En réponse à la dépêche Boycott Adobe... un air de déja vu ?. Évalué à 1.