Has anyone else found that PerlDesk tends to eat resources quite heavily?

It refuses to run if we add RLimitMem, RLimitCPU and RLimitNPROC to the virtual host entry - even if the settings are pretty high.

We're reluctant to ban it because many of our clients use it, I just wondered if anyone else found it to be quite resource intensive.

i was just about to install that too!

we have not seen anything like this at all on any of our servers. What CP are you running?

Yes, it's a pig. It's CGI/Perl. Not even mod_perl.

interesting..

Are there any other help desks LIKE perldesk (becuase it looks good) but not such a resource hog?

perhaps something in php? doenst matter to me

any know of any?

Not a free one but a good one, PHPSupportdesk.

www.phpsupportdesk.com

-Nordic

Originally posted by Nordic
Not a free one but a good one, PHPSupportdesk.

www.phpsupportdesk.com

-Nordic

if you can forgive the constantly bugs in the upgrades.

We actually worked alot with PHPSupportDesk fixing bugs etc and very much enjoy the helpdesk.

Its very well coded

There's no reason for a Perl program that's ran as CGI to be a resource hog. Indeed, mod_perl or fastCGI would be better, but to save overhead. It's not that much a difference if it's coded properly. The guy that created perldesk is a cool person, and I'm sure if there's anything wrong causing that, he'll fix it. There's no reason to worry about how something runs and what something is coded in, if it's coded well. CGI isn't _that_ bad, and unless you are getting hundreds of thousands of hits on a complex CGI script each day, it should work just fine (and I don't see the need for things like control panel's and support ticket systems, etc., to have to run as a web server module with the process embedded in the httpd process itself, unless you have some seriously ridiculous and very frequent amount of hits on them every minute.) That's to say, to be clear, that a well coded program, in about any language or any interface -- while it can be more efficient, you reallyu shouldn't notice any problems or any difference, unless you get tons of hits -- otherwise it's not coded to be efficient and it won't matter if you embed it or not into the httpd process. So, it again would have to be something else that's the cause, especially since I don't think a control panel or support system will ever get enough hits that often to make any noticeable difference whatsoever -- unless you are benchmarking it by executing these programs 1,000 times or more a minute to see how it would uphold with that many concurrent accesses (then I'd have to ask "why"). :-)