IIS/Perl - best combination?

Folks,

I've started working on an MSSQL/IIS/Perl site that is still CGI, like
ten years ago. While it sort of works for this particular site, it's not
pretty, it doesn't perform, and I'm not happy with this scenario.

So IIS and Perl being the invariants of our configuration, what are my
options when opening a perspective to move to a superior execution
model? I'm reading the ActivePerl documentation and other sites on the
net to find out just that. I have the following options on my radar for
now:

* ASP/PerlScript - looks promising
* PerlEx 3.0 - ditto (but see my thread on the DCOM issue)
* PerlIS - don't know yet
* FastCGI - not sure, would prefer to rely on ActivePerl

Anything else?

Anything you might have to report on the pros and cons of either of
these configurations?

--
Michael Ludwig
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: IIS/Perl - best combination?

On 10/08/2010 21:52, Michael Ludwig wrote:
> * FastCGI - not sure, would prefer to rely on ActivePerl
>

IIS7 FastCGI works with ActivePerl


Lyle

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: IIS/Perl - best combination?

Hi there

>Michael Ludwig wrote:
> * ASP/PerlScript - looks promising

We tried this in the early ages of ASP. The main problem for us was that wh=
en things failed it could be in the MS chain of code and we'd be stuck with=
a strange error code. Stability under heavy load was an issue, back then. =
I don't know about know...

> * PerlEx 3.0 - ditto (but see my thread on the DCOM issue)

We use this almost exclusively (unless we are doing some COM work with a si=
ngle-threaded component, then we use PerlIS). It performs brilliantly and o=
nce you get your head around the persistent code and data thing, you are of=
f. We have experienced some problems under extreme loads, though.

Did you find a solution to you DCOM issue? Did you try to run the sync-pass=
word script to see if it at least is the right symptom?

> * PerlIS - don't know yet

Works very well and if you use code that cannot be run in multi-threaded en=
vironments or that rely on a complete cleanup between two iterations, this =
could be the right tool. But if you load a bunch of modules everytime it ma=
y not give you the performance boost you are looking for...

>Lyle wrote:
>> * FastCGI - not sure, would prefer to rely on ActivePerl
>> =

> =

> IIS7 FastCGI works with ActivePerl

Do you have any experience with that, that you can share?


Best regards
Henning Michael M=F8ller Just


_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: IIS/Perl - best combination?

> -----Original Message-----
> From: activeperl-bounces@listserv.ActiveState.com
> On Behalf Of Lyle

> On 10/08/2010 21:52, Michael Ludwig wrote:
> > * FastCGI - not sure, would prefer to rely on ActivePerl
>
> IIS7 FastCGI works with ActivePerl

Thanks, Lyle. IIS7 - we're not there yet.

Michael
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: IIS/Perl - best combination?

> -----Original Message-----
> From: activeperl-bounces@listserv.ActiveState.com
> On Behalf Of Henning Michael M=F8ller Just

> >Michael Ludwig wrote:
> > * ASP/PerlScript - looks promising
> =

> We tried this in the early ages of ASP. The main problem for us was =

> that when things failed it could be in the MS chain of code and we'd =

> be stuck with a strange error code. Stability under heavy load was an =

> issue, back then. I don't know about know...

I hope I'll get time to explore this soon.

> > * PerlEx 3.0 - ditto (but see my thread on the DCOM issue)
> =

> We use this almost exclusively (unless we are doing some COM work with =

> a single-threaded component, then we use PerlIS). It performs =

> brilliantly and once you get your head around the persistent code and =

> data thing, you are off. We have experienced some problems under =

> extreme loads, though.

Many people do, with various technologies. :-) We won't have to handle
extreme load, so that doesn't scare me. I just want the site to appear
somewhat snappier. Unsurprisingly, CGI will never make that happen.

It is reassuring to me to get feedback from people actually using this tech=
nology. Much appreciated!

> Did you find a solution to you DCOM issue? Did you try to run the =

> sync-password script to see if it at least is the right symptom?

Not yet. But I'll get back to this issue and keep the list updated.

> > * PerlIS - don't know yet
> =

> Works very well and if you use code that cannot be run in =

> multi-threaded environments or that rely on a complete cleanup between =

> two iterations, this could be the right tool. But if you load a bunch =

> of modules everytime it may not give you the performance boost you are =

> looking for...

I'll give this a try, too. Thanks for your feedback! Gruß aus Hamburg!
--
Michael Ludwig
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

Re: IIS/Perl - best combination?

On 11/08/2010 09:48, Henning Michael M=F8ller Just wrote:
>> * PerlIS - don't know yet
>> =

> ...or that rely on a complete cleanup between two iterations...
> =



I'm very interested in how it achieves this complete clean up? Is it =

within Perl itself?



>> Lyle wrote:
>> =

>>> * FastCGI - not sure, would prefer to rely on ActivePerl
>>>
>>> =

>> IIS7 FastCGI works with ActivePerl
>> =

> Do you have any experience with that, that you can share?
> =


Unfortunately not much more than getting it working :( I did have a =

crack at making a module that would use FastCGI to make the Perl =

interpreter persistent, but clean up after each execution so any Perl =

script could run under it. Hence my interest in the previous statement.


Lyle

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: IIS/Perl - best combination?

Lyle wrote:
> On 11/08/2010 09:48, Henning Michael M=F8ller Just wrote:
>>> * PerlIS - don't know yet
>>> =

>> ...or that rely on a complete cleanup between two iterations...
>> =

> =

> I'm very interested in how it achieves this complete clean up? Is it =

> within Perl itself?

Ah, cleanup is perhaps the wrong word here. Jan Dubois will obviously be ab=
le to give the correct answer. I *think* what happens is that PerlIS has an=
thread ready for an interpreter so that when it needs to process a script =
a new interpreter is started up; it is then discarded at the end of executi=
on.

I experimented with some selective cleanup of namespaces in PerlEx some yea=
rs ago using Symbol::delete_package(). But that brought other problems (men=
tioned in the BUGS section of Symbol) that I didn't overcome at that time (=
read: the cost of doing it was higher that changing the code that needed it=
;-)


Best regards
Henning Michael M=F8ller Just


_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: IIS/Perl - best combination?

> -----Original Message-----
> From: activeperl-bounces@listserv.ActiveState.com
> On Behalf Of Lyle

> On 11/08/2010 09:48, Henning Michael M=F8ller Just wrote:
> >> * PerlIS - don't know yet
> >> =

> > ...or that rely on a complete cleanup between two iterations...
> =

> I'm very interested in how it achieves this complete clean up?
> Is it within Perl itself?

I share your interest. If I'm not mistaken, the complete interpreter
reset is one of the things that made PHP such a success with hosting
providers. I wonder if and how it can be achieved.

--
Michael Ludwig
_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: IIS/Perl - best combination?

On Wed, 11 Aug 2010, Henning Michael M=F8ller Just wrote:
> Lyle wrote:
>> I'm very interested in how it achieves this complete clean up? Is it
>> within Perl itself?
>
> Ah, cleanup is perhaps the wrong word here. Jan Dubois will obviously
> be able to give the correct answer. I *think* what happens is that
> PerlIS has an thread ready for an interpreter so that when it needs to
> process a script a new interpreter is started up; it is then discarded
> at the end of execution.

The threads are managed by IIS, PerlIS is just an ISAPI plugin (DLL)
that is loaded by IIS into the process that hosts these threads.

Note that you still must make sure all modules used under PerlIS are
thread-safe because the threads for one application pool all run within
a single process. So if you have a Perl module with XS code that stores
information in a static C variable, then you still have a race condition
when 2 requests are processed in parallel.

Cheers,
-Jan

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: IIS/Perl - best combination?

Jan Dubois wrote:
> Note that you still must make sure all modules used under PerlIS are
> thread-safe because the threads for one application pool all run within
> a single process. So if you have a Perl module with XS code that stores
> information in a static C variable, then you still have a race condition
> when 2 requests are processed in parallel.

Wowzer. OK, then I've misunderstood the requirements. So basically, if you =
are stuck with a module that is *not* thread-safe, you would need to have i=
t run by old-fashioned CGI, or alternatively, in a PerlEx pool with only a =
single interpreter?

Best regards
Henning Michael M=F8ller Just


_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs

RE: IIS/Perl - best combination?

On Wed, 11 Aug 2010, Henning Michael M=F8ller Just wrote:
> Jan Dubois wrote:
> > Note that you still must make sure all modules used under PerlIS are
> > thread-safe because the threads for one application pool all run
> > within a single process. So if you have a Perl module with XS code
> > that stores information in a static C variable, then you still have
> > a race condition when 2 requests are processed in parallel.
>
> Wowzer. OK, then I've misunderstood the requirements. So basically, if
> you are stuck with a module that is *not* thread-safe, you would need
> to have it run by old-fashioned CGI, or alternatively, in a PerlEx
> pool with only a single interpreter?

Yes, with the further caveat that you should not have additional interpreter
classes in the same PerlEx instance either that could load the same module.
Maybe that was implied by your statement, but I wanted to make sure nobody
tries to create several PerlEx thread pools inside a single IIS application
pool, and expect them to be isolated from each other: everything inside
a single IIS application pool will happen inside the same process.

Cheers,
-Jan

_______________________________________________
ActivePerl mailing list
ActivePerl@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs