Journal Serveur web java .. Que choisir ?

Posté par  (site web personnel) .
Étiquettes : aucune
0
22
mai
2003
Je fais un projet JSP / Servlet et je ne sais pas du tout quoi choisir entre Resin, Tomcat, Jetty ...
Quelqu'un a des arguments en faveur / contre chaque serveur ?
(performance, stabilité, simplicité de conf, prix ...)
  • # Re: Serveur web java .. Que choisir ?

    Posté par  . Évalué à 2.

    J'ai aussi a faire en ce moment un projet JSP/Servlet.

    J'ai essayé Tomcat, mais je n'ai rien réussi à faire. J'ai également essayé JBoss, sans arriver a faire grand chose non plus... Tout ca est asser nouveau pour moi, même Java.

    J'ai finalement conservéé, JBoss, en combinaison avec un environnement Eclipse + le plugin Lomboz, qui permet à l'aide d'assistants et tout ca de créer et de déployer en 3 clics ton appli.

    Oui, je sais, c'est peut etre un clicodrome, mais ca marche alors ca me va.
  • # Re: Serveur web java .. Que choisir ?

    Posté par  . Évalué à 4.

    hum...je te conseille de partir sur tomcat (4.1), tout simplement car c'est l'implementation standard. De plus il est tres stable/robuste et encaisse bien la charge si tu le places pas en serveur web (faut le coller derriere un apache quoi ! )

    ensuite, et c'est le gros avantage des appli web java, tu n'es pas dependant du serveur...donc rien ne t'empeche de bencher un peu pour tester les autres...

    par exemple, tomcat est connu pour galerer un peu sur les tres fortes charges ponctuelles, alors que jetty encaisse mieux...du coup, pour cracher des tonnes de mail tres vite, vaut mieux jetty...
    • [^] # Re: Serveur web java .. Que choisir ?

      Posté par  (site web personnel) . Évalué à 2.

      Merci.

      En plus, je pense faire aussi un apache frontal vu que je vais faire un design "à la templeet" (cad pointer directement vers le cache et utiliser les erreurs 404.

      Maintenant faudra juste voir comment faire passer avec les ErrorDocument et les mod_rewrite.

      Tu as des docs pour ce genre de choses ? Des sites à conseiller ? etc.
      • [^] # Re: Serveur web java .. Que choisir ?

        Posté par  . Évalué à 2.

        moué :-/
        je pense que le concept de templeet s'adapte mal aux techno java.
        tu as deja de nombreuses possibilités pour avoir un site tres rapide !

        la mise en cache (memoire) (Context) de tout ce que tu veux. le fait d'ecrire des pages en dur est pas une bonne idée je pense. cette notion de page n'est pas tres adaptée a mon avis.

        enfin a voir, mais pas très facile a faire.

        par contre je te confirme, ne laisse pas tes moteurs de servlet en frontal...toujours derriere le apache tu mettras :-p
        • [^] # Re: Serveur web java .. Que choisir ?

          Posté par  (site web personnel) . Évalué à 1.

          la mise en cache (memoire) (Context) de tout ce que tu veux. le fait d'ecrire des pages en dur est pas une bonne idée je pense. cette notion de page n'est pas tres adaptée a mon avis.

          Si tu as de la doc là dessus je suis preneur
          Je ne connais probablement pas assez le terrain mais ce qui me fait peur c'est une utilisation abusive de java d'où l'idée de mettre un apache qui se servirait directement sur le disque dur.

          Néanmoins il est vrai que si cela se limite à des accès mémoires, cela ne devrait pas poser trop de problèmes.

          Pour le proxy apache comment cela se passe ?
          il utilise les header http (expires etc.) ?

          Je veux dire comment cela se passe si la page est réellement modifiée ?
          • [^] # Re: Serveur web java .. Que choisir ?

            Posté par  . Évalué à 2.

            en gros, faut oublier la notion de page....ce sont des programmes (servlet) qui repondent aux requetes http. (les jsp sont des servlets masquées, mais c'est la meme chose).

            pour apache en frontal : en gros, tu lui dis, tout ce qui est en .jsp ou dans tel repertoire, tu demandes a tomcat, le reste (les images, les pdf, le reste quoi), tu t'en occupes direct.

            pour le context (voir la doc, ServletContext), c'est en gros comme une session php, mais visible de tout le monde !
            • [^] # Re: Serveur web java .. Que choisir ?

              Posté par  (site web personnel) . Évalué à 1.

              Je comprends mieux

              En fait les pages n'évoluent pas énormément dans ce projet d'où certaines interrogations.

              Est-ce que tu penses qu'il faut utiliser un cache au niveau d'apache (deux niveaux de cache donc) ? ou juste utiliser ServletContext ?
              • [^] # Re: Serveur web java .. Que choisir ?

                Posté par  . Évalué à 2.

                ce depends des volumes !
                si c'est quelques pages...tu les charges en memoire (en context), et comme ca c'est reglé. si les volumes sont importants, faut reflechir :-)

                ca peut etre marrant de generer des pages en .html pour les servir par apache...mais c'est casse gueule a mon avis...chuis pas convaincu que ce soit une vraie bonne idée.
                • [^] # Re: Serveur web java .. Que choisir ?

                  Posté par  (site web personnel) . Évalué à 1.

                  En fait le problème c'est que c'est un annuaire d'artiste musicaux (au sens large, auteur compositeur label etc.) avec toutes leurs caractéristiques (et dispo pr les PDA de surcroit)

                  Alors au début c'est limité au Val d'Oise mais après cela peut s'étendre
                  Bref il peut y avoir un grand nombre de pages

                  Il faudrait que je réfléchisse sur la quantité de données qui pourra être servie ...
                  Bon je ne pense pas qu'il y aura un million d'artiste musicaux donc je pense que l'on peut tout mettre en mémoire (si y en a assez)

                  Mais c'est vrai que l'idée de générer du html et qu'un démon apache les prenne directement me plaisait assez
                  Bon je vais manger, je reviendrait pe discuter après le repas !

                  Merci pour tout Julien :o)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.