GWTは素晴らしいフレームワークです。 私はJava開発者であり、JSP、JSF、およびGWTを使用してシンクライアントで作業しました。 JSPについて特別なことは何もありません。テクノロジーはほぼ消滅しましたが、JSFでは2つのプロジェクトで数年調理しなければなりませんでした。複雑なページの不可解な動作の分析の瞬間にエクスタシーに。 はい、例ではすべてがすっきりとシンプルに見えますが、実際の生活はそうではなく、プロジェクトのJSFページは中くらいのサイズであり、テンプレートを使用して設計するための有能なゆっくりとしたアプローチで、特に部分的に「臭い」がし始めます読みやすさ。 GWTでは、すべてが非常にきちんとしています。なぜなら、私たちは、ネイティブバージョンのJava言語で書いているからです。ただし、必要最低限のバージョンですが、それで十分です。
GWTで巨大なJavaScriptファイルがクライアントにロードされるという事実について話すと、ここに私の意見があります。 GWTでは、クライアントが最初にログインするときに、ロジックはロードされますが、多くはありますが、一度だけです。 ダウンロード後、純粋なビジネスロジックデータのみがクライアントとサーバー間を流れます。 具体的には、最初の3MBのダウンロードがあり、次にAJAXリクエスト/レスポンスがあります。これは実際にどのようなデータを持っているかによって異なります。 JSFでは、任意のページに入ると、ブラウザーにデータと、それらが表示されるインターフェースの説明の両方が含まれます。 ほとんどの場合、インターフェース記述（html）のサイズは、データ自体のサイズよりも何倍も大きいです。 クライアントで1KBのデータを表示するには（テーブルの数行など）、15〜30 kBのhtmlをブラウザーに転送する必要があります（画像とスクリプトはキャッシュされていると考えられます）。 ただし、ページ上のデータは通常、ヘッダー、メニュー、さまざまなブロックなど、はるかに多くのデータです。 実際、データと機能で非常に飽和しているページの重量は通常、少なくとも100〜200 kBです。 GWTは、同じページを表示するために、サーバーから1 kBのデータを取得します。 ユーザーが定期的にサイトに長時間アクセスしている場合、プライマリ3MBの損失は30分間補償されます。 これを念頭に置いて、GWTはジョブの実装には理想的ですが、通常のサイトではそれほど良くないかもしれません。
いずれにせよ、これは議論中のトピックに少し「突入」するための単なる紹介であり、この記事はテクノロジーの比較に関するものではなく、ブラウザーとサーバー間を行き来するデータのスパイが問題の解決と最適化にどのように役立つかについてですクライアントとサーバーの相互作用。 執筆時点では、すでに非常に古いGWT 1.5を使用し、DTOの転送には、同等に古く、もはやサポートされていないGileadライブラリを使用しました。 GWTの最新バージョンにアップグレードし、Gleadを放棄してGWT-shy RequestFactoryを採用する計画があります。 テクノロジーに関係なく、ツールとデバッグ方法は同じままです。 FireBugプラグインをインストールした状態でFireFoxを使用しました。
メモリリークの発見方法
GWT、Gilead、JBoss、Hibernateなどの使用されているテクノロジーを更新することに決めました。 ライブラリを置き換え、サーバーを展開し、プロジェクトを再コンパイルしました。 立ち上げ、テストを行い、商業運転を開始することにしました。 サーバーを更新しました。お待ちしています。 最初のレビュー-高速。 1時間後、すべてが「ハング」し始め、15分後に「賭けをした」後、少し後にOutOfMemoryによってサーバーがクラッシュしました。 彼らはこの時間に1時間ごとにサーバーを再起動し、問題を把握しようと必死に試み始めました。 繰り返しますが、この記事は完全にこれに関するものではなく、検出に失敗し、古いバージョンにロールバックしました。 長い間、ダンプの分析、負荷テストを試みましたが、それでも問題の原因を見つけることができませんでした。
1か月後、テスターはシステムのログの1つが長時間開いていると不平を言い始めました（ユーザーはこれについて不平を言いました）。 この問題は私には再現しませんでした。私は彼にFireFoxとFireBugをインストールし、そこで何が起こっているのかを確かめるように頼みました。 ジャーナルが開かれたときに、10レコードのプレートを表示するために、約4メガバイト（!!!）のパケットがクライアントにロードされたことが判明しました。 問題の原因はすぐに見つかりました-サーバー上で、表示用のデータをフェッチするとき、データベースから読み取られるレコードの数に制限はなく、データベーステーブルの内容全体がクライアントにロードされました。 開発者のテストベースでは、テーブルに50個のレコードがあり、テスターにはこのテーブルに数千個のレコードがある産業ベースの新しいダンプがありました。 問題の修正-コードを1行追加します。
技術更新中にサーバーが「クラッシュ」した理由は、このジャーナルにあったと思います。 なぜ古い技術が対処したのですか？ どうやら、使用するデータキャッシングが少なくなりました（レビューにより、新しいテクノロジがより高速に機能することが間接的に確認されました）。 残念なことに、このファイルはユーザー（そしてもちろん、開発者と実装者）に大きな打撃を与えたため、JBossを更新する次の試みは1年後に完了しました。GWTとGileadの公式計画はありません。 これは、忘れられたコード行が大規模な計画を台無しにし、何百時間もの仕事を盗み、多くの人々に白髪を追加する方法です。
ネットワークトラフィックとメモリを節約する方法
怠けてはいけません。サーバーに転送されて戻ってくるものをFireBugで確認するために数時間を費やすと、面白いものを見つけることができます。 具体的な例：クライアント（ブラウザ）は、サーバーから定期的に通知を要求します。 実際、リストの受信に応じて、誰が要求したかに関するデータをサーバーに転送する必要があります。 クライアントに保存されたUserオブジェクトには、さまざまなリストデータなど、それに関する多くの情報が含まれています。 そのため、サーバーにデータを要求するメソッドは単純に実装されました-Userオブジェクト全体が渡されます。 他の多くのメソッドも同じ方法で実装されます。 デバッグの下で見て、文字列にシリアル化され、ユーザーサーバーに転送されるサイズは15kBであることがわかりました。 ただし、ユーザーセッションキャッシュ内のサーバーにはこのオブジェクトのコピーがあり、メソッドによって要求されたデータを受信するには、一般にユーザーIDで十分です。 メソッド内のUserオブジェクトをそのIDで置き換えると、要求サイズを15kBから50-100バイトに減らすことができます。または、パラメーターなしでメソッドを呼び出し、現在のセッションからユーザー情報を取得することもできます。
最新のネットワークインフラストラクチャの場合は15kBですか？ ほこり！ しかし、多くのリクエストがあり、システム内のユーザーは一人ではないことを忘れてはなりません。 サーバーは、ネットワークリソースに加えて、プロセッサとメモリリソースを使用して、受信した15kBをJavaユーザーオブジェクトに変換します。Javaユーザーオブジェクトから、要求のIDが誇らしげに取り出され、その他はすべてガベージコレクターに委ねられます。
負荷テストの方法
テクノロジを更新したときにサーバーがクラッシュし始めたとき、問題の原因を検出する試みの1つは負荷テストを実行することでした。 無料のユーティリティとソフトウェアライブラリをすばやく検索して表示しても、テスト環境を作成するのに役立ちませんでした。そこで、私は自分で簡単なものを書くことにしました。 GWTサーバーに送信するものはすべてHTTPリクエストです。つまり、標準のJava言語ツールを使用してそれらをエミュレートすることができます。 ここでのみ、リクエストで正確に送信するものは何ですか？ 繰り返しになりますが、FireBugが助けになりました。 クライアント部分に移動してアクションを実行し、FireBugでPOSTリクエストのコンテンツを取得します。 ストレステスト用の自己記述ユーティリティは、非常に小さく、非常に機能的であることが判明しました。 特定のUserオブジェクトは、アクションの繰り返しセットを実行します。 HTTPリクエストを送信します。 数十/数百のそのようなオブジェクトが異なるスレッドで起動され、サーバーに適切な負荷を与えます。 現在、JBoss 7に切り替えた後のチェックのためにシステムを負荷下でテストしています：プロセッサリソースはサーバーによって90％使用され、夜中に500 MBのメモリが消費されます。クライアント部分に入ると顕著な「減速」があります。
おわりに
上記のすべてはGWTだけでなく、すべてのシンクライアントにも適用されます。サーバーとクライアントの間で行われることをデバッグで確認してください。 これは、ボトルネック/問題領域の兆候を示すだけでなく、使用されているテクノロジーの本質をよりよく理解するのにも役立ちます。