> 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

This is a stupid question on my part, but how does Nginx manage memory for 
a JVM instance? If my app has a line in project.clj such as: 

  :jvm-opts ["-Xms100m" "-Xmx1000m" "-XX:-UseCompressedOops"])

then the memory is hardcoded, yes? Does Nginx have a way to ignore this and 
manage the memory without regard to Xmx settings? 







On Sunday, September 7, 2014 12:52:17 PM UTC-4, Xfeep wrote:
>
> Sorry I don't use Immutant + Wildfly and know little about it.
>
> The simple benchmarks including Immutant & Nginx-Clojure can be found 
> from HERE <https://github.com/ptaoussanis/clojure-web-server-benchmarks>. 
>
> 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.
>
>
> Xfeep
>
>
>
>
>
>
>
> On Sun, Sep 7, 2014 at 11:27 PM, gvim <gvi...@gmail.com <javascript:>> 
> wrote:
>
>> On 07/09/2014 13:45, Yuexiang Zhang wrote:
>>
>>>
>>>     0.2.5 (2014-09-07)
>>>
>>>  1. New Feature: Reference variables in jvm_options & different jvm
>>>     debug ports for jvm processes (issue #42)
>>>  2. New Feature: Server Sent Events(SSE) & Long polling (issue #41,
>>>     issue #36)
>>>  3. New Feature: Supports 64-bit JDK on 64-bit Windows (issue #40)
>>>  4. New Feature: Coroutine based socket supports JDK8 (issue #39)
>>>  5. New Feature: More easier to archive Sub/Pub services with Broadcast
>>>     Events to all Nginx workers (issue #39)
>>>  6. New Feature: Asynchronous Channel a wrapper of asynchronous socket
>>>     to make the usage easier (issue #37)
>>>  7. Enhancement: Fix--On Windows a little many write events happen and
>>>     these events seem useless (issue #35)
>>>
>>>
>>>  
>> What are the trade-offs, if any, compared with Immutant + Wildfly (on 
>> CentOS 6)? Memory usage is of particular interest.
>>
>> gvim
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> <javascript:>
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com <javascript:>
>> 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+u...@googlegroups.com <javascript:>.
>>
>> 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.

Reply via email to