Larry Leszczynski <[EMAIL PROTECTED]> writes:
[...]
> The above link mentions the memory benefits of having few perl intepreters
> among many threads e.g. if you have a mix of static and dynamic content.
> But it made me wonder what is the effect regarding the "spoonfeeding slow
> clients" scenar
Hi all -
> You use interpreter pool size control directives:
> http://perl.apache.org/docs/2.0/user/config/config.html#Threads_Mode_Specific_Directives
>
>
> You don't need to prevent anything. It's just that if your server uses
> very little modperl and mostly doing static requests, you can have
Tom Schindl wrote:
[EMAIL PROTECTED] wrote:
Greetings,
The problem is that the script takes more than 3 or 4 seconds to execute
sometimes.
So we have a script that takes 3-4 seconds to execute, each varaiable is
defined with my $var. and when the script ends it resets the value of the
variables usi
[EMAIL PROTECTED] wrote:
Greetings,
The problem is that the script takes more than 3 or 4 seconds to execute
sometimes.
So we have a script that takes 3-4 seconds to execute, each varaiable is
defined with my $var. and when the script ends it resets the value of the
variables using undef.
If multip
On Wed, 2004-09-22 at 19:37, [EMAIL PROTECTED] wrote:
> So we have a script that takes 3-4 seconds to execute, each variable is
> defined with my $var. and when the script ends it resets the value of the
> variables using undef.
>
> If multiple users execute the script within those 3-4 seconds wil
ot; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, September 22, 2004 3:59 PM
Subject: Re: Variables in memory.
> Stas Bekman wrote:
>
> > Tom Schindl wrote:
> >
> >> Thanks Stas for the full explaination. Indeed I didn&#x
Stas Bekman wrote:
Tom Schindl wrote:
Thanks Stas for the full explaination. Indeed I didn't know exactly
what's really going on behind the scences. Thanks for your
explaination I'm always learning something new when reading your
answers.
Thanks :)
Still on the one hand I recognize what you're
Tom Schindl wrote:
Thanks Stas for the full explaination. Indeed I didn't know exactly
what's really going on behind the scences. Thanks for your explaination
I'm always learning something new when reading your answers.
Thanks :)
Still on the one hand I recognize what you're trying to tell me, on
Stas Bekman wrote:
Thomas Schindl wrote:
When running with mp2 and worker mpm the case is slightly different:
1. Apache-starts and starts Apache-Child 1 which spawn Thread 1.1 and
Thread
1.2 and Apache-Child 2 which spawn Thread 2.1 and Thread 2.2
2. User1 hits Apache-Child 1 Thread 1.1 and sets t
Thomas Schindl wrote:
When running with mp2 and worker mpm the case is slightly different:
1. Apache-starts and starts Apache-Child 1 which spawn Thread 1.1 and Thread
1.2 and Apache-Child 2 which spawn Thread 2.1 and Thread 2.2
2. User1 hits Apache-Child 1 Thread 1.1 and sets the global $FOO from
Hi,
you'll have to give us more background information. I hope to get you right
but using globals to pass things between request doesn't work because you
can never tell which Apache-Child is used. This is true e.g. mp1 and mp2
with apache in prefork mode.
Take this:
1. Apache-starts and forks to
Greetings,
I'm having a problem with a script when accessed by
multipile users.
The script remembers the variables used by one user
and passes them on to another user.
What would be the best way to avoid this? Use
sessions and hold the variables in a uniqe hash per session?
Thank you.
D
On Wed, 22 Sep 2004 08:01:12 -0700
[EMAIL PROTECTED] wrote:
> Greetings,
>
> I'm having a problem with a script when accessed by multipile users.
> The script remembers the variables used by one user and passes them on
> to another user. What would be the best way to avoid this? Use
> sessions an
Greetings,
I'm having a problem with a script when accessed by
multipile users.
The script remembers the variables used by one user
and passes them on to another user.
What would be the best way to avoid this? Use
sessions and hold the variables in a uniqe hash per session?
Thank you.
On Sat, Dec 20, 2003 at 11:16:53AM -0500, Perrin Harkins wrote:
> Eric Sammer wrote:
> >I've had fantastic luck with MLDBM::Sync thus far, not that it's the all
> >in one wonder tool.
>
> I think it's a great tool, especially when you need easy access to
> complex data structures, but I wanted t
Eric Sammer wrote:
I've had fantastic luck with MLDBM::Sync thus far, not that it's the all
in one wonder tool.
I think it's a great tool, especially when you need easy access to
complex data structures, but I wanted to point the non-intuitive fact
that a local MySQL can be a great cache for a r
Perrin Harkins wrote:
Eric Sammer wrote:
Any DBM file or shared memory caching will be infinitely faster than
making a DB round trip.
Actually, it turns out that this is no longer true. MySQL is really
fast these days. A simple query on a local MySQL is faster than just
about anything except
Eric Sammer wrote:
Any DBM file or shared memory caching will be infinitely faster than
making a DB round trip.
Actually, it turns out that this is no longer true. MySQL is really
fast these days. A simple query on a local MySQL is faster than just
about anything except IPC::MM or BerkeleyDB (
Chris Ochs wrote:
I have an application where known users connect, and normally I do a db
query to get their configuration information. What I would like to do is
preload all of this information into memory, say into a global hash where
all the mod perl processes can access it.
You want to use one
I have an application where known users connect, and normally I do a db
query to get their configuration information. What I would like to do is
preload all of this information into memory, say into a global hash where
all the mod perl processes can access it.
I could have each process load the
20 matches
Mail list logo
