Re: [julia-users] Re: Backend deployment for website
Sorry for the delay, I was finishing up my slides for JuliaCon, which incidentally address this exact topic. You can find the slides here: https://github.com/jminardi/jminardi.github.io/blob/master/files/JuliaCon-2015.pdf and I believe the video should be posted soon. I was using ZMQ to communicate with a long running process. In Julia there was a simple loop that just listened for instructions coming in over a ZMQ socket. On Wed, Jun 17, 2015 at 1:17 PM, Matthew Krick wrote: > Great stuff, seems like I've still got a bunch of research to do, > especially regarding ZMQ. > > Jack, I'm really interested in your approach of using your julia process > as a separate dockerfile. Could you explain what you meant by using a ZMQ > server when you needed more communication? > > On Tuesday, June 16, 2015 at 10:35:40 AM UTC-5, Matthew Krick wrote: >> >> I've read everything I could on deployment options, but my head is still >> a mess when it comes to all the choices, especially with how fast julia is >> moving! I have a website on a node.js server & when the user inputs a list >> of points, I want to solve a traveling salesman problem (running time >> between 2 and 10 minutes, multiple users). Can someone offer some advice on >> what's worked for them or any pros/cons to each option? Least cost is >> preferable to performance. >> >> >>1. Spawn a new node.js instance & solve using node-julia ( >>https://www.npmjs.com/package/node-julia) >>2. Use Forio's epicenter to host the code ( >>http://forio.com/products/epicenter/) >>3. Create a julia HTTP server & make a REST API ( >>https://github.com/JuliaWeb/HttpServer.jl) >>4. Host on Google Compute Engine (https://cloud.google.com/compute/) >>5. Host on Amazon's Simple Queue (http://aws.amazon.com/sqs/) >>6. Use Julia-box, if it can somehow accept inputs via an http call ( >>https://www.juliabox.org/) >>7. ??? >> >> >> -- Jack Minardi jack.minardi.org j...@minardi.org
[julia-users] Re: Backend deployment for website
Great stuff, seems like I've still got a bunch of research to do, especially regarding ZMQ. Jack, I'm really interested in your approach of using your julia process as a separate dockerfile. Could you explain what you meant by using a ZMQ server when you needed more communication? On Tuesday, June 16, 2015 at 10:35:40 AM UTC-5, Matthew Krick wrote: > > I've read everything I could on deployment options, but my head is still a > mess when it comes to all the choices, especially with how fast julia is > moving! I have a website on a node.js server & when the user inputs a list > of points, I want to solve a traveling salesman problem (running time > between 2 and 10 minutes, multiple users). Can someone offer some advice on > what's worked for them or any pros/cons to each option? Least cost is > preferable to performance. > > >1. Spawn a new node.js instance & solve using node-julia ( >https://www.npmjs.com/package/node-julia) >2. Use Forio's epicenter to host the code ( >http://forio.com/products/epicenter/) >3. Create a julia HTTP server & make a REST API ( >https://github.com/JuliaWeb/HttpServer.jl) >4. Host on Google Compute Engine (https://cloud.google.com/compute/) >5. Host on Amazon's Simple Queue (http://aws.amazon.com/sqs/) >6. Use Julia-box, if it can somehow accept inputs via an http call ( >https://www.juliabox.org/) >7. ??? > > >
[julia-users] Re: Backend deployment for website
We've put Julia and our package in a docker container and built a Ruby on Rails front end that spins up containers when needed. When we've needed to do a little more communication with the julia instance, we've run a ZMQ server in Julia and fed in the required data. (after poking open the ports through Docker) This has worked very well in that it allows Julia to do what it does best (numerical computation) and lets Rails and some other packages handle all the networking. Using this architecture we've been able to develop our julia package just as a command line app. On Tuesday, June 16, 2015 at 11:35:40 AM UTC-4, Matthew Krick wrote: > > I've read everything I could on deployment options, but my head is still a > mess when it comes to all the choices, especially with how fast julia is > moving! I have a website on a node.js server & when the user inputs a list > of points, I want to solve a traveling salesman problem (running time > between 2 and 10 minutes, multiple users). Can someone offer some advice on > what's worked for them or any pros/cons to each option? Least cost is > preferable to performance. > > >1. Spawn a new node.js instance & solve using node-julia ( >https://www.npmjs.com/package/node-julia) >2. Use Forio's epicenter to host the code ( >http://forio.com/products/epicenter/) >3. Create a julia HTTP server & make a REST API ( >https://github.com/JuliaWeb/HttpServer.jl) >4. Host on Google Compute Engine (https://cloud.google.com/compute/) >5. Host on Amazon's Simple Queue (http://aws.amazon.com/sqs/) >6. Use Julia-box, if it can somehow accept inputs via an http call ( >https://www.juliabox.org/) >7. ??? > > >
[julia-users] Re: Backend deployment for website
On Tuesday, June 16, 2015 at 11:35:40 AM UTC-4, Matthew Krick wrote: > > I've read everything I could on deployment options, but my head is still a > mess when it comes to all the choices, especially with how fast julia is > moving! I have a website on a node.js server & when the user inputs a list > of points, I want to solve a traveling salesman problem (running time > between 2 and 10 minutes, multiple users). Can someone offer some advice on > what's worked for them or any pros/cons to each option? Least cost is > preferable to performance. > Well I can offer some information about the thing I know the most about (node-julia). Ironically, I'm also working on visualizing the TSP, but more single user oriented currently. In this case, seems like a reasonable approach is routing the user request (via express) and calling your Julia code, process that asynchronously, and long-poll for the result. That part at least is straightforward. The tricky part is the long running time, and process queue, once Julia becomes multithreaded, then this becomes much less of an issue, but until then there are tasks, which is complicated with libuv use. But if there is little likelihood of 2 users running things simultaneously that's much less of a issue. Interesting problem; willing to help out if needed.
[julia-users] Re: Backend deployment for website
There are, indeed, various ways of doing so. So I suppose the choice depends a lot on your personal preferences. I don't have much experience with the node eco-system, but node-julia may be a good option for you. The way I have settled on doing this is using using https://github.com/tanmaykm/JuliaWebAPI.jl . This allows you to very easily provide a remote callable API to any Julia function using ZMQ. I use this from Java, using a standard Java ZMQ client. Alternatively, that package also wraps the ZMQ API with a HTTP/JSON api, which you can use with any http client. Presumably, the latter might be easier to do from nodejs. Regards - Avik On Tuesday, 16 June 2015 16:35:40 UTC+1, Matthew Krick wrote: > > I've read everything I could on deployment options, but my head is still a > mess when it comes to all the choices, especially with how fast julia is > moving! I have a website on a node.js server & when the user inputs a list > of points, I want to solve a traveling salesman problem (running time > between 2 and 10 minutes, multiple users). Can someone offer some advice on > what's worked for them or any pros/cons to each option? Least cost is > preferable to performance. > > >1. Spawn a new node.js instance & solve using node-julia ( >https://www.npmjs.com/package/node-julia) >2. Use Forio's epicenter to host the code ( >http://forio.com/products/epicenter/) >3. Create a julia HTTP server & make a REST API ( >https://github.com/JuliaWeb/HttpServer.jl) >4. Host on Google Compute Engine (https://cloud.google.com/compute/) >5. Host on Amazon's Simple Queue (http://aws.amazon.com/sqs/) >6. Use Julia-box, if it can somehow accept inputs via an http call ( >https://www.juliabox.org/) >7. ??? > > >
