Can I make a suggestion that lies outside of the realm of PerlSvc?  Take a
look at Win32::ProcFarm.  I regularly spin of 30 processes to execute tasks
that are high-latency but low-CPU and low-bandwidth.  What Win32::ProcFarm
lets you do is define a single parent process that in turn spins off a bunch
of child processes.  The child processes are assigned tasks sequentially
from a pool of tasks (pretty much your standard worker thread pattern in a
multi-threaded language), and Win32::ProcFarm takes care of all the
communications issues. To improve the performance, have the parent process
assign blocks of tasks rather than single tasks (since there's some latency
between the parent and the child processes, this will amortize the latency
over a large group of tasks - for instance, have the child processes execute
variable requests in blocks of 100).

I'm sending this to the whole list because there may be others in the same
boat, but if you have further questions, please contact me off-list.

--Toby Everett


		-----Original Message-----
		From:	David Hares [mailto:dhares@[...].net]
		Sent:	Thursday, February 28, 2002 12:35 PM
		To:	Jan Dubois; Kenneth Olving
		Cc:	Pdk
		Subject:	RE: PerlSvc questions

		The script does SNMP polling.  The code started life as
MRTG, but has now been munged to my specfic requirements.  The problem is
		that I'm retrieving lots of data.  SNMP libraries block,
waiting for responses.  I found that if a process could query 10,000
		variables in 5 minutes, if you ran 5 copies of the process
each looking at 2,000 variables you'd finish in under 1 1/2 minutes.  On
		my quad CPU box, the results were even more dramatic.

		I've been running the script by running it in 5 different
windows.  Not very nice.  I researched services and some of the controls
		they had for starting/restarting and decided to try to
create a service.  The idea worked.  I have 5 running.  Each time I make a
		change though, I have to create 5 different exe files.  I
thought I'd be able to determine what service I was running as though, and
		get by with one exe.  In fact, I can.  I can specify the
service name dynamically on -install.  On install, I create a config file.
		Each service, when it starts, looks for a config file, and a
config lock file.  If the service finds a config file without a
		corresponding lock file, it creates the lock file and
executes the config file.  Of course, I don't know which service latched
onto
		which config file.  I could do a lot better if I could just
get my service name dynamically.

		That's the short story.


		-----Original Message-----
		From: pdk-admin@[...].com
		[mailto:pdk-admin@[...].com]On Behalf Of Jan
Dubois
		Sent: Thursday, February 28, 2002 3:39 PM
		To: Kenneth Olving
		Cc: David Hares; Pdk
		Subject: Re: PerlSvc questions


		On Thu, 28 Feb 2002 15:21:24 -0500, "Kenneth Olving"
		<kenneth.olving@[...].com>  wrote:

		Hi ken,

		> And, that place is usually the registry. As an experiment,
find your
		> service in the registry after it's installed - for FOO, it
would be
		> in HKLM\System\CurrentControlSet\Services\FOO. Add your
params to the
		> ImagePath and you can access them normally with GetOpt or
whatever.
		> It's not too hard to add that stuff using some tied hash to
the
		> registry or whatever.

		Yes, that's the only way to do what David wants, I'm afraid.

		> However, this is probably frowned upon as the contents of
ImagePath
		> is really handled by the SCM during CreateService calls
etc. A probably
		> better and common approach is to create a subkey to the
above mentioned
		> key, something like
HKLM\System\CurrentControlSet\Services\FOO\Parameters.
		> Now go hogwild with settings under Parameters. If you still
need/want
		> to use GetOpt et al, just read a string from under
Parameters, read it
		> in startup and manipulate ARGV before calling GetOpt.

		This doesn't work.  Note that David won't know which FOO to
look into
		until after he has retrieved the value for FOO from
Parameters.

		> These are just some possibilities of course; nothing
stopping you from
		> having your params in a file in a known location or
whatever...

		Same problem: He wants to run multiple services that are
only
		differentiated by service name.  All his services would now
look into the
		same configuration file because they don't know yet who they
are.

		> I think you would benefit from reading up on
msdn.microsoft.com on
		> exactly what a service is and how it fits in - it's really
not to bad,
		> and might clear up a few things about why PerlSvc looks
like it does.
		> 
		> Jan: I can't remember and don't have my old service code
handy, but I
		> seem to remember that SCM actually calls in to the service
at startup
		> with the name of the service and/or the registry path it's
listed under
		> - providing that information would make it simple to get to
something
		> like a 'Parameters' key...perhaps even some framework code
on how to
		> deal with this easily could be contrived...:-)

		No, the only information you get is the ImagePath:

	
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ser
vices_9ju6.asp?frame=true

		Yes, you get the filename for your service too (the first
element of
		ImagePath).  It is available in Perl as $0.  But David wants
to use the
		same executable for all services, this would always be the
same too.

		As I said above, I don't think there is a way around
modifying ImagePath
		to implement Davids scheme.

		I would still be interested in the more general question:
What is the
		advantage of having multiple identical services running that
just use
		different names?

		Cheers,
		-Jan

		_______________________________________________
		PDK mailing list
		PDK@[...].com
		To unsubscribe:
http://listserv.ActiveState.com/mailman/mysubs

		_______________________________________________
		PDK mailing list
		PDK@[...].com
		To unsubscribe:
http://listserv.ActiveState.com/mailman/mysubs
_______________________________________________
PDK mailing list
PDK@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs