No, the firewall is in front of the load balancers and the servers are separated from the network by the dmz. At some point there will be a reverse proxy in there somewhere (they tell me - I'm not a network engineer), but at the moment it's not open to the internet so I just have it directly opened to the db.
Thanks for the chat anyway. I have not used a profiler for a Win32 web server before. Do you have any recommendation? -marc --- Peter Lin <[EMAIL PROTECTED]> wrote: > sounds like you have a big big mainframe, so I also > doubt the database > server is an issue. Is there any firewall between > tomcat and the database > server? it could be the firewall is limiting the > number of connections and > therefore forcing the db connection pool to wait > longer than it should to > create a new connection. > > beyond that, about the only way would be to start > tomcat using a profiler > and see exactly what is blocking. > > peter > > > On 12/15/05, Marc Richards <[EMAIL PROTECTED]> wrote: > > > > No, the db is actually our world-wide enterprise > > server. It's got plenty of capacity for handling > many > > hundreds of thousands of daily transactions. When > I'm > > pounding the web app I literally can not even see > my > > activity on the machine and the disk arms are all > > calm. It's made for tougher stuff than I'll ever > be > > able to throw at it (due to JDE client programs > being > > so chatty, it's necessary to have a very powerful > db > > when you run OneWorld). > > > > It's kind of hard to track how many open db > > connections there are from the db end because > normally > > there are many thousands to begin with and the > number > > fluctuates by leaps and bounds just as a course of > > doing regular business. > > > > I'm not sure that my sessions are of too much > concern > > at the moment either because when I check the > server > > boxes I'm seeing that Tomcat is only using between > 200 > > and 400 mg of RAM and there is 4gb available. I > don't > > have a short session kill time (I think it's two > hours > > at the moment), but I am failing them out to disk > > every few minutes, so inactive sessions should be > > staying out of physical memory. And by the low > memory > > consumption of Tomcat under load, I'd say that > part is > > probably working ok (and also because I can see > all of > > the db records in the session table). > > > > I haven't gotten any complaints from the db on the > > session table itself, but that doesn't mean that > there > > isn't collusion because there could be some > locking > > issues taking place that would cause session > backups > > and restores to take on some latency. The db > won't > > complain about a locking issue and I haven't been > able > > to find any myself, but due to the fact that each > > connection appears to open, read/write and then > > abandon, locks would come and go so quickly that I > > probably wouldn't be able to see them anyway. > > > > I did notice that the db performance optimizer was > > spending some extra time analyzing the sessions > table, > > but I think that's because it regularly gets a > bunch > > of records pumped to it and then it clears out as > > sessions become invalidated. It's really quite > > under-used compared to most of the JDE tables on > the > > system. > > > > I was concerned about the maxThreads for a time > (and > > actually did have a problem because Apache's was > set > > higher and puking when it over-ran). But I got > tired > > of tweaking for this and just set it at 5000 to > see > > what would happen. I think the default is only > 50, so > > I thought 10x would represent a 'big' site. Am I > > wrong? It didn't change a thing by setting it > that > > high. How do you check the queue depth? I'm not > sure > > I'm familiar with that one... > > > > - > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
