> Hmm, exactly how do you route the requests through the apache server? It > almost sounds like your applikation is restarted every now and then, iirc > Apache only servers a limited amount of requests per server thread.
Interesting if true, but I assume there would be an error if 2 instances of the app both tried to grab the same port. In: /etc/apache2/sites-available/000-default.conf which is the only config file we are using right now, I have this: ProxyPass /user/ http://127.0.0.1:34002/ ProxyPassReverse /user/ http://127.0.0.1:34002/ ProxyPass /user http://127.0.0.1:34002/ ProxyPassReverse /user http://127.0.0.1:34002/ This works fine. The requests proxy through Apache and back. I repeated the line to deal with the trailing "/" On Monday, September 15, 2014 2:45:13 AM UTC-4, Linus Ericsson wrote: > > If you turn on verbose gc for the JVM you could at least rule out GC > pauses. > > Hmm, exactly how do you route the requests through the apache server? It > almost sounds like your applikation is restarted every now and then, iirc > Apache only servers a limited amount of requests per server thread. > > If this somehow started a new JVM per apache thread things would go > strange. What does $ps ax --forest say? > > /Linus > Den 15 sep 2014 06:44 skrev "Shantanu Kumar" <kumar.s...@gmail.com > <javascript:>>: > >> Few thing to consider: >> 1. Which API calls pause? If only certain calls pause, then probably you >> have something specific to suspect. Try adding a dummy REST call - see if >> that call pauses while others do. >> 2. Is any of your services running on a t1.micro or a burst-oriented EC2 >> instance on AWS? Try changing the instance type in that case. >> 3. Can you mock out the components that you suspect could be a problem? >> Begin by mocking out everything you suspect, then replace the mock with >> actual impl one component at a time until you isolate the problematic >> component. >> 4. Have you tried running a profiler? >> 5. Have you tried printing GC info? Maybe this could be useful: >> http://blog.ragozin.info/2011/09/hotspot-jvm-garbage-collection-options.html >> >> Shantanu >> >> On Monday, 15 September 2014 09:45:14 UTC+5:30, larry google groups wrote: >>> >>> >>> I have an embarrassing problem. I convinced my boss that I could use >>> Clojure to build a RESTful API. I was successful in so far as that went, >>> but now I face the issue that every once in a while, the program pauses, >>> for a painfully long time -- sometimes 30 seconds, which causes some >>> requests to the API to timeout. We are still in testing, so there is no >>> real load on the app, just the frontenders, writing Javascript and making >>> Ajax calls to the service. >>> >>> The service seems like a basic Clojure web app. I use Jetty as the >>> webserver, and the libraries in use are: >>> >>> Ring >>> >>> Compojure >>> >>> Liberator >>> >>> Monger >>> >>> Timbre >>> >>> Lamina >>> >>> Dire >>> >>> When someone complains about the pauses, I will go test the service, and >>> I can hit with 40 requests in 10 seconds and it has great performance. The >>> pauses actually seem to come after periods of inactivity, which made me >>> think that this had something to do with garbage collection, except that >>> the pauses are so extreme -- like I said, sometimes as much as 30 seconds, >>> causing requests to timeout. When the app does finally start to respond it >>> again, it goes very fast, and responds to those pending request very fast. >>> >>> But I have to find a way to fix these pauses. >>> >>> Right now I packaged the app as an Uberjar and put it on the server, >>> spun it up on port 24000 and proxied it through Apache. I put a script in >>> /etc/init.d to start the app using start-stop-daemon. >>> >>> Possible things that could be going wrong: >>> >>> Maybe Jetty needs more threads, or maybe less threads? How would I test >>> that? >>> >>> Maybe the link to MongoDB sometimes dies? (Mongo is on another server at >>> Amazon) How would I test that? >>> >>> Maybe it is garbage collection? How would I test that? >>> >>> Maybe I have some code that somehow blocks the whole app? Seems unlikely >>> but I'm trying to keep an open mind. >>> >>> Maybe the thread pool managed by Lamina sometimes gets overwhelmed? How >>> would I test that? >>> >>> Maybe when Timbre writes to the log file it causes things to pause? (But >>> I believe Timbre does this in its own thread?) How do I test that? >>> >>> This is a small app: only about 1,100 lines of code. >>> >>> I don't have much experience debugging problems on the JVM, so I welcome >>> any suggestions. >>> >>> >>> >>> >>> >>> >>> >>> -- >> 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 the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, 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.
