問題タブ [query-cache]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
mysql - MySQL クエリ キャッシュの Hitrate % 値は何を表していますか?
MySQL Workbench を使用して、実行している 2 つのサーバーの管理ビューを見ています。
どちらのサーバーも同様の帯域幅を持っています
1 つのサーバーには、クエリ キャッシュ ヒット率が 15% のサイトが 1 つだけあります。
もう 1 つのサーバーには 100 を超えるサイトと 88 のデータベースがあり、クエリ キャッシュのヒット率は 70% です。
これらの MySQL サーバーのパフォーマンスを最適化して向上させる最善の方法について学習している最中であり、これらの値が何を意味するのか、何が良いのか悪いのか、そしてどのように改善できるのかについて何も見つけることができません。
(私はたくさん検索しましたが、適切な用語で検索していないと思います)
mysql - QUERY CACHEを定期的にリセットする必要がありますか?
私はウェブサイトのゲームを実行しています。ゲームが開始された年のクエリキャッシュのリセットなどは何も触れていません。テーブルにもよりますが、約5000〜100万行を処理しています。すべてが絶えず更新されており、テーブルに挿入されています。私が正しく理解していれば、挿入または更新するたびにそのテーブルのキャッシュがクリアされますか?それが私のオンライン検索でわかったことですが、それが本当かどうか、または定期的にキャッシュをリセットする必要があるかどうかはわかりません。
1か月前に発生したクエリは、おそらく現在は役に立たなくなっています。したがって、これらのクエリ結果を保存している場合は、まったく同じクエリを再度実行する可能性がないため、まったく価値がありません。
SHOW STATUS LIKE "Qcache%"を実行したところ、結果は次のようになりました。
Qcache_free_blocks 6941
Qcache_free_memory 23490288
Qcache_hits 253269763
Qcache_inserts 368937684
Qcache_lowmem_prunes 57410566
Qcache_not_cached 9872266
Qcache_queries_in_cache 35275
Qcache_total_blocks 84877
それらが何を意味するのか、あるいはキャッシュをリセットする必要があるかどうかを判断するのに役立つのかどうかは、私にはよくわかりません。前もって感謝します。
mysql - MySQL Query Cache を保存してリロードし、サイトを最高速度で実行し続けるにはどうすればよいですか
テストサーバーで Magento e-commerce インストール (PHP/MySQL で実行) を実行しています。(私が読んだものから) query_cache_size は 272,629,760 バイトとかなり大きく、うまく機能します。
ほとんどのクエリがクエリ キャッシュに読み込まれると、サイトは非常に高速に実行されます。これは、最速の本番サイト (おそらく Google.com や Amazon.com 以外) と同じくらいの速さです。しかし、私が抱えている問題は、これらのクエリをすべてクエリ キャッシュにロードするために、サイト上の何百ものリンクを手動でクリックする必要があることです。リンクをクリックするたびに、クエリがデータベースに送信され、キャッシュに保存されます。しかし、サーバーを再起動すると、最初からやり直す必要があります。もっと良い方法があるはずです!
理想的には、再起動前にクエリキャッシュを「バックアップ」し、再起動時にロードする方法があればいいと思います。これは可能ですか?
それ以外の場合は、すべてのリンクを自動的にクリックする Web クローラーを設計する必要があります。
hibernate - Hibernate EntityManager + Query Cache - 「join fetch」が機能しない
次のようなクエリをキャッシュしようとしています:
問題はFETCH
、キャッシュがヒットしたときに効果がないように見えることです。つまり、コレクション Foo.bar が初期化されません。結果リストを繰り返し処理し、コレクションのすべてのインスタンスを手動で初期化することもできますが、最初からクエリ キャッシュを使用しない場合よりも全体がさらに遅くなります。
JBoss AS 6.0 / Hibernate 3.6 と Infinispan をキャッシュ エンジンとして使用しています。
不思議なことに、JMX コンソールから取得したキャッシュ統計によると、Foo.bar 内のオブジェクトはキャッシュされているように見えますが、それらのオブジェクトのキャッシュにはヒットがありません。
glassfish - グラスフィッシュのopenjpaクエリキャッシュの問題+クエリキーからのクラスキャスト例外
openjpa 1.2.0 と Glassfish の組み込み DataCache を使用して、クエリ キャッシュを有効にし、いくつかの名前付きクエリを固定すると、次の例外が表示されます: org.apache.openjpa.persistence.PersistenceException: java.lang.String cannot be cast to org. apache.openjpa.datacache.QueryKey
誰にもアイデアはありますか?
完全な例外ダンプ: [#|2011-05-01T11:43:05.728-0500|WARNING|sun-appserver9.1|javax.enterprise.system.core.transaction|_ThreadID=30;_ThreadName=httpSSLWorkerThread-20393-0;_RequestID =3ce3425f-cd4b-42b9-a305-570c5745add7;|JTS5054: 完了後に予期しないエラーが発生しました org.apache.openjpa.persistence.PersistenceException: java.lang.Object は org.apache.openjpa.datacache.QueryKey にキャストできません.apache.openjpa.kernel.BrokerImpl.afterCompletion(BrokerImpl.java:1870)、com.sun.jts.jta.SynchronizationImpl.after_completion(SynchronizationImpl.java:154)、com.sun.jts.CosTransactions.RegisteredSyncs.distributeAfter(RegisteredSyncs) .java:210) com.sun.jts.CosTransactions.TopCoordinator.afterCompletion(TopCoordinator.java:2585) で com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:433) com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:249) com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623) com.sun.jts.jta.TransactionManagerImpl .commit(TransactionManagerImpl.java:309) com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030) com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397) com. com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3571) の sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792) com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler. java:200) で $Proxy973.transfer(不明なソース) で、sun.reflect で。NativeMethodAccessorImpl.invoke0(Native Method) の sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) の sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) の java.lang.reflect.Method.invoke(Method. java:597) com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81) com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82) com.sun.xml.ws .server.InvokerTube$2.invoke(InvokerTube.java:146) com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257) com.sun.xml.ws.server.sei. com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595) の SEIInvokerTube.processRequest(SEIInvokerTube.java:93) com.sun.xml.ws.api.pipe.Fiber.java.lang.reflect.Method.invoke(Method.java: 597) com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81) com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82) com.sun.xml.ws.server .InvokerTube$2.invoke(InvokerTube.java:146) at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257) at com.sun.xml.ws.server.sei.SEIInvokerTube. processRequest(SEIInvokerTube.java:93) com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595) com.sun.xml.ws.api.pipe.Fiber.java.lang.reflect.Method.invoke(Method.java: 597) com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81) com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82) com.sun.xml.ws.server .InvokerTube$2.invoke(InvokerTube.java:146) at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257) at com.sun.xml.ws.server.sei.SEIInvokerTube. processRequest(SEIInvokerTube.java:93) com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595) com.sun.xml.ws.api.pipe.Fiber.java.lang.reflect.Method.invoke(Method.java:597) で、sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) で、com.sun.enterprise.webservice.InvokerImpl で.invoke(InvokerImpl.java:81) com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82) com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146) com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257) com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93) com.sun .xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595) com.sun.xml.ws.api.pipe.Fiber.java.lang.reflect.Method.invoke(Method.java:597) で、sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) で、com.sun.enterprise.webservice.InvokerImpl で.invoke(InvokerImpl.java:81) com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82) com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146) com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257) com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93) com.sun .xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595) com.sun.xml.ws.api.pipe.Fiber.java.lang.reflect.Method.invoke(Method.java:597) での invoke(DelegatingMethodAccessorImpl.java:25) com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81) での com.sun.enterprise .webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82) com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146) com.sun.xml.ws.server.sei.EndpointMethodHandler で。 com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93) での invoke(EndpointMethodHandler.java:257) com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber. java:595) com.sun.xml.ws.api.pipe.Fiber.java.lang.reflect.Method.invoke(Method.java:597) での invoke(DelegatingMethodAccessorImpl.java:25) com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81) での com.sun.enterprise .webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82) com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146) com.sun.xml.ws.server.sei.EndpointMethodHandler で。 com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93) での invoke(EndpointMethodHandler.java:257) com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber. java:595) com.sun.xml.ws.api.pipe.Fiber.com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146) で invoke(EjbInvokerImpl.java:82) com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java) で:257) com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93) で com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595) でcom.sun.xml.ws.api.pipe.Fiber.com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146) で invoke(EjbInvokerImpl.java:82) com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java) で:257) com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93) で com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595) でcom.sun.xml.ws.api.pipe.Fiber.com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539) の doRun(Fiber.java:554) com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber. Java:436) com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106) com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147) com com.sun.xml.ws.api.pipe.Fiber の .sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)。_doRun(Fiber.java:595) com.sun.xml.ws.api.pipe.Fiber.com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539) の doRun(Fiber.java:554) com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber. java:436) com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106) で com.sun.xml.ws.tx.service.TxServerPipe.process(TxServerPipe.java: 317) com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218) com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129) com.sun.xml.ws.api .pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115) com.sun.xml.ws.api.pipe.Fiber.com.sun.xml.ws.api.pipe.Fiber.Fiber._doRun(Fiber.java:554) の _doRun(Fiber.java:595) com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber. java:539) com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436) で com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243) でcom.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444) at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244) at com. sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135) com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113) com.sun.enterprise.webservice. com.sun.enterprise.webservice.EjbWebServiceServlet の Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)。com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:155) の dispatchToEjbEndpoint(EjbWebServiceServlet.java:226) com.sun.enterprise の javax.servlet.http.HttpServlet.service(HttpServlet.java:831) org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) の .web.AdHocContextValve.invoke(AdHocContextValve.java:114) org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) ) org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) で com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87) で org.apache.catalina.core.StandardHostValve. org.apache.catalina.core で (StandardHostValve.java:206) を呼び出します。org.apache で StandardPipeline.doInvoke(StandardPipeline.java:632) を呼び出します。org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) の catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) 1080) org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150) で org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) で org.apache.catalina.core.StandardPipeline .doInvoke(StandardPipeline.java:577) org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) org. com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask の apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)。com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568) の invokeAdapter(DefaultProcessorTask.java:637) com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask. java:813) com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341) で com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263) でcom.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214) で com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) で com.sun .enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106) 原因: java.lang.ClassCastException: java.lang.Object を組織にキャストできません。org.apache.openjpa.datacache.AbstractQueryCache.onTypesChanged(AbstractQueryCache.java:85) の apache.openjpa.datacache.QueryKey org.apache.openjpa.datacache.DataCacheStoreManager.updateCaches(DataCacheStoreManager.java:252) の org.apache. openjpa.datacache.DataCacheStoreManager.commit(DataCacheStoreManager.java:90) org.apache.openjpa.kernel.DelegatingStoreManager.commit(DelegatingStoreManager.java:94) org.apache.openjpa.kernel.BrokerImpl.endStoreManagerTransaction(BrokerImpl.java: 1308) org.apache.openjpa.kernel.BrokerImpl.endTransaction(BrokerImpl.java:2177) で org.apache.openjpa.kernel.BrokerImpl.afterCompletion(BrokerImpl.java:1846) ... 75 以上 |#]85) org.apache.openjpa.datacache.DataCacheStoreManager.updateCaches(DataCacheStoreManager.java:252) で org.apache.openjpa.datacache.DataCacheStoreManager.commit(DataCacheStoreManager.java:90) で org.apache.openjpa.kernel.DelegatingStoreManager .commit(DelegatingStoreManager.java:94) org.apache.openjpa.kernel.BrokerImpl.endStoreManagerTransaction(BrokerImpl.java:1308) org.apache.openjpa.kernel.BrokerImpl.endTransaction(BrokerImpl.java:2177) org. apache.openjpa.kernel.BrokerImpl.afterCompletion(BrokerImpl.java:1846) ... 75 詳細 |#]85) org.apache.openjpa.datacache.DataCacheStoreManager.updateCaches(DataCacheStoreManager.java:252) で org.apache.openjpa.datacache.DataCacheStoreManager.commit(DataCacheStoreManager.java:90) で org.apache.openjpa.kernel.DelegatingStoreManager .commit(DelegatingStoreManager.java:94) org.apache.openjpa.kernel.BrokerImpl.endStoreManagerTransaction(BrokerImpl.java:1308) org.apache.openjpa.kernel.BrokerImpl.endTransaction(BrokerImpl.java:2177) org. apache.openjpa.kernel.BrokerImpl.afterCompletion(BrokerImpl.java:1846) ... 75 詳細 |#]DelegatingStoreManager.commit(DelegatingStoreManager.java:94) org.apache.openjpa.kernel.BrokerImpl.endStoreManagerTransaction(BrokerImpl.java:1308) org.apache.openjpa.kernel.BrokerImpl.endTransaction(BrokerImpl.java:2177) org .apache.openjpa.kernel.BrokerImpl.afterCompletion(BrokerImpl.java:1846) ... 75 詳細 |#]DelegatingStoreManager.commit(DelegatingStoreManager.java:94) org.apache.openjpa.kernel.BrokerImpl.endStoreManagerTransaction(BrokerImpl.java:1308) org.apache.openjpa.kernel.BrokerImpl.endTransaction(BrokerImpl.java:2177) org .apache.openjpa.kernel.BrokerImpl.afterCompletion(BrokerImpl.java:1846) ... 75 詳細 |#]
hibernate - infinispan-configs.xmlのnamedCache「entities」を有効にして、namedCache「local-query」のバッキングに使用する方法
JPAプロバイダーとしてHibernate3.5.6-FINALを使用し、レベル2クエリキャッシュプロバイダーとしてinfinispan 4.2.0.ALPHA1を使用する場合、Hibernateのドキュメントとは異なり、データベースの結果が個別のメモリに複数回保存されるのではないかと心配しています。 infinispan namedCache、 "local-query"内の場所(同じレコードの一部を返す異なるHQLクエリの結果セット用)。頻繁に発行されるクエリの多くは結果セットに大きな共通部分があるため、これによりメモリがすぐに使い果たされ、クエリキャッシュが使用できなくなる可能性があります。
クエリキャッシュのバッキングとして休止状態の第2レベルのエンティティキャッシュを動作させることができないように見えるため、infinispanまたは休止状態、あるいはその両方を誤って構成していると思われます。infinispanの例をJPAとしての休止状態のレベル2クエリキャッシュとして見たいと思います。その結果自体は、JPAとしての休止状態のレベル2エンティティキャッシュとしてinfinispanによってバックアップされます。
詳細:
Hibernate 3.5ドキュメント(http://docs.jboss.org/hibernate/core/3.5/reference/en/html/performance.html#performance-querycache-enable)の主張:
クエリキャッシュは、キャッシュ内の実際のエンティティの状態をキャッシュしません。識別子の値と値型の結果のみをキャッシュします。このため、[原文のまま]クエリキャッシュは、クエリ結果キャッシュの一部としてキャッシュされることが期待されるエンティティの第2レベルのキャッシュと常に組み合わせて使用する必要があります。
ただし、 persistence.xmlで次のようにinfinispan( http://community.jboss.org/wiki/usinginfinispanasjpahibernatesecondlevelcacheproviderによる)を使用してHibernateレベル2クエリキャッシュを有効にします。
infinispan CacheManager JMX属性を調べると、infinispan-configs.xml(GAV org.hibernate / hibernate-infinispan / 3.5.6-FINALから、GAV org.infinispan / infinispan-core /に依存)で定義された6つのnamedCacheのうちの1つのみが表示されます。 4.2.0.ALPHA1)は、そこで定義されていないものとともに作成されます。
上記で参照されているjbosswikiの記事がエンティティキャッシュについて説明している場合、namedCacheの「エンティティ」を参照していると思われます。ただし、そのキャッシュを作成する方法が見つかりません。(余談ですが、infinispan-configs.xmlのローカルクエリは作成されますが、infinispan-configs.xmlのタイムスタンプは作成されません。代わりに、Hibernateの他の場所で定義する必要があるUpdateTimestampsCacheを受け取ります。)指定
私たちのpersistence.xmlで、関連するエンティティに注釈を付ける@ javax.persistence.Cacheableは(infinispan CacheManager JMX属性に従って)エンティティキャッシュを作成します(エンティティのパッケージ修飾されたJavaクラス名として名前が付けられます)が、未使用のようですJMX統計がローカルクエリの高いヒット率を示している場合(そして実際、そのようなキャッシュヒットクエリの優れたパフォーマンス)。
私の恐れは根拠がなく、隠れて、infinispanは、複数のHQLクエリの結果セットで返された場合でも、エンティティの情報を1回だけ保存していますか?そうでない場合、infinispan-configs.xmlのnamedCache、エンティティデータの重複ストレージを回避するために使用される「エンティティ」を取得する適切な方法は何ですか?最後に、休止状態のレベル2タイムスタンプキャッシュとして、「org.hibernate.cache.UpdateTimestampsCache」ではなく、infinispan-configs.xmlのnamedCache「timestamps」をどのように使用できますか?
hibernate - Hibernateエンティティの変更/削除は、同じエンティティ名を含むクエリキャッシュを無効にしますか?
私はいくつかのブログから読んだ
タイムスタンプキャッシュは、各テーブルの最終更新タイムスタンプを追跡します(このタイムスタンプは、テーブルが変更されるたびに更新されます)。クエリキャッシュがオンの場合、タイムスタンプキャッシュは1つだけであり、すべてのクエリキャッシュインスタンスで使用されます。クエリキャッシュでクエリがチェックされるたびに、タイムスタンプキャッシュでクエリ内のすべてのテーブルがチェックされます。テーブルの最後の更新のタイムスタンプがクエリ結果がキャッシュされた時間よりも大きい場合、エントリは削除され、ルックアップは失敗します。
メソッドを使用してエンティティをロードget()
し、を呼び出して保存したとしますsaveOrUpdate()
(または)を呼び出してエンティティを削除しましたdelete()
。
これらすべての場合において、タイムスタンプキャッシュは変更されたテーブルを追跡し、クエリキャッシュにそれらのテーブルのキャッシュされたクエリ結果を無効にしますか?
ありがとうございました!
mysql - MySQL Query Cache と Memcached を同時に使用する
どちらも素晴らしいと思いますが、両方のキャッシング システムを同時に使用することは可能ですか? 経験はありますか?
web-services - EF 1 Web サービス アプリケーションのメモリ使用量が呼び出しごとに増加し続ける - クエリ キャッシュの問題?
賢い人たちがここで私を助けてくれることを願っています!
Entity Framework 1 と EFPocoAdapter を使用した ASP.NET Web サービス アプリがあります。この Web サービスを実行しているアプリ プールのメモリ使用量は、Web サービスの呼び出しごとに増え続けています。現在、メモリの使用量を監視しており、1GB を超え始めたら、アプリ プールをリサイクルしてメモリを解放します。
'using' ステートメントで各 Web メソッドのオブジェクト コンテキストをインスタンス化して、オブジェクト コンテキストを開いたままにしないようにします (efprof で観察)。
そこで、Ants メモリ プロファイラー 7 を使用して何が起こっているかを追跡し、Web サービスへの最初の呼び出しの後 (この時点で EF フレームワークがそのビューを生成するなど)、スナップショットを作成しました。次に、同じ呼び出しを行い、別のスナップショットを取得します。Ants は、最後のスナップショット以降に作成された新しいオブジェクトがほぼすべて System.Data.Common.QueryCache.QueryCacheManager に関連していることを示しています。
キャッシュのポイントはパフォーマンスの向上であることはわかっていますが、私たちの場合、メインのアプリ/ビジネスの性質上、これらの呼び出しを繰り返す可能性は最小限であるため、すべてのクエリ プランをキャッシュする必要はないと思います。
それで、私の質問.....このキャッシングをオフにする方法はありますか、それとも私はここで間違ったツリーを吠えていて、私が気付いていない何か他のことが起こっていますか?
これに対する答えを求めてウェブ全体を検索しましたが、速度/パフォーマンスの向上のためのエンティティ追跡に関連していると思われる MergeOption プロパティしか見つかりませんでした。
hibernate - Hibernate、第2レベルのキャッシュおよびクエリキャッシュ
私はEhcacheでHibernateを使用しています(重要ではないと思います)。ユーザーがログインすると、私は彼の電子メールで彼を識別し、その後のすべての呼び出しに彼の電子メールを使用します。さて、電子メールは私の「休止状態のID」(私@Id
が注釈を付けたもの)ではないので、クエリをロードして、クエリキャッシュに保存する必要があります。ただし、ユーザーがログアウトすると、それ以降にログインしている他のユーザーと共有する領域内に保存されているため、キャッシュから明示的に削除することはできません。
私の質問は次のとおりです。メソッドを使用してデータベースに再度アクセスすることなく、ユーザーを2次キャッシュにロードできますか(したがって、エビクションが容易になります)session().get(user)
?ここに別のポイントがあります。ユーザーが更新されると、このユーザーのクエリキャッシュが正しくなくなります。ユーザーを更新するときに更新したい