EhCache version upgrade from 2.10 to 3.10.8

[siddudivya]

Hi Team,

I work on a Java Netty based application. And I currently use 2.10 version.
I am upgrading my application to 3.10.8.
As part of it, I am doing some scale testing on both the versions.
I see the throughput is reduced after upgrading the Ehcache 3.10.

Throughput on version 2.10 is 1.63 Million per minute while 3.10 version throughput is 1.52 Million per minute.

Below is the Ehcache configuration
EhCache 2.10

<cache name="purchase-orders"
     maxEntriesLocalHeap="300000"
     eternal="false"
     timeToIdleSeconds="900"
     memoryStoreEvictionPolicy="LRU"
     transactionMode="off">

    <persistence strategy="none"/>

</cache>

Ehcache 3.10

<cache alias="purchase-orders">
     <key-type>java.lang.String</key-type>
     <value-type>java.lang.Object</value-type>
     <expiry> 
     <tti unit="seconds">900</tti>
    </expiry>
    <resources>
      <heap unit="entries">300000</heap>
   </resources>
 </cache>

1. Can you throw some light on why the throughput has reduced with the new version?
2. I use only On Heap Config, is it good practice to use java.lang.Object as value type as I am observing EhCache giving serialization/deserialization exception on the Cache Initialization. Though the exception, I see the application is functioning properly.
3. Does EhCache apply Serialization/Deserialization for On-Heap configuration also. If so in which all scenarios will it apply?

Note: Both Cache configurations are same. No changes just version upgrade

[SamuelBussmann]

One possibility is that the CacheConfiguration has storeByValue set to true (AFAIK the default).
If it's set to false the keys will be stored as reference to the given key object.

[Shaquarib]

For the configuration you've shown:

heap unit="entries">300000 is an appropriate on-heap configuration.
java.lang.Object is legal, but use the concrete value type if you know it.
Heap-only native Ehcache 3 does not serialize/deserialize merely because the value type is Object.
By default, heap entries are stored by reference.
Serialization is required for off-heap/disk/clustered tiers and can also occur when using copy-by-value/serializing copiers.
JCache is a particularly important exception, because its default store-by-value behavior can introduce serialization.
Your ~6.7% throughput reduction is more likely to be an implementation/expiry/concurrency/benchmark difference than serialization unless your application is actually using JCache or a copier.