On 3/6/06, Ryan Bowman <[EMAIL PROTECTED]> wrote: > RMI-IIOP. We have around 100-ish clients connected to the server, > people creating orders, adding items to orders, people printing > orders, picking orders, verifying each line item on the order, making > POs, etc...I don't really know how many connections, but I'd say lots. > As for data, some people are retreiving info about a single product, > anywhere from just name, price, qty in stock, to retreiving past POs > that ordered thousands and thousands of parts.
Are you using stateless-session-beans or stateful-session-beans? > Some simple searches, such as retreive the product with a give product > number responding instantly on windows and sometimes being almost as > fast to taking 5 seconds. Browsing purchase orders by vendor can > take a few seconds to retreive a list of vendors, where it's > instantaneous on windows. How are you communicating to your database? Is it running on the same Linux machine? What database are you using? What is the output of "java -version" on both Windows and Linux? What is the output of "ps -fe | grep java" on Linux when the app is running? I'm looking for the command-line args... Do the same on Windows... Oh wait! :-) What version of JBoss are you running? > Dual Intel Xeons, actually. Xeon is ambiguous to me. I haven't followed Intel closely ever since the Itanium nightmare. I've lost all faith in their server-class lines. Old Xeons are 32-bit with 33-bit memory allocation. Using a trick similar to old DOS XMS you can use up to 16GB of RAM. New Xeon processors are 64-bit (x86-64 instruction set?) and can allocate seemingly endless amounts of RAM with a flat memory model. Is this correct? Can someone correct me if I'm wrong? Is this a 64-bit chip? How much RAM is in the machine and how much RAM is the jboss process using? What is your -Xmx setting for the JVM on Linux? > > What is the output of these commands (run as root): > > uname -r > 2.6.13-15-smp > > > sysctl net.ipv4.tcp_tw_recycle > 0 > > > sysctl net.ipv4.tcp_keepalive_intvl > 75 > > > sysctl net.ipv4.tcp_fin_timeout > 60 These settings are the defaults, and are fine if you're not rotating a lot of TCP connections. If you're using HTTP w/o pipelining or stateless-session-beans, then you'll use a LOT of unique TCP connections between the clients and the server. When you're client is done with the TCP connection, the socket goes into a FIN_WAIT or TIME_WAIT state on the server for quite some time. I've had to tweak these kernel settings in the past to get Linux to move sockets out of the TIME_WAIT state quickly so socket resources could be reused by new connections. This is actually a security feature of Linux (to leave sockets in a timewait state for a while), but can affect network performance for certain types of applications. While your Linux server is serving many clients (100 concurrent if you can do that), check to see how many sockets are in a state other than ESTABLISHED. Run: netstat -tn | grep -v ESTABLISHED While you're at it, what does your CPU look like when running with 100 clients? Run: top -n 1 The fact is that Linux takes longer on Linux with identical hardware and software stack (java version 1.x, Jboss version x, etc.) -- right? So, we need to find out where you are bound. Are you network bound? Are you CPU bound? Are you memory bound? Are you I/O bound? Also, as far as Solaris goes -- do you have SATA drives with a BIOS RAID? Solaris 10 doesn't support SATA RAID well as far as I can tell. I believe your boot problem is related to that. Many newer BIOSes allow you to run your SATA drives in a look-like-an-ATA-drive mode. This would allow Solaris to see the drive at boot (if this indeed is your problem). -Bryan /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
