[JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545
by Jakub Markos (JIRA)
[ https://issues.jboss.org/browse/ISPN-6580?page=com.atlassian.jira.plugin.... ]
Jakub Markos commented on ISPN-6580:
------------------------------------
They are disabled in current master. With db0890270 and default standalone.xml, the access log is indeed TRACE logging every operation. But I turned it off, so the regression between 628819461 and db0890270 is not related to excessive logging.
> Hotrod performance regressions after ISPN-5342 ISPN-6545
> --------------------------------------------------------
>
> Key: ISPN-6580
> URL: https://issues.jboss.org/browse/ISPN-6580
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Server
> Reporter: Jakub Markos
> Assignee: William Burns
> Attachments: jfr_recordings.zip, pom.xml, Reproducer.java
>
>
> There were 2 recent regressions in hotrod performance, one between commits dd5501c5e and 628819461 and the second one between 628819461 and db0890270. I didn't look for the exact commits, so the name of the issue might not be 100% exact...
> It is easily reproducable locally with a single server instance, reproducer attached.
> The numbers on my machine:
> ||Build commit||Puts time||Gets time||
> |dd5501c5e|21|74|
> |628819461|26|102|
> |db0890270|48|224|
> The JFR recordings (attached, captured is only the part of the test with gets) for db0890270 show a lot of time is spent in HotRodDecoder#resetNow(), and also the allocation rate goes from 100MB/s for dd5501c5e to over 1GB/s for db0890270. There are no glaring differences between dd5501c5e and 628819461.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6580?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-6580:
---------------------------------------
We should really disable access logs out of the box
> Hotrod performance regressions after ISPN-5342 ISPN-6545
> --------------------------------------------------------
>
> Key: ISPN-6580
> URL: https://issues.jboss.org/browse/ISPN-6580
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Server
> Reporter: Jakub Markos
> Assignee: William Burns
> Attachments: jfr_recordings.zip, pom.xml, Reproducer.java
>
>
> There were 2 recent regressions in hotrod performance, one between commits dd5501c5e and 628819461 and the second one between 628819461 and db0890270. I didn't look for the exact commits, so the name of the issue might not be 100% exact...
> It is easily reproducable locally with a single server instance, reproducer attached.
> The numbers on my machine:
> ||Build commit||Puts time||Gets time||
> |dd5501c5e|21|74|
> |628819461|26|102|
> |db0890270|48|224|
> The JFR recordings (attached, captured is only the part of the test with gets) for db0890270 show a lot of time is spent in HotRodDecoder#resetNow(), and also the allocation rate goes from 100MB/s for dd5501c5e to over 1GB/s for db0890270. There are no glaring differences between dd5501c5e and 628819461.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6580?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-6580:
-------------------------------------
Assignee: William Burns
> Hotrod performance regressions after ISPN-5342 ISPN-6545
> --------------------------------------------------------
>
> Key: ISPN-6580
> URL: https://issues.jboss.org/browse/ISPN-6580
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Server
> Reporter: Jakub Markos
> Assignee: William Burns
> Attachments: jfr_recordings.zip, pom.xml, Reproducer.java
>
>
> There were 2 recent regressions in hotrod performance, one between commits dd5501c5e and 628819461 and the second one between 628819461 and db0890270. I didn't look for the exact commits, so the name of the issue might not be 100% exact...
> It is easily reproducable locally with a single server instance, reproducer attached.
> The numbers on my machine:
> ||Build commit||Puts time||Gets time||
> |dd5501c5e|21|74|
> |628819461|26|102|
> |db0890270|48|224|
> The JFR recordings (attached, captured is only the part of the test with gets) for db0890270 show a lot of time is spent in HotRodDecoder#resetNow(), and also the allocation rate goes from 100MB/s for dd5501c5e to over 1GB/s for db0890270. There are no glaring differences between dd5501c5e and 628819461.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-6580) Hotrod performance regressions after ISPN-5342 ISPN-6545
by Jakub Markos (JIRA)
Jakub Markos created ISPN-6580:
----------------------------------
Summary: Hotrod performance regressions after ISPN-5342 ISPN-6545
Key: ISPN-6580
URL: https://issues.jboss.org/browse/ISPN-6580
Project: Infinispan
Issue Type: Bug
Components: Remote Protocols, Server
Reporter: Jakub Markos
Attachments: jfr_recordings.zip, pom.xml, Reproducer.java
There were 2 recent regressions in hotrod performance, one between commits dd5501c5e and 628819461 and the second one between 628819461 and db0890270. I didn't look for the exact commits, so the name of the issue might not be 100% exact...
It is easily reproducable locally with a single server instance, reproducer attached.
The numbers on my machine:
||Build commit||Puts time||Gets time||
|dd5501c5e|21|74|
|628819461|26|102|
|db0890270|48|224|
The JFR recordings (attached, captured is only the part of the test with gets) for db0890270 show a lot of time is spent in HotRodDecoder#resetNow(), and also the allocation rate goes from 100MB/s for dd5501c5e to over 1GB/s for db0890270. There are no glaring differences between dd5501c5e and 628819461.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-6579) Migrate near cache demo to a separate repo
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-6579:
-------------------------------------
Summary: Migrate near cache demo to a separate repo
Key: ISPN-6579
URL: https://issues.jboss.org/browse/ISPN-6579
Project: Infinispan
Issue Type: Task
Components: Demos and Tutorials
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 9.0.0.Alpha2, 9.0.0.Final
And also remove the jnp-[client|server] dependencies.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months
[JBoss JIRA] (ISPN-5916) Filtering by cache status in management console doesn't work
by Pedro Zapata (JIRA)
[ https://issues.jboss.org/browse/ISPN-5916?page=com.atlassian.jira.plugin.... ]
Pedro Zapata commented on ISPN-5916:
------------------------------------
There's no property in the model, but a statistic refresh would have to be issued for each cache and update the model before being able to filter. Currently, no cache stats is retrieved and the cache status is not updated. That might involve a large number of DMR requests in the case of many caches being displayed.
> Filtering by cache status in management console doesn't work
> ------------------------------------------------------------
>
> Key: ISPN-5916
> URL: https://issues.jboss.org/browse/ISPN-5916
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.1.0.Alpha2
> Reporter: Jiří Holuša
> Assignee: Vladimir Blagojevic
>
> Page: "Caches" tab -> click on certain cache container: list of caches in that container is shown.
> On the left side, these are options how to filter the shown caches and you can also filter by cache status - Indexing, Offline, Rebalancing, Split. When I click any of them, nothing happens, it looks like they do nothing since I definitely don't have any cache rebalancing or indexed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 8 months