[infinispan-issues] [JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545

[ https://issues.jboss.org/browse/ISPN-6580?page=com.atlassian.jira.plugin.... ] William Burns edited comment on ISPN-6580 at 5/4/16 11:42 PM: -------------------------------------------------------------- I tweaked my server to not have the execution group changes and the performance is the same as the old server. Unfortunately by doing this we cannot support async clients and event OOM will not be solved. Unfortunately it seems like the context switching caused by handing off the messages is causing a major performance hit for operations that don't do remote operations. I am thinking to fix this by possibly having a get operation performed on the handler thread instead of handing it off to the execution thread. Unfortunately this means for an async client the server could read multiple requests but only be able handle 1 remote get instead of possibly multiple in parallel, but other operations would work in parallel. This might be okay, but if the client has an outdated topology this could cause a major slowdown if it has to go remote. I am thinking I might want to add an extra handler that will delegate calls if no remote operations are required. Also if you have multiple servers this latency should be minimized quite a bit and this is why in my testing I didn't notice such a big performance issue since I was testing with 3 nodes. was (Author: william.burns): I tweaked my server to not have the execution group changes and the performance is the same as the old server. Unfortunately by doing this we cannot support async clients and event OOM will not be solved. Unfortunately it seems like the context switching caused by handing off the messages is causing a major performance hit for operations that don't do remote operations. I am thinking to fix this by possibly having a get operation performed on the handler thread instead of handing it off to the execution thread. Unfortunately this means for an async client the server could read multiple requests but only be able handle 1 remote get instead of possibly multiple in parallel, but other operations would work in parallel. This might be okay, but if the client has an outdated topology this could cause a major slowdown if it has to go remote. I am thinking I might want to add an extra handler that will delegate calls if no remote operations are required, possibly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)