Tomas Doran wrote:
Toby Corkindale wrote:
It's interesting to note the headline figures have 5.71 performing 316
tps, vs 5.80 making only 283 tps.
The very important thing you haven't noted (unless I missed it) is what
perl version this benchmark was conducted under.
Some benchmarking was d
Possibly related anecdote. My main personal app went from 5 second
start ups to start ups of well over a minute when I went from 5.7 to
5.8. I had a handful of Controller and Model classes in which I had
written test code and then removed it all so they looked something like-
package MyApp:
Carl Johnstone wrote:
Toby Corkindale wrote:
(CentOS 5 was one of the operating systems that came with the
badly-patched Perl with the slow bless performance..
although I'm sure it's been patched by now?
ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/
)
Was patched last year -
Tomas Doran wrote:
Toby Corkindale wrote:
It's interesting to note the headline figures have 5.71 performing 316
tps, vs 5.80 making only 283 tps.
The very important thing you haven't noted (unless I missed it) is what
perl version this benchmark was conducted under.
Ah, sorry, I didn't men
i meant 100 resultsources+controllers :-) not models
2009/9/30 Tomas Doran :
>
> On 29 Sep 2009, at 22:12, Oleg Pronin wrote:
>
>> 5.8 !!TWICE!! slower at startup than 5.7 under any perl version. This
>> is annoying because i have 100 models and i do not want to wait 10
>> secs while it is starti
On 29 Sep 2009, at 22:12, Oleg Pronin wrote:
5.8 !!TWICE!! slower at startup than 5.7 under any perl version. This
is annoying because i have 100 models and i do not want to wait 10
secs while it is starting in debug.
Patches welcome to optimise things for your wacky use-case given
appropr
5.8 !!TWICE!! slower at startup than 5.7 under any perl version. This
is annoying because i have 100 models and i do not want to wait 10
secs while it is starting in debug.
2009/9/29 Tomas Doran :
> Toby Corkindale wrote:
>>
>> It's interesting to note the headline figures have 5.71 performing 31
On Tue, 29 Sep 2009, Carl Johnstone wrote:
What everybody else in this thread is referring to as "shared" memory is
actually the amount of memory that hasn't needed to be duplicated because of
the copy-on-write semantics within the Linux kernel. Unfortunately there's
currently no easy way I know
Toby Corkindale wrote:
It's interesting to note the headline figures have 5.71 performing 316
tps, vs 5.80 making only 283 tps.
The very important thing you haven't noted (unless I missed it) is what
perl version this benchmark was conducted under.
Some benchmarking was done before 5.8 was r
Tobias Kremer wrote:
and I hope that 3480 is really not the amount of memory that is shared
because that'd be quite low.
Shared memory indicates things which are shared at a library linking
level (e.g. libc is a shared object which both processes will share).
This has nothing to do with the
On Tuesday 29 September 2009 03:44:33 am Carl Johnstone wrote:
> What everybody else in this thread is referring to as "shared" memory is
> actually the amount of memory that hasn't needed to be duplicated because
> of the copy-on-write semantics within the Linux kernel. Unfortunately
> there's cur
Tobias Kremer wrote:
> So, what's a better way to find out how much memory is shared? On our
> production servers "top" shows
>
> VIRT: 70116, RES: 64m, SHR: 3480
>
> and I hope that 3480 is really not the amount of memory that is shared
> because that'd be quite low.
It's a different type of sha
Toby Corkindale wrote:
> (CentOS 5 was one of the operating systems that came with the
> badly-patched Perl with the slow bless performance..
> although I'm sure it's been patched by now?
> ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/
> )
Was patched last year - stop spreading
On Mon, Sep 28, 2009 at 12:23 PM, Tomas Doran wrote:
> top totally doesn't show how much RAM is shared by copy on write at all, and
> so is misleading you here.
So, what's a better way to find out how much memory is shared? On our
production servers "top" shows
VIRT: 70116, RES: 64m, SHR: 3480
Toby Corkindale wrote:
It's interesting to note the headline figures have 5.71 performing 316
tps, vs 5.80 making only 283 tps.
Memory usage (for this small app) has increased by 4MB, but is
presumably shared. I guess I should look into that more.
Here are some new analysis of memory usage on
On Monday 28 September 2009 12:56:36 am Fayland Lam wrote:
> I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8
Benchmark, as requested. View this message at http://p3m.org/pfn/3499 if your
mailer is too high-tech for fixed-width text.
The Setup:
Linux 2.6 OpenVZ, on Qu
Fayland Lam wrote:
I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8
I have a vested interest in knowing the difference between the two
versions as well, so knocked up a "proper" test.
I have two identical virtual machines, only on one I installed
Catalyst::Runtime 5.
Sorry to interrupt, but that is a !!WOW!!
I used CentOS a few weeks ago and i have to say that it could be better if
it was updated... But seems that they are with internal problems ...
2009/9/28 Stuart Watt
> Toby Corkindale wrote:
>
> (CentOS 5 was one of the operating systems that came with
Toby Corkindale wrote:
(CentOS 5 was one of the operating systems that came with the badly-patched
Perl with the slow bless performance..
although I'm sure it's been patched by now?
ie. http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/
)
This issue is still listed as open for Cento
6:36 +1000 (EST)
Subject: [Catalyst] Catalyst benchmark 5.7 VS 5.8
I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8
here is the result from our server: http://scsys.co.uk:8001/34323
the background is
Catalyst 5.7011 VS Catalyst 5.80013
CPU: Intel(R) Core(TM)2 Quad CP
Fayland Lam wrote:
from the top, each httpd takes 20M more RAM in 5.8 compared with 5.7
No, that'll be 20Mb of RAM _in total_, as all of those pages should be
shared between your apache processes (given that you're preloading your
application in the parent process).
top totally doesn't show
I'm wondering if someone here did a benchmark between Catalyst 5.7 and 5.8
here is the result from our server: http://scsys.co.uk:8001/34323
the background is
Catalyst 5.7011 VS Catalyst 5.80013
CPU: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz
RAM: 4G
OS: Centos5
from the top, each httpd tak
22 matches
Mail list logo
