Re: [Catalyst] Catalyst benchmark 5.7 vs 5.8 - new test

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

Re: [Catalyst] Catalyst benchmark 5.7 vs 5.8 - new test

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:

Re: [Catalyst] Catalyst benchmark 5.7 VS 5.8

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 -

Re: [Catalyst] Catalyst benchmark 5.7 vs 5.8 - new test

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

Re: [Catalyst] Problem with index.tt2

David Silva wrote: Hi again, I'm following the book "Catalyst - Accelerating Perl Web Application Development" by Jonathan Rockway (2007) with Catalyst 5.80013. And in chapter 3 the autor says to create an index.tt2 page and said that we don't need to do nothing cos Catalyst will recognize t

Re: [Catalyst] Problem with index.tt2

"we don't need to do nothing" parses as "we need to do something." Specifically, you missed: TEMPLATE_EXTENSION => '.tt2' also, this book has some errata: http://www.packtpub.com/view_errata/book/catalyst-perl-web-application -Wade On Tue, Sep 29, 2009 at 5:30 PM, David Silva wrote: > Hi

Re: [Catalyst] Catalyst benchmark 5.7 vs 5.8 - new test

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

[Catalyst] Problem with index.tt2

Hi again, I'm following the book "Catalyst - Accelerating Perl Web Application Development" by Jonathan Rockway (2007) with Catalyst 5.80013. And in chapter 3 the autor says to create an index.tt2 page and said that we don't need to do nothing cos Catalyst will recognize the index. I start the se

Re: [Catalyst] Catalyst benchmark 5.7 vs 5.8 - new test

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

Re: [Catalyst] Catalyst benchmark 5.7 vs 5.8 - new test

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

Re: [Catalyst] Catalyst benchmark 5.7 VS 5.8

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

Re: [Catalyst] Re: Calling Controller Methods from inside begin or auto.

Aristotle Pagaltzis schrieb: > * monkey [2009-09-29 14:35]: >> Is there another way to do the above without having to write >> the auth handling at the top of every method used to display >> pages? > > Chained dispatch. Do an auth check early in the chain, then the > actions down the chain don’t

Re: [Catalyst] Re: Calling Controller Methods from inside begin or auto.

On Tue, 2009-09-29 at 14:39 +0200, Aristotle Pagaltzis wrote: > * monkey [2009-09-29 14:35]: > > Is there another way to do the above without having to write > > the auth handling at the top of every method used to display > > pages? > > Chained dispatch. Do an auth check early in the chain, then

[Catalyst] Re: Calling Controller Methods from inside begin or auto.

* monkey [2009-09-29 14:35]: > Is there another way to do the above without having to write > the auth handling at the top of every method used to display > pages? Chained dispatch. Do an auth check early in the chain, then the actions down the chain don’t need to do it. Regards, -- Aristotle P

[Catalyst] Calling Controller Methods from inside begin or auto.

Hello, So I have a site I'm building that requires authentication, but only to selected pages. By default I want to require that an authenticated user is found, but in certain controllers I want to disable this. I was originally thinking about doing this by creating a auth_required() method call i

[Catalyst] Re: Speaking of Perls ... which is the preferred version for current Catalyst development?

* Joe Landman [2009-09-29 14:30]: > Has this been fixed in 5.10.1? Yes. Regards, -- Aristotle Pagaltzis // ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable

[Catalyst] Speaking of Perls ... which is the preferred version for current Catalyst development?

Hi Folks: We've been using Catalyst for a while now, for a variety of products/projects we build/market/support. Until recently, our platform has been Perl 5.8.8 based. For a number of reasons, we needed to go to a 5.10 based platform for our other (not-Cat) tools. Catalyst had a fairl

Re: [Catalyst] Catalyst benchmark 5.7 vs 5.8 - new test

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

Re: [Catalyst] Re: Catalyst benchmark 5.7 VS 5.8

Fayland Lam wrote: 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. do you know how to do a real benchmark? the siege result shows 5.7 is better under pressure. I didn't actually do any 'real' benchmarking for this,

Re: [Catalyst] Catalyst benchmark 5.7 VS 5.8

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

Re: [Catalyst] Catalyst benchmark 5.7 VS 5.8

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

Re: [Catalyst] Catalyst benchmark 5.7 VS 5.8

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

Re: [Catalyst] Catalyst benchmark 5.7 VS 5.8

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

Re: [Catalyst] Catalyst benchmark 5.7 VS 5.8

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