I think this benchmark is fundamentally flawed. It compares apples to oranges
and is too simplistic
to generalize anything. JSON serialization? Really? You aren't testing web
framework performance
with that. Interpreted languages in the same benchmark as compiled languages?
How can you even try
> Isn't scaling out using multiple instances is the way to go?
Yes, but I would better use more than one thread per process.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h
On Tue, May 7, 2013 at 2:30 PM, Denis Stepanov wrote:
> Finally they have added test that actually tests web frameworks -
> "Fortunes test" but no Tapestry yet. Does anyone is going to contribute the
> fortune test?
>
> >> Performance can be black magic.
> >>
> >> On the one hand, I've heard some
Finally they have added test that actually tests web frameworks - "Fortunes
test" but no Tapestry yet. Does anyone is going to contribute the fortune test?
>> Performance can be black magic.
>>
>> On the one hand, I've heard some specific things about Node.js performance
>> that are very positiv
Here is a latest framework benchmark:
http://www.techempower.com/benchmarks/#section=data-r4
How do you guys think about it?
于 2013/1/25 9:39, Howard Lewis Ship 写道:
Performance can be black magic.
On the one hand, I've heard some specific things about Node.js performance
that are very positive
Performance can be black magic.
On the one hand, I've heard some specific things about Node.js performance
that are very positive. Certainly, when developing for Node, the virtually
instance server startup is wonderful. Java has beaten us down into thinking
that code needs lots of time to start u
I was also surprised by the results when I saw them.
This was a C++ project, not java, but the performance characteristics wouldn't
be any different.
This was also proprietary project for one of my old companies so I can't
divulge anything else about it.
What I can tell you, it comes down to a ve
I find this very difficult to swallow, at least for java apps, unless, maybe,
you're using a java implementation that uses native threads instead of
lightweight java threads, then I might believe it. I would also believe it if
the async server is poorly written. And I can believe that many an as
I've done extensive ( no, not extensive, really, really, extensive, worthy of a
space research project extensive ) testing of async IO performance vs. threaded
server performance.
The conclusion is that unless you have over 10,000 active, users, async IO is
about 1/2 the performance of the usu
On Thu, 24 Jan 2013 09:26:45 -0200, Muhammad Gelbana
wrote:
Can someone clarify why would play! be better than tapestry in this test?
I guess only someone with play! internal architecture can tell you this
for sure. I also think that is probable that its usage of Netty
(https://netty.io
Can someone clarify why would play! be better than tapestry in this test ?
On Wed, Jan 23, 2013 at 4:10 PM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Wed, 23 Jan 2013 11:36:01 -0200, John wrote:
>
> That's interesting Thiago, in the chart JSP ranked slightly better than
>>
On Wed, 23 Jan 2013 11:36:01 -0200, John wrote:
That's interesting Thiago, in the chart JSP ranked slightly better than
Tapestry but not as well as play.
Where's this chart? By the way, as far as I know, Play doesn't use JSP nor
the Servlet API. Regarding Tapestry vs JSP, Tapestry has more
ivial test cases are unlikely to stretch the frameworks to reveal
substantial practical differences.
John
- Original Message -
From: Thiago H de Paula Figueiredo
To: Tapestry users
Sent: Monday, January 21, 2013 8:28 PM
Subject: Re: Tapestry performance
On Mon, 21 Jan 201
On Mon, 21 Jan 2013 17:52:12 -0200, Lenny Primak
wrote:
I'm pretty sure tapestry would blow JSF out of the water, just due to
the architecture differences.
As far as JSP, it is very hard to beat because it compiles directly to
java servlet code.
I don't think so, as the generated Java se
y users
> Sent: Sunday, January 20, 2013 2:54 PM
> Subject: Tapestry performance
>
>
> Hello everybody,
>
> I recently threw together a new page in the documentation about
> Tapestry performance. (Much of it plagiarizes mailing list posts from
> Howard.)
>
>
users
Sent: Sunday, January 20, 2013 2:54 PM
Subject: Tapestry performance
Hello everybody,
I recently threw together a new page in the documentation about
Tapestry performance. (Much of it plagiarizes mailing list posts from
Howard.)
http://tapestry.apache.org/performanc
llo everybody,
>
> I recently threw together a new page in the documentation about
> Tapestry performance. (Much of it plagiarizes mailing list posts from
> Howard.)
>
> http://tapestry.apache.org/performance-and-clustering.html
>
> It's really just a first draft at
> > I recently threw together a new page in the documentation about
> > Tapestry performance. (Much of it plagiarizes mailing list posts from
> > Howard.)
> >
> > http://tapestry.apache.org/performance-and-clustering.html
> >
> > It's really just a
Well done Bob!
Kalle
On Sun, Jan 20, 2013 at 6:54 AM, Bob Harner wrote:
> Hello everybody,
>
> I recently threw together a new page in the documentation about
> Tapestry performance. (Much of it plagiarizes mailing list posts from
> Howard.)
>
> http://tapestry.apach
Hello everybody,
I recently threw together a new page in the documentation about
Tapestry performance. (Much of it plagiarizes mailing list posts from
Howard.)
http://tapestry.apache.org/performance-and-clustering.html
It's really just a first draft at this point. So if anyone ha
> You're right. Maybe we should change the default tracker persistence from
> session to flash persistence? I do that in my projects using @Meta.
Personally I wish the form didn't persist anything until it needed it
so the session wasn't created. Client persistence isn't an option
because of the n
Em Fri, 18 Sep 2009 19:57:41 -0300, Josh Canfield
escreveu:
Last time I checked the Form component persists the tracker, which
means rendering a form puts something in your session. Every page in
the test has a form and so a different tracker would be persisted.
You're right. Maybe we shoul
> T5 doesn't use the session itself. That's exactly what puzzles me.
Last time I checked the Form component persists the tracker, which
means rendering a form puts something in your session. Every page in
the test has a form and so a different tracker would be persisted.
I haven't done any testin
Em Thu, 17 Sep 2009 18:31:11 -0300, Norman Franke
escreveu:
I'm puzzled by the retained size for 20 sessions.
Me too . . .
Is that due to how
he wrote the app and marked everything as @Persist, or is T5 really
that bad?
T5 doesn't use the session itself. That's exactly what puzzles me.
It's a mix; he's storing a lot of WebFlow style data in the session/ I
haven't looked at his code (it is downloadable) to see what else he is
doing. Ben Gidley's detailed T5 analysis didn't note an exceptional memory
utilization.
On Thu, Sep 17, 2009 at 2:31 PM, Norman Franke wrote:
> I'm puzzle
I'm puzzled by the retained size for 20 sessions. Is that due to how
he wrote the app and marked everything as @Persist, or is T5 really
that bad? I know I try to minimize the use of @Persist, but the post-
redirect model makes this much more difficult, seriously impairing one
key aspect of
This is the link?
http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
On Wed, Sep 16, 2009 at 4:07 PM, Howard wrote:
> Peter Thomas has created a detailed performance analysis of Wicket,
> Tapestry, Grails and Seam. It's an interesting read from non-Tapestry
> user
Peter Thomas has created a detailed performance analysis of Wicket,
Tapestry, Grails and Seam. It's an interesting read from non-Tapestry
user's perspective, and complements Ben Gidley's findings.
He's measuring raw performance and Wicket narrowly bests Tapestry in
most categories, with Seam pretty
28 matches
Mail list logo
