In addition one Java thread will tie up one native OS thread. A On Monday, September 8, 2014 10:50:13 AM UTC+8, Yuexiang Zhang wrote: > > Not only Wildfly but also most of mainstream pure java webservers use > thread pool to handle http requests. Nginx-Clojure can also be configurated > to use thread pool with one or many JVM instances. > > Advanced Java webservers use Java NIO (I/O multipexing) to do the first > phrase (Http request accepting and simple parsing) then run user business > flow with thread pool. The first phrase only need one or very few threads. > But at the second phrase (using thread pool) largely existing Java Socket > API based libraries such as JDBC drivers, Http Client are blocking so if > there are many connections they 'll eat up all threads and make the > webserver hang because a OS can only support less threads than connections. > By the way threads in JVM are not cheap and they use more memory than pure > native OS threads and OS threads are pre-emptive and scheduled at constant > time slice so if there are too many threads scheduling will cost too many > of cpu cycles to do real works. > > For large scalar application one JVM instance is really not enough. > Typical scenario is we use serveral Java webservers such as tomcat, jetty, > glassfish etc, and > put a reverse proxy such as Nginx, Haproxy, Apache in the front of them. > And Nginx-Clojure make this work easier because it can automatic embed JVM > instances into Nginx worker processes and we need not maintain too many > webservers. > > Since JDK 5, JVM instances can share Class data to reduce memory usage and > the startup time for java applications. And on our enviroment typically we > use coroutine based sockets to work with Apache http client , Solr client > ,etc. Coroutines are cooperative and cheaper than threads and be created as > much as our memory can bear. > > Xfeep > > On Mon, Sep 8, 2014 at 3:27 AM, gvim <gvi...@gmail.com> wrote: > >> On 07/09/2014 17:51, Yuexiang Zhang wrote: >> >>> >>> From Nginx-Clojure the most attractive things to us is : >>> >>> 1. Nginx's architecture is Master + Worker processes, Nginx-Clojure >>> embed one JVM in per Worker process. So if any of worker process >>> crashes, the other JVM instances can still work and the Master will >>> recreate a new Worker process embedding with a new JVM instance. >>> 2. Nginx's perfect performance when handle even over 10 thousand >>> connections >>> 3. Coroutine based socket let old Java Socket API based app/libraries >>> won't lock a thread anymore >>> 4. IO (Coroutine based socket, Asynchronous socket & Channel) are on >>> top of Nginx IO API which is more worldly-wise than Java NIO on huge >>> scalar server application. >>> 5. JVMs are not goot at huge memory management. Configurable multiple >>> JVM instances (is the same number of Nginx Worker processes) will >>> manage less memory. e.g. we have ten Nginx Worker processes in one >>> Nginx instance every JVM instance will only manage 1/10 memory >>> 6. Nginx already has many modules / features such as rate limit , >>> spdy , pages cache, image filter etc. Most of them maybe are >>> difficult or less effective to be implemented in pure Java world. >>> >>> >> I'm fairly new to Clojure/JVM but I was under the impression Java >> webservers such as Wildfly (= JBoss) had a reputation for managing memory >> efficiently by spawning threads, ie. only a single JVM instance required? >> Your scenario with multiple JVMs/1 per worker sounds like a much bigger >> memory footprint but, as I said, I'm new to Java. >> >> >> gvim >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- You received this message because you are subscribed to a topic in >> the Google Groups "Clojure" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/ >> topic/clojure/baqWfrei8CE/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > >
-- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
