If you were planning on running each binary on different servers, then it would somewhat make sense (but you should really measure to see how CPU heavy the processing is).
But if you are planning on putting both binaries on the same server, you may as well just have one binary. Otherwise both binaries will be competing for the same CPU(s). Are the 20/30MB per user or per app? If per app, that isn't really an amount to worry about unless you are planning on running this on a really small server Hope that helps. Diego On Thursday, January 19, 2017 at 4:43:13 PM UTC-5, Keith Brown wrote: > > I am writing a webapp using go. It will server about 200 people but will > be highly dynamic so efficiency is important for me. > > > The app will contact 2 segments. 1) collect data by running few commands. > The data will be around 30/40 MB. I plan to run it periodically, say 20 > secs. The data will be XML so I plan to use XML library to parse the data. > 2) present the data. With the data collected I want to present it on the > website. > > > My question, would it be better to put collection and presentation in a > single binary? Or should I split it up where data collection is running > subsequent next to webserver. But how would I share the content efficiently > (I want to avoid a database since it’s a bottleneck and will add some more > complexity). What is a good mechanism to share memory when doing a split > setup? > > > I am inclined to go with separate binaries (collection and web serving). > > What are your thoughts? > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
