• 締切済み

HttpServletとjsp負荷はどっちが高い?

◆全く同じ処理をさせたとき、サーバーの負荷は変わるのでしょうか? Aの処理のあと、Bの処理をして、その後Cの処理をさせるとき、 (1)HttpServletを継承したクラスから呼ぶか? (2)jspで呼ぶか? でサーバ負荷は変わるのでしょうか? ファッション層の処理を、 案1◆コントローラ層部分が呼んで、結果を踏まえて処理制御して、、  という形にするか? ファッション層の処理を、 案2◆View層部分に呼ばせるか? で、パフォーマンス観点で、どう判断すれば良いかわからず困っています。 ※もし良ければ「構成」の観点でも、何か「こうあるべき」的なものがあると、それもご教授頂けますと幸いです。 .

みんなの回答

回答No.4

知らぬ間にManagedBeanが登場していたようですが、それも既に「ManagedBeanは次のJSFバージョンで無くなる予定だ」そうです(^_^;) JSF(JavaServer Faces)関連 https://www.sangyo-rock.com/tech/index.php?JSF%28JavaServer%20Faces%29%B4%D8%CF%A2 >JSFはMVCにおけるVとCの機能を提供する >View→JSFのタグライブラリで拡張されたJSPを用いてWebインターフェイスを記述 >Control→Managed Beanと設定ファイルによってコントローラを実装 >Model→EJB Java Management Extensions https://ja.wikipedia.org/wiki/Java_Management_Extensions >Java EE 6仕様では、managed beanはJavaクラスで実装されたBeanであるとしており、beanクラスと呼ばれる。他の何らかのJava EE 技術仕様(たとえばJavaServer Faces技術仕様)でmanaged beanであると定義されたトップレベルJavaクラス、あるいは次の条件をすべて満たすトップレベルJavaクラスであれば、それはmanaged beanである。 JavaServer Faces入門 http://dream.mods.jp/wp/tag/jsf/ >JavaEE7からはCDIがデフォルトになっており、そのためNetBeansIDE8.xでは「ManagedBeanは次のJSFバージョンで無くなる予定だ」というメッセージが出ます。

回答No.3

知らぬ間にJSP(JavaServer Page)の進化形として「JSF2」(JavaServer Faces 2)が登場していたようです(^_^;) よってサーバー・サイドJavaには「Servlet(Java Servlet)、JSP(JavaServer Page)、JSF(JavaServer Faces)、Enterprise JavaBeans」の4種類有ると言うことになります。 JavaServer Faces https://ja.wikipedia.org/wiki/JavaServer_Faces

回答No.2

回答No.1 amanojaku1 申し訳ございません、訂正します。 >HttpServletとjsp負荷はどっちが高い? 下記のような処理が入るのでjspの方が負荷が高いと言うことになります(断定はできませんが、毎回と言う事ではなく、(作成・変更されてから)最初の1回だけだろうと思われます)。 ざっくりJava JSP/サーブレット https://qiita.com/kazukichi/items/4325b64450f93f04e316 >JSPはJavaサーバーがJSPのコードを読み込み、それをサーブレットのソースコードに変換。 >HTMLのタグなど、すべてprintlnで書きだすように変換される。 >そして、生成されたサーブレットのソースコードをコンパイルし、サーブレットを生成してそれを呼び出す。

回答No.1

複数の人数で開発する場合に場合に、「Model、View、Controller」に分けます。 Model(Enterprise JavaBeans)はデータベースが得意な人が担当します。 View(JavaServer Page)はデザイナーが担当します。 Controller(Servlet)はデータベースが不得意な人が担当します。 個人でプログラミングする場合は、そこまで厳密に分ける必要は有りません(もちろん分けても良いでしょうが、「JavaServer Page」だけでプログラムしても良いでしょうし、「Servlet」だけでプログラムしても良いでしょう)。 >HttpServletとjsp負荷はどっちが高い? 下記ページには「実は、JSPとサーブレットは技術的には同じもの」とされているので、ほぼ同等と思われます。 初めてのWebアプリケーション・サーバ http://www.atmarkit.co.jp/fjava/rensai/was05/was05_1.html >サーブレットは最初のHTTPリクエストによって初期化され、それ以降はメモリ上に常駐し、マルチスレッドでサービス処理のみを実行するようになります。そして、HTTPリクエストが来なくなると消滅処理が実行され、メモリ上から消滅します。 >実は、JSPとサーブレットは技術的には同じもので、違いはその記述方法にあります。 JavaによるWebアプリケーション入門 http://www.wakhok.ac.jp/~tomoharu/web2004/text/index_c10.html ざっくりJava JSP/サーブレット https://qiita.com/kazukichi/items/4325b64450f93f04e316 ServletとJSP、Beanのうまい連携方法を教えてください http://www.atmarkit.co.jp/fjava/javafaq/jsp/jsp05.html ちなみに知らない間に「Thread」は非推奨になっているようです。 Java EE 7で並列処理がケタ違いに速くなる! 使いこなしのポイントは?──Java Day Tokyo 2013レポート https://blogs.oracle.com/wlc/java-ee-7-java-day-tokyo-2013 >Java EE 7では、「Concurrency Utilities for Java EE」の導入により、マルチコア・プロセッサの能力を余すことなく引き出し、並列処理を格段に速く行えるようになる。 ↑このJava EE(Enterprise Edition)はサーバー側の開発環境の話です。 >2004年にJava SE 5でConcurrency Utilitiesを導入。 ↑このJava SE(Standard Edition)はクライアント(一般の個人のPC)側の開発環境の話です。 >2011年にリリースされたJava SE 7ではFork/Joinに対応。さらに、2014年にリリース予定のJava SE 8ではラムダ式をサポートし、これまで以上に並列処理が簡単に記述できるようになるという。 >「スレッド処理に関して、いまだにJavaの登場当初からのnew Thread(r).start(); などと書いているプログラムを多く見かけるが、もうこのような実装はやめたほうがよい」とアドバイスした。 >そこで現在、スレッドを直接生成する方法に代わって推奨されているのが、Java SE 5 から導入されたConcurrency Utilitiesである。Concurrency Utilitiesは並列処理の実装を簡素化するために導入されたAPIで、これを利用することによってスレッドのライフサイクル管理が簡単になるほか、スケーラビリティやパフォーマンスが大幅に向上するのだという。 >このデモでは、シングルスレッドやマルチスレッドのプログラムが256個のうち一部のプロセッサしか利用できないのに対して、Concurrency Utilitiesを使った場合は256個のプロセッサの負荷がほぼ同時に限界まで達し、瞬時に処理を終えることが確認できた。 >「Javaはパフォーマンスが悪いという声を聞くことがあるが、それは間違い。パフォーマンスが悪いのは、いまだに古いやり方でプログラムを書いているからにすぎない。Concurrency Utilitiesでマルチコア・プロセッサの能力をフルに使い切れば、Javaは驚異的なパフォーマンスを発揮する」

関連するQ&A