タグ付けされた質問 「performance」

Servicesモジュールを使用してREST WebAPIを開発しました。正常に動作します。私は、Drupalインスタンスを水平方向にスケーリングする必要があると予測される使用法でそのAPIのクライアントを持っています。APIの性質上、大量のCPUおよびGPUリソ​​ースを必要とするため、クラウドサーバーを使用できないことに注意してください。また、私のAPIの性質上、DrupalインスタンスはWindows OSで実行する必要があります。（私のアプリケーションには、Win64でのみ利用可能なソフトウェアが必要です。）現在、同じ場所にかなり頑丈なサーバーがあり、この野心的なクライアントのために、次の方法でハードウェアを水平方向に拡張する予定です。 フロントエンドロードバランサーとしてHaProxyを実行している1つのCentOSサーバー 最初に2つ、必要に応じてさらに追加して、DrupalをホストするWindows Server 2008 R2サーバー、 複数のDrupalインスタンスに単一のデータベースを提供する1つのCentOSデータベースサーバー DBサーバー1が停止した場合に備えて、レプリケーションモードで実行されている1つのCentOSデータベースサーバー。 私の質問は、HaProxyロードバランサーの動作に関係しています。Drupalインスタンスによって作成されたセッションIDは、互いに一意であると想定しています。ロードバランサーはsessionIdを確認し、すべての要求をそのsessionIdを生成した同じサーバーにルーティングしますか？負荷分散によって各API要求が別のサーバーに送信される場合、REST WebAPI通信はどのように機能しますか？同じリソースに対する複数のAPIリクエストが同じDrupalインスタンスにルーティングされることを保証できないため、WebAPIによって参照されるすべてのデータをデータベースに保存する必要がありますか？

8 services  performance 

複数のビューの代わりにビューの複数のディスプレイを作成することは単に便宜上の問題ですか、それともパフォーマンス上の利点はありますか？ 一部のディスプレイに次のアイテムのいずれかが存在し、他は存在しないと、ビュー全体に影響しますか？ コンテキストフィルター コンテンツタイプフィルター 集約 たとえば、記事のコンテンツタイプの結果だけを表示するディスプレイ、フォーラムの結果を表示するディスプレイ、カスタムの写真コンテンツタイプを表示するディスプレイで、各ディスプレイの動作が遅くなるかどうか知りたいです。あるいは、すべてのビューが同じコンテンツタイプを共有しているが、1つはnidのコンテキストフィルターを持ち、他は持っていないという点でのみ異なる場合、それらはすべて遅くなりますか？ 1つのビューに30のディスプレイがある場合、パフォーマンスを向上させるためにリファクタリングする必要がありますか、それともUIがそれほど多くのディスプレイを表示するように意図されていなかったからです。

8 views  performance 

特定のビューのキャッシュのクリアを開始するために特定のビューを無効にする必要がある状況に直面しています。 views_invalidate_cache（）は、サイト上のすべてのビューについて、キャッシュされたすべてのビューデータをクリアします。 モジュールコード内から特定のビューのキャッシュ無効化をトリガーするにはどうすればよいですか？

8 7  views  caching  performance 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ Drupal Answersのトピックとなるように質問を更新してください。 3年前休業。 私のサイトは動作が遅く、そのモジュールを疑っていますが、どちらのモジュールかはわかりません。ロードされたページで実行されているすべてのSQLクエリを表示できるモジュールはありますか？おそらく、他の人がこのデータを監視するために使用するコマンドラインツールがないのですか？

8 performance  database 

私は現在Drupal 7を使用しており、次のモジュールをインストールし、すべて最新のバージョンに更新しました。 ビュー-7.x-3.0-beta3 CTools-7.x-1.0-alpha4 パネル-7.x-3.0-alpha3 ルール、ACL、高度なフォーラム、フォーラムアクセス、ユーザーポイント、BUEditor 「PHP Fatal Error：Out of memory」というメッセージが表示され続けます。サーバーの制限は、プロバイダーが許可する最大値（32 MB）です。これらのエラーは主にモジュールページを操作するときに表示されますが、パスワードを更新したりノードを編集したりしようとするユーザーにも表示されます。 したがって、メモリ使用量を減らす方法について何かアドバイスはありますか？ PS：これらのエラーのほとんどにビューとビュープラグインの.incファイルが含まれていることに気づきました。ただし、コアモジュールとシステムの.incファイルにも関係があります...必要に応じて、そこにコピーすることもできます。

7 performance 

安い共有ホストにDrupal 7を再インストールしました。インストールはうまくいきました... FTP経由で1098ファイルをコピーし、2分以内にインストールしました。標準インストール（すべてのモジュールがコアにある）には、約5〜10秒かかりました。インストール後、サイトは正常に動作します。安価なホスティングなので、少し遅い場合もありますが、許容範囲です。 昨日、私は新しいDrupal 8をインストールしました（これが、比較のために今日Drupal 7をインストールした理由です）。最初に気づいたのは、ファイル数12327です。現在、Viewsなどのモジュールがコアに含まれていることは理解していますが、ファイル数が10倍を超えて増加するのは少し奇妙に思えます。これには別の理由がありますか？ ？ すべてのファイルをコピーしたら、Drupal 8をインストールしようとしました。インストールページの読み込みには最大20秒かかります。インストールを開始しようとすると、PHPでOPcacheが有効になっていないという通知が表示されます。これが遅い理由ですか？代替品はありますか？ インストールを続行すると、ランダムなエラーが発生します。Googleでそれらを検索しても、詳細な情報は得られません。数か月前に修正されたバグについての何か、それは私が見つけることができたすべてです。インストールが成功するまでに3回再起動する必要がありました。 最大の問題はパフォーマンスです。デフォルトのインストール中にこれらすべてのモジュールをインストールするのに、Drupal 7では約5〜10秒かかりました。Drupal8では約20〜30分かかりました。さて、いくつかのモジュールが追加されましたが、これは非常に奇妙に見えます。3回リトライしなければならなかったので、Drupal 8をインストールするだけで約2時間かかりました。インストール後は遅くて使えないので、インストール全体を削除する必要がありました。 誰かがこの問題についてもっと知っているかどうか疑問に思っています。Drupal 8が適切に実行するには、Drupal 7の20倍以上のリソースが必要ですか？それとも、OPcacheが不足しているためですか？この問題が発生するのは私だけですか？ 新しい機能を試してみたいので、アドバイスがあれば歓迎します。Drupal 7は私の安いホスティングで完璧に動作しますが、Drupal 8は本当の悪夢です。 この問題を見つけて解決するために、他にどのような技術情報が関連しているのかわかりません。

7 8  caching  performance 

まず、私はデューデリジェンスを確保し、以前に出てきた質問を重複させないようにしています。stackexchangeやその他のさまざまな場所で、ビューのキャッシュや、さまざまなタイプのビューキャッシュの詳細（例：hereとhere）について説明している投稿が数多くあります。ただし、ビューキャッシュのさまざまなレイヤー間の関係と、それらがケース固有のキャッシュの決定にどのように影響するかを十分に説明している詳細はまだわかりません。簡単にするために、私はこの質問の範囲を、コントリビュートスペースで提供される他のレイヤーとは関係なく、すぐに使える7.x-3.xのキャッシュオプションに焦点を合わせています。 ビューは、ディスプレイごとに「クエリ結果」キャッシュと「レンダリングされた出力」キャッシュの2つの時間ベースのキャッシュレイヤーを公開します。各キャッシュに含まれる生データの詳細は明確ですが、それらの相互作用方法は明確ではありません。レンダリングされたキャッシュへのヒットがクエリキャッシュを完全にバイパスするのか、2つのレイヤーが別々に動作するのか、私は特に疑問に思っています。私は（のような旧主張するいくつかの参照見てきたこの1を）、および（のように後者を主張しているいくつかのこの1）。 理論1-個別のキャッシュレイヤー 最初は、各レイヤーが別々に「連続して」呼び出され、レンダリングされた出力キャッシュがそのCID内の実際のクエリ結果をハッシュするという印象（および期待）を抱いていました。このようにして、新しいコンテンツがビューに即座に反映されるようにしながら、最も負荷の高いクエリ後のロード/ビルド作業をキャッシュするエレガントな方法があります（ "クエリ結果"キャッシュがオフで、 "レンダリングされた出力"キャッシュがオン）。いくつかの簡単なテストは、レンダリングされた出力キャッシュが現在のクエリ結果を認識していない可能性があるため、これは不可能かもしれないことを明らかにしています。 理論2-レンダリングされた出力キャッシュがクエリ結果キャッシュを「包括」する もう1つの可能性は、レンダリングされた結果キャッシュが、クエリ自体（結果ではない）のハッシュによってキー設定されることです。この場合、ヒットすると、クエリキャッシュやDBを参照する必要なく、レンダリングされた出力を直接返すことができます。これが事実である場合、「レンダリングされた結果」キャッシュよりも短い時間間隔で「クエリ結果」キャッシュを設定することはあまり意味がないと思います。もちろん、利点は、DBへの直接クエリを回避しながら、レンダリングされた出力をより頻繁に更新できることです（多くの動的テーマロジックまたは頻繁なエンティティ更新がある場合）。ただし、最も複雑なビュークエリを除くすべての場合、この種類の分離はそれほど有利に思えません。 理論2を指す「ブラックボックス」テストをいくつか実行しましたが、他にいくつかの設定が機能しているかどうか、またはビューのバージョンによって答えが異なるかどうかはわかりません。私もコードを少し調べましたが、ほとんどのビューのプラグインメソッドがドキュメント化されておらず、たまに追跡するのが難しいことがイライラしています。とにかく、これに対する答えは、他の人の参考資料として役立つと思います。

7 7  views  caching  performance 

約50のフィールドを持つノード追加フォームがあり、ほとんどが1つのフィールドコレクション（別の5つのフィールドを持つ）を持つテキストと、いくつかのエンティティと用語参照があります。 ページの読み込みに約30秒かかり、使用できなくなります。 いくつかの遅いクエリがあります（99.28-DrupalDatabaseCache :: getMultiple、34.21-views_plugin_query_default :: execute、20.51-DrupalDefaultEntityController :: load、18.46-DrupalDatabaseCache :: getMultiple、17.46-DrupalDatabaseCache :: getMultiple .. Cache :: getMultipleクエリには1087のプレースホルダーがあり、EntityController :: loadには1084のプレースホルダーがあります。 完了までにさらに30秒かかるフィールドコレクションの[別のアイテムを追加]をクリックした場合。 ページの読み込み時間を短縮するにはどうすればよいですか？ 編集：私はAPCをインストールしましたが、すべてのキャッシュクエリが削除されましたが、問題は解決しませんでした-まだ約30秒の読み込み時間です。遅いロード時間はキャッシングに関連しているとは思いません。約280MBのメモリロードを使用してページを構築しています。 編集：フィールドコレクションを削除し、memcacheとentitycacheをインストールすると、読み込み時間が20秒短縮されました。ただし、最初にページをロードするのに10秒かかり、ajaxリクエストごとにさらに10秒は許容されません。多数のフィールドでWebフォームはどのように機能しますか？多分それはより良いオプションでしょうか？

7 nodes  forms  caching  performance 

Apache 2.2でDrupal（最新バージョン7.22）を実行しています。また、Varnish（モジュールとプロキシ）もインストールしています。Apacheでは、mod_deflateモジュールを無効にしました。Webを読んでいると、Drupalのパフォーマンスページのオプション（集約css、js）はcssファイルとjsファイルを圧縮すべきではないようです。しかし、自分のサイトを閲覧してhttpヘッダーを確認すると、「Content-Encoding：gzip」を受信して​​います。（デフォルト）.htaccessを見ると、gzipで圧縮されたファイルを、それらを読み取ることができるクライアントに提供するために、いくつかの書き換えルールがあることがわかります。だから、これが "Content-Encoding：gzip"ヘッダーの出所だと思います。また、drupalのパフォーマンス設定ページでキャッシュされたページの圧縮を有効にすると、要求しているページのhtml（匿名ユーザーのみ）でも圧縮されて返されます。 1）「CSSファイルを集約して圧縮する」オプションを実行します。および「集約JavaScriptファイル」。実際に集約されたファイルを圧縮しますか、それとも.htaccessがそれらをgzipしたように見えるだけですか？Chromeデベロッパーツールを使用すると、ファイルは圧縮されているように見えます。しかし、Firefoxの開発者ツールバーアドオンでそれらをチェックすると、（情報->ドキュメントサイズの表示）圧縮されたものとして報告されません（認証済みユーザーとしてアクセスした場合でも、htmlファイルは常にそのように報告されます！） 2）それらが実際にgzipされている場合、圧縮はどこで行われますか？どういうわけか圧縮などのレベルを制御できますか？ 3）X-Drupal-Cache "MISS"を常に受け​​取っています。Varnishがインストールされているので、あまり気にしません。それでも、キャッシュにアクセスしていないため、圧縮されたhtmlファイル（キャッシュにない）が返されるのはなぜですか？ 4）Varnishモジュールが何かを混乱させる可能性はありますか？どんな場合でもVarnishがバイパスされるように、httpsでWebサイトにアクセスしています。 5）mod_deflateを有効にする場合、.htaccessのその部分をそのまま残すべきですか？mod_deflateでは事前圧縮ができないことを理解していますが、圧縮の方が優れている場合はどうなりますか？ 6）また、drupalがそれ自体でcss、js、htmlファイルを圧縮する場合、これらのファイルに対してmod_deflateを有効にする意味は何ですか？ 参考のために、ここに私の.htaccessファイルの関連部分を示します。 <IfModule mod_headers.c> # Serve gzip compressed CSS files if they exist and the client accepts gzip. RewriteCond %{HTTP:Accept-encoding} gzip RewriteCond %{REQUEST_FILENAME}\.gz -s RewriteRule ^(.*)\.css $1\.css\.gz [QSA] # Serve gzip compressed JS files if they exist and the client accepts …

7 7  performance  css-js-aggregation 

メンバーとそのユーザーポイントのリストを表示する基本的なビューがあります。ビューのクエリ出力は、このクエリの実行に1500ms以上かかることを示しています。 クエリビルド時間24.71 ms クエリ実行時間1546.84 ms レンダリング時間の表示88.29 ms SELECT users.picture AS users_picture、users.uid AS uid、users.name AS users_name、users.mail AS users_mail、users.created AS users_created、userpoints_total.points AS userpoints_total_points、 'user' AS field_data_field_motorcycle_user_entity_type、 'user' AS field_data_field_reity_count_user_userユーザーのAS field_data_field_address_user_entity_type FROM {users}ユーザーLEFT JOIN {userpoints_total} userpoints_total ON users.uid = userpoints_total.uid WHERE（（（users.status <> '0'）AND（users.uid NOT IN（ '1'））））LIMIT 10 OFFSET 0 そのクエリをコピーしてmyphpadminに貼り付けて実行すると、5ミリ秒未満かかります。「実行時間」で他に何が起こっていますか？私はそれについてウェブで良い助けを見つけることができませんでした。

7 views  performance 

コンテンツタイプの1つにかなり大きなノードフォームがあります。約100のフィールドがあるとします。これらのフィールドの多くは値が無制限のテキスト値なので、ユーザーはAJAXボタンを使用してこれらのそれぞれに「別のアイテムを追加」します。視覚的には、フィールドグループを使用して物事を合理的に保つため、このフォームはそれほど威圧的ではありません。 問題：「別のアイテムを追加」をクリックするのが非常に遅くなります。本当に遅いみたい。 サーバーのパフォーマンスだと思ったのですが、Firebugでチェックアウトしました-要求は実際にはそれほど長くかかっていませんが、WOW-クライアント側のCPU使用率（Chrome、Firefox、および私が試した他のブラウザー）は100％に達していますそこに最大11〜12秒間留まると、AJAXリクエストが完了します。 それは非常識です。 したがって、現時点では、自分のオプションが何であるかわかりません。どういうわけかフォームを分解できますか？ワークフローngスタイル？多くの人々は、フィールドグループを大量のフィールドを整理する方法として言及していますが、それは明らかにパフォーマンスに役立ちません。 助けてくれてありがとう。

7 7  entities  performance 

生成に最も時間がかかるページを見つけることは可能ですか？Develがページごとにクエリログを収集できることは知っていますが、ページごとにこれらを収集して最も遅いページのリストを表示するモジュールはありますか？

7 7  debugging  performance 

Q＆AとしてPostgreSQLでDrupal 7を実行しています（多数のノードの挿入/更新といくつかのcontribモジュールを使用）。特定のテーブルに対する特定のpgsqlバキュームポリシーを推奨しますか？

7 7  performance  database 

コードをPHPからC ++またはCに変換するHipHopまたは他の同様のソリューションを使用して、Drupal 7のパフォーマンスを向上させたいと思います。 以下のシナリオを適切に実行するには、どのような手順が必要ですか？ 私はしたいと思います ： @開発環境をコンパイルされていないphpとして維持し、contribとカスタムモジュールを追加してテストします。 @developmentをテストした後、@ stagingに対してrsync @developmentを実行します... ...そして@stagingをコンパイルします @stagingをテストする rsync @staging to @life 少し単純化しすぎですが、概要を説明する必要があります。 それが不可能な場合、他のオプションはありますか？

7 7  performance  staging