Re^10: Timing concerns on PerlEX/Mod

So, the mod_perl hack to avoid loading time just trades that for piecemeal, on-the-fly memory allocations and copying. And the more you preload, the worse it gets. Hence your problems I think.

I thought that might have been the issue as well but the strange thing is if I run 3 sites under the same shared pool in IIS/perlex and an apache instance with mod_perl.(all on the same 1 server)

with 1 instance of IIS being public, while other 2 are lets say different sub domain but not public. Same for apache..the public instance experiences these issues while the none public ones and apache run perfectly. so unless it hit a cap limit to the size a namespace can be(is that possible?) or it places a lock on the certain portion of the namespace(ram) too many times limiting the connections...but these are all guess work...is there any way to test this?

On another not I will experiment with Tiny a bit to see if it will come in useful in the future, thanks!

Comment on Re^10: Timing concerns on PerlEX/Mod_Perl

Replies are listed 'Best First'.
Re^11: Timing concerns on PerlEX/Mod_Perl by BrowserUk (Patriarch) on Jul 27, 2008 at 08:56 UTC
so unless it hit a cap limit to the size a namespace can be(is that possible?) Like I said. Mod_perl and Apache aren't things I have much experience of. Just enough to know that I don't want any more. But, I'll venture an opinion based upon the discussion so far and my knowledge of Perl in general. And say that I think it highly unlikely that this has anything to do with namespace capacities, which are unlimited within the constraints of memory availability, and which you say you are not running out of. Without seeing what you're doing--and from the sound of things, this is far too much to dump here in a post--it is really hard to suggest what would be the cause of a sudden and prolonged slowdown like this. But, once again, I'll hazzard a guess. I'm betting it is to do with access to the DB. Specifically, I'm betting that you're running out of db handles and are having to wait until the DBserver times out some existing connections before it will allow you to make a new connection. I guessing that you are instantiating new connections somewhere in your libraries, but never closing them. That's nothing more than a lot of supposition (I had to check back through the thread to see if you'd actually mention using a DB) and a vague memory of something similar. The quickest way to determine if I'm right would be to go check you DB logs for a time period when one of these slowdowns has occured and see what if any relevant errors you can find. If that is the cause, there might be a relatively easy fix. Good luck. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^12: Timing concerns on PerlEX/Mod_Perl by Anonymous Monk on Jul 27, 2008 at 17:42 UTC
I am using a database(mysql), but not persistent connections. So a database handle is opened and closed every time. Though the Time::HiRes start is done before the database handle is opened and checked after it is closed, so I would think if that was the issue, the time slowdown would be noticed in my benchmark. The database server is also on its own dedicated server so it can handle quite a lot of connections.	[reply]