For the JPA tests, I wonder if different persistence.xml settings
might
be interesting to use. For example, adding
"<shared-cache-mode>NONE</shared-cache-mode>" to
https://github.com/codylerum/FrameworkBenchmarks/blob/ee7-wildfly/ee7-wil...
would disable the second level cache for persistence providers that have
a second level cache enabled by default (e.g.
https://wiki.eclipse.org/EclipseLink/Examples/JPA/Caching).
Perhaps we could also see runs with
"<shared-cache-mode>ALL</shared-cache-mode>" via an alternative
persistence unit definition. Which would allow a second level cache to
be enabled. Perhaps we could also add the various vendor specific hints
to enable the second level cache (e.g. <property
name="hibernate.cache.use_second_level_cache" value="true"/> and
<property name="openjpa.DataCache" value="true"/>)
Should also add @Cacheable(true) to the entities to go with this.
I'm not sure if there will be any impact for the SingleQuery test but
there could be differences for the other JPA tests.
On 02/12/2014 12:14 PM, Cody Lerum wrote:
> I've had this queued up for a bit but Stuart suggested I hold off
> until Wildfly went final so here it is.
>
> Some of you are probably aware of a Web Framework Benchmark project
> that is being put on by TechEmpower
> (
http://www.techempower.com/benchmarks/). They are currently up to the
> 8th round with 90 participating "frameworks". Undertow as been around
> for a few rounds and is routinely at or near the top of the charts.
>
> My goal here is to incorporate EE7 into these results with Wildfly
> providing the implementation. There are a lot of different ways to go
> here, but my preference is to stay portable with the application so
> that if another EE7 implementation wanted to use the same code it
> would be an apples to apples comparison. IMO this means for example
> that it shouldn't dip down into undertow/hibernate/resteasy/etc
> specific features that wouldn't be available on other application
> servers. Stick to EE7 API.
>
> There currently are 6 tests
>
> 1. Plaintext: Simple "Hello World!" Text response. Not that
> interesting and not dynamic. Implemented via JAX-RS.
>
https://github.com/codylerum/FrameworkBenchmarks/blob/ee7-wildfly/ee7-wil...
>
> 2. JSON Serialization: "Hello World" placed into a new object and then
> serialized out to JSON. Again not really a real world thing since
> nothing dynamic is happening here. Implemented via JAX-RS.
>
https://github.com/codylerum/FrameworkBenchmarks/blob/ee7-wildfly/ee7-wil...
>
> 3. Single Query: Select a single random result from a database and
> serialize out to JSON. First real world test. Implemented via JAX-RS,
> CDI, JPA.
https://github.com/codylerum/FrameworkBenchmarks/blob/ee7-wildfly/ee7-wil...
>
> 4. Multiple Queries: Select a specified number of random results from
> database one by one. Add to list and serialize out to JSON.
> Implemented via JAX-RS, CDI, JPA.
>
https://github.com/codylerum/FrameworkBenchmarks/blob/ee7-wildfly/ee7-wil...
>
> 5. Data Updates: Select a specifed number of random results from
> database one by one and update a value on each of them. Then return
> the result via JSON. Implemented via JAX-RS, CDI, JPA.
>
https://github.com/codylerum/FrameworkBenchmarks/blob/ee7-wildfly/ee7-wil...
>
> 6. Fortunes: Select all from database and store in a list. Add a new
> result and sort. Display sorted results as an html table. Implemented
> via JSF, CDI, JPA.
>
https://github.com/codylerum/FrameworkBenchmarks/blob/ee7-wildfly/ee7-wil...
>
> Since 1 and 2 are handled so well by undertow and really aren't
> anything someone would do real world with an application server I
> could see dropping them and just not participating in those tests.
> Unless anyone thinks differently.
>
> On the other tests it would be helpful if you could review the code to
> see if there are better/faster ways to accomplish the same tasks
> without dipping into implementation specific features that would not
> be portable.
>
> Thanks!
>
> -C
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev