Re: Embperl vs. Mason

2003-12-18 Thread Angus Lees
At Sat, 13 Dec 2003 15:10:23 +0100, Stefan Cars wrote:
> I'm looking for some facts on why Mason would be better than Embperl. I have
> been using Embperl in alot of projects and think it works great. I don't see
> any reason at all to move to Mason but it would be interesting to know how
> things differs.

I've had a cursory look at some Mason stuff lately ("customising" RT..)

Mason seems to have more mindshare (or at least a louder userbase or
something).  I've heard a few people say that Mason documentation is
much better than Embperl's (particularly with examples), but I haven't
actually read any of Mason's docs yet ;)

Technically, Mason is slower than Embperl (its pure perl).  The Mason
error page is way better than Embperl's.  I believe Mason has better
caching "scalability" (it dumps cached output to disk rather than
keeping it in memory).  The Mason %INIT% block makes page globals a
little more manageable than they are in Embperl.  I /really/ don't
like the Mason syntax, I find it too intrusive on both the perl and
HTML parts.  I've also found the Embperl::Object "base" way of
templating makes a lot more sense than the usual include mechanisms
found in toolkits.  "Extras" like %udat, %mdat, HTML escaping, etc are
manual addons with Mason.  Afaik there is no scope for other syntaxes
in Mason (eg RT uses Template::Toolkit for its email templates), or
any of the funky Embperl HTML context-sensitive magic stuff (table
loops, etc).

Oops, that turned into why Embperl is better than Mason ;)

The Mason benefits (error handler, documentation, caching) wouldn't be
too hard add to Embperl -- the reverse isn't at all true.  Personally,
I think Embperl is a much better choice for new projects.

-- 
 - Gus


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



memory usage

2003-12-18 Thread Hans de Groot
Hello,

I use Embperl for a few years now and I am sure I am not using it in the most
efficient way.

I only use the %udat,%fdat features.
I usally create pages that look like this:
[*
some perl here
store all output in $ouput
use http_headers_out followed with and exit() if I need to redirect.
*]

[+$output+]

This works great and really do not need all the extra's Embperl offers.

I do have one problem. My apache processes take a lot of memory.
Every request of a page it grows in size. I limited the "max request per child"
to 200 to prevent them from becoming to big, but spawning of a new child is not
really fast.

How do I prevent, or minimize the loss of memory?

I tried clearing all variables but it does not seem to help.

I could be my lack of knowlege about perl.

I usually clear vars like this:
%myhash=(); undef %myhash;
$template=''; undef $template;

But it seems this does not help.

People warned me about using the [* *] why is that?

Anyway some hints how to prevent apache processes from growing every request
would be nice. (or how to minimize this)

Thank you.

Hans de Groot










-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: memory usage

2003-12-18 Thread Donovan Allen
Hans de Groot wrote:

I usally create pages that look like this:
[*
some perl here
store all output in $ouput
use http_headers_out followed with and exit() if I need to redirect.
*]
[+$output+]

 

Unless you need the "local" scope of the [* *] blocks, you might try the 
[- -] instead and see if that fixes your problem.  Change it on one page 
and repeatedly call that page while watching the memory use.

I have never had memory problems using [* *], but that may be because I 
only use them for loops around html output.  I generally stick with [- 
-] blocks.

I do have one problem. My apache processes take a lot of memory.
 

Apache + any mod_perl tend to take a lot of memory anyway, however some 
of it is shared between processes.

Every request of a page it grows in size. How do I prevent, or minimize the loss of memory?
 

One other thing to be aware of is that if you are using modules, the 
variables in the module need to have proper scope (such as my() in 
functions and methods), otherwise you will get what "appears" to be a 
memory leak.

Getting all the "use" lines from your code and putting them into one 
document where you can comment them out, refresh the page, and check 
memory is a dirty but quick was to isolate a module that has not 
declared proper variable scope.

It is possible that things have changed, but as I recall default perl 
installs rarely (if ever?) use versions of malloc() that allow 
deallocation of used memory while running (providing that your OS even 
supplies one).  Your best tactic in general is to use memory carefully 
in practice and find what is causing the memory consumption and fixing it.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: embperl using DSO

2003-12-18 Thread Gerald Richter
Saadiq wrote:
> I'm trying to set up another instance of apache for some testing and
> I'm having very little luck.  I've compiled Apache to use DSO and
> modperl is a DSO object.  The embperl docs say that I am not to set up
> embperl in httpd.conf but I can't seem to find instructions on what to
> do instead.  Could someone give me a pointer in the right direction?

The problem which caused segfaults when loading Embperl at startup when
mod_perl is a DSO should be fixed in newer mod_perl versions, so you can
load it at startup. For Apache 2 and Embperl 2, you need to load the Embperl
shared library anyway to get it working

Gerald


--
Gerald Richter ecos electronic communication services gmbh
IT-Securitylösungen * dynamische Webapplikationen * Consulting

Post:   Tulpenstrasse 5  D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED]  Voice:   +49 6133 939-122
WWW:http://www.ecos.de/  Fax: +49 6133 939-333
--
|
|   ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
|
+-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Pr server data

2003-12-18 Thread Gerald Richter
Kaare Rasmussen wrote:
> I want to save some data per Apache server - NOT per user or per page.
>
> Is this possible with Embperl? Or will I have to study mod_perl ?
>
> The data is a POE client object.

You can simply put it in a varibale and it will stick. Since Embperl normaly
cleans up all package variables you can put it in a different namespace e.g.

$datasave::poeclient = POE -> .

Gerald


--
Gerald Richter ecos electronic communication services gmbh
IT-Securitylösungen * dynamische Webapplikationen * Consulting

Post:   Tulpenstrasse 5  D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED]  Voice:   +49 6133 939-122
WWW:http://www.ecos.de/  Fax: +49 6133 939-333
--
|
|   ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
|
+-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Cookie and Cookieless sessions

2003-12-18 Thread Gerald Richter
Stefan Cars wrote:
> What is the status of this, Gerald ? Is that implemented yet ??
>
> smodeUDatUrl = 4
>
>   The session id for the user session will passed as a part of the
> URL. NOT YET IMPLEMENTED!!
>

No it's not implemented, but what you want is

smodeUDatParam

(smodeUDatUrl would do something like //path/data.epl)

Gerald


>
> Kind Regards,
> Stefan Cars
>
> -Original Message-
> From: Gerald Richter [mailto:[EMAIL PROTECTED]
> Sent: den 2 december 2003 16:20
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Cookie and Cookieless sessions
>
> Hi,
>
>>
>> Basically what I want to do is to have standard cookied sessions,
>> however if user doesn't support cookies then it falls back to
>> cookieless sessions.
>>
>> Can I
>> a)  Have both cookie and cookieless sessions running at the same time
>> - if so how do I configure this.
>
> In Embperl 2.0 look at EMBPERL_SESSION_MODE
>
>> b)  Optionally pass the session_id as a param - so if there isn't a
>> cookie, but there is a param then it loads the session using the
>> param session id.  If so whats the correct name of the session id
>> (as in ?session_id=sds232sd23dsgrfgf355565)
>>
>
> If you set session_mode correctly Embperl will do this for you
> automaticly
>
> Gerald
>
>
>>
>> Regards
>>
>>
>> Pete
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> Gerald Richter ecos electronic communication services gmbh
> IT-Securitylösungen * dynamische Webapplikationen * Consulting
>
> Post:   Tulpenstrasse 5  D-55276 Dienheim b. Mainz
> E-Mail: [EMAIL PROTECTED]  Voice:   +49 6133 939-122
> WWW:http://www.ecos.de/  Fax: +49 6133 939-333
> --
>>
>>   ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
>>
> +-
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

--
Gerald Richter ecos electronic communication services gmbh
IT-Securitylösungen * dynamische Webapplikationen * Consulting

Post:   Tulpenstrasse 5  D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED]  Voice:   +49 6133 939-122
WWW:http://www.ecos.de/  Fax: +49 6133 939-333
--
|
|   ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
|
+-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: memory usage

2003-12-18 Thread Gerald Richter
>
> I do have one problem. My apache processes take a lot of memory.
> Every request of a page it grows in size.

mod_perl httpd takes a lot of memory, that can't be changed. Every new
request will eat up more memory, because Perl code is compiled. If you
request only one page more than once memory useage should stay the same,
that's how you can test if any of your code has a memory leak.

BTW Which Embperl version do you are using?

Gerald

--
Gerald Richter ecos electronic communication services gmbh
IT-Securitylösungen * dynamische Webapplikationen * Consulting

Post:   Tulpenstrasse 5  D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED]  Voice:   +49 6133 939-122
WWW:http://www.ecos.de/  Fax: +49 6133 939-333
--
|
|   ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
|
+-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Apologies for the large attachement

2003-12-18 Thread Gerald Richter

>My sincere apologies to all for the large test.log attachment. I had no
idea it was so big. I should have checked.

It never made the way through the list...


>Test 117 in mod_perl mode gives.
>
>#117 match/div.htm... ERR:Internal Server Error

Looks like either Embperl or mod_perl has a problem with Perl 5.8.2

I didn't have the time to check Embperl against Perl 5.8.2, but hopefully
will do this during the next two weeks

Gerald



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]