Re^3: Perl concurrent access

Many thanks for this reply, that stops me wasting time optimising code etc! I may try and work out a 'ticketing' system, so when people want to create a PDF they can 'take a ticket' and wait in line for a slot. That way I can limit the number of pdf creation scripts in memory at any one time to two or three. I can then throw some more power at it, by upgrading the server from dual core to 8 or 16 core, and throwing more RAM at it.. then hopefully after my wallet recovers.. it should be ok!

Comment on Re^3: Perl concurrent access

Replies are listed 'Best First'.
Re^4: Perl concurrent access by leocharre (Priest) on Sep 10, 2009 at 15:35 UTC
Now, I'm not sure about the specifics of your situation. But, if you are generating some kind of report.. that is.. maybe one person requests pdf output once a day or so.. You could do things like.. Autogenerate the pdf output once a day (this is imagining you already know what the output is going to/should be ) Maybe instead of letting them download it.. When the request the pdf.. it can be sent via email to them instead. You would have to keep track of it- that the user making a request does not already have a request in progress. Another thing I would look into.. (possibly.. again.. if it's worth the human time (yours)!) is named pipes (fifo), and maybe in conjunction with daemonizing a process (In essence, the request is put in a queue).	[reply]
Re^4: Perl concurrent access by TienLung (Acolyte) on Sep 10, 2009 at 15:57 UTC
Unfortunately pre-generating the PDF is not an option. The whole system is essentially a web2print solution, users login to the system, build how they want the pdf to look using an html/js interface, and then when they are happy with how it looks, they hit 'build'. At the moment with only a few users it is relativly uncommon for more than 2 requests to happen at any one time, however due to new clients I am having to make the system ready for a much larger scale. Depending on how much the system needs to be scaled I am thinking of a system whereby when a user wants to build a pdf, it puts an entry into a database, this will be their 'ticket'. I will then run the script as a daemon, which will check for an entry in the database, process it, create the pdf, then remove the entry, and wait until another 'ticket' is collected.	[reply]
Re^4: Perl concurrent access by cdarke (Prior) on Sep 10, 2009 at 15:27 UTC
Have you tried profiling the script? See Devel::DProf I may try and work out a 'ticketing' system System V semaphores are useful for that. See IPC::SysV (although there are other ways to do it).	[reply]