Sticking my nose in one more time :-) Another consideration for system choice is uptime loss for patch maintenance. From the tiny bit of information so far, the data collection off these scales may have to be nearly real time - web system down = nothing moves in the field. Is that true? I am having a vision of highways dpartment truck scales or something like that. Then you will have to design for fail-over so machines can be patched.
A very common architecture in the securities trading business is to do as little as possible on the front end except ingest the data and get it into a queue with persistence, for example RabbitMQ. Then process the downstream data with multiple systems as needed to deal with the throughput. RabbitMQ is written in Erlang which has high availability built in because of the way it is architected. The Erlang language, libraries and OTP the queue system came out of Ericsson and their Swedish telco switch business, I tend to believe they know what they are talking about when it comes to high availability. RabbitMQ is built on top of that. This is readily available on Ubuntu as a standard install package. There are Python interfaces and I believe orbited discussed recently does STOMP protocol as an interface into RabbitMQ or ActiveMQ. At this point I may sound like I am guilty of trying to design your system and am jumping ahead of knowing the true requirements. :-) I am just pointing out other considerations and products all readily available in the open source domain that may be worth looking at. Once you are forced onto the .Net platform the alternatives are much more restrictive. I am also not looking for a job, I have too much to do right now. :-/ Cheers, hope you end up with something workable that will solve the problem. Ron On Nov 29, 11:00 am, ron_m <ron.mco...@gmail.com> wrote: > Beware the consultant that only recommends what they know about. :-) > > Sounds like early optimisation attempts by the consultant if you ask > me. You have to do a traffic analysis on the network - sounds like > these are scales at remote locations - how often do they report in, > how much information per transaction, how much database activity per > transaction? My belief is either the network or the database will be > the real limiting factor. Worrying about whether or not the code is > compiled at this point is blowing smoke IMHO with 2GHz+ 4 core Nehalem > Xeons running $300 or $400 at most. CPU hardware is ridiculously > cheap. On the busiest system I am looking after I have trouble pushing > one core to 20% and I am moving 8 frames/sec of 704x480 pixel JPEG > camera video from 24 cameras to disk, each camera generates about 1 > GByte of data per hour to put it in perspective. This is all done in > Python layered over the C/C++ library gstreamer which is admittedly > nothing to do with web2py but worth mentioning because of the > languages used. The reason Python can be so fast is all the heavy > lifting is done in C with the excellent integration to C libraries > Python provides. Same thing goes for when you hit the database. I come > from a Java background prior to Python and know what a pain JNI can be > which is why Java types try to do it all in Java. With .Net you are in > a similar environment to Java and have to do all the programming > boilerplate other than what they can generate for you. Expect > somewhere around 10x lines of code comparing .Net or Java to Python. > > A far more important consideration is what does the programming team > know and is efficient working in. Having worked in both Java and > Python I can say with a certainty Python is like the walls have been > knocked down dealing with collections for example. Not meaning to > start any religious wars about languages but at age 59 I think I am > officially an old fart, I have been in the industry since 1977 and > have kept up to date with the technology else I would still be looking > for Fortran jobs. :-) > > Ron > > On Nov 29, 10:20 am, Julio Schwarzbeck <ju...@techfuel.net> wrote: > > > And this without considering "vendor lock-in". web2py can run on a > > variety of platforms such as windows, macs. Linux and others, same > > goes for the selection of the back-end database. Much more flexibility > > under web2py in my opinion and prototyping is much faster in python. > > > On Nov 29, 10:05 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > > You achieve scalability by replicating the web server behind a load > > > balancer. This is documented in the book, chapter 11, using HAProxy. > > > All frameworks work the same way in this respect. web2py has no > > > intrinsic limitations. The bottle neck is the database connection. All > > > frameworks have the same problem. You can replicate the database too > > > and web2py supports multiple database clients with Round-Robin. > > > > On a small VPS, web2py in average, should execute one page in 20ms. > > > Depending on how many requests/second you need you can determine how > > > many servers you need. > > > > web2py apps run on Google App Engine and that means arbitrary > > > scalability as long as you can live with the constraints imposed by > > > the Google datastore (these limitations will go away as soon as Google > > > releases MySQL in the cloud, which they announced some time ago). > > > > Please ask the consultant: which .NET feature makes it scale any > > > better than web2py or Rails? If he explains we can address it more > > > specifically. > > > > Massimo > > > > On Nov 29, 11:56 am, Lorin Rivers <lriv...@mosasaur.com> wrote: > > > > > The project I'm working on has hired a consultant who is now > > > > recommending .Net in place of web2py or even rails. > > > > > What's the 'largest' scale web2py is known to perform well on? > > > > > -- > > > > Lorin Rivers > > > > Mosasaur: Killer Technical Marketing <http://www.mosasaur.com> > > > > <mailto:lriv...@mosasaur.com> > > > > 512/203.3198 (m) > >
