Well you perhaps stepped on the issue, the db. Depending on nature of your db interaction they just might not run concurrently on db side. Would even depend on what MySQL engine you are using. Of you have managed to measure call response time then I am sure you can measure the time reach can takes in the db. You might see that that is where mac time variance is occurring compared to a sequential call.
Nitish -----Original Message----- From: "James Radke" <[email protected]> Sent: 22-10-2014 21:32 To: "[email protected]" <[email protected]> Subject: Re: [OpenBD] Open source package using BlueDragon limiting API callsto 2 simultaneously I think that I solved the concurrent connections issues, there were actually two different issues: 1.) The .NET config needed to be changed, as mentioned by Jason King 2.) The NGINX config had to change to allow more than two inbound transactions per IP address. Once both of those changes were made I was then able to send in multiple concurrent transactions at one time. Which leads me to a follow up question: If I submit 10 sequential transactions to an .cfc API, it takes an average of 2.95 seconds to run all 10 back to back. If I send all 10 of these in so they are running concurrently, I see the average response time of 1.65 seconds. this doesn't add up, because when running sequentially it is taking, on average .295 seconds per transaction (plus transport time), whereas with the concurrent transactions it ends up taking the longest one 1.65 seconds to run (plus transport time). It seems like there is still something else in nginx / tomcat / bluedragon that is not releasing everything concurrently. I am using MySql, and I made sure that the maximum number of db connections is set to 100, so it is not the database that is causing the issue (at least I don't think it is). Does anyone have any other ideas as to what else could be bottlenecking the concurrent transactions so they don't run as optimally as they should? Thanks, Jim On Tuesday, October 21, 2014 12:50:13 PM UTC-5, Al Holden wrote: A quick search leads me to suspect that this is happening over on the .NET side of things: http://stackoverflow.com/questions/866350/how-can-i-programmatically-remove-the-2-connection-limit-in-webclient Al On 10/21/2014 9:39 AM, Jason King wrote: How are you determining only 2 connections are allowed to run? User experience? Logs? Application Feedback? I wonder where in the stack it's being throttled. Is the throttling limited to API calls? What about http requests to a .html resource? What about http requests to a standard .cfm resource? Are these throttled in anyway? How is the API being called? Example code? On Tue, Oct 21, 2014 at 11:19 AM, James Radke <[email protected]> wrote: I am using an open source software package, Razuna, installed as follows: 1.) Ubuntu OS 2.) NGINX v1.4.6 3.) Tomcat 4.) BlueDragon 5.) Razuna Community Edition (coldfusion based product) Everything is working on the open source application, but when I attempt to call the API's provided in the system (set up as a cfcomponent) from a .Net multi-threaded application for the api calls to allow for as quick processing as I can, the cfcomponent only allows 2 simultaneous connections to run, all others are queued up, and released as one finishes. I have searched through the Ubuntu, NGINX, and Tomcat settings, and there is nothing within those that should be throttling me when I call this cfcomponent API. Is there a setting in BlueDragon somewhere that would be limiting me, by default, to only allow two simultaneous connections to the cfcomponent API ? Thanks, Jim -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout. -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout. -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout. -- -- online documentation: http://openbd.org/manual/ http://groups.google.com/group/openbd?hl=en --- You received this message because you are subscribed to the Google Groups "Open BlueDragon" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
