My point in bringing in C was that the tools you choose are those that can do the job. If you have a real time requirement (something with msecs response) you won't be happy with interpreted code exchanging messages via email. However, if what you've been given is more on the order of "use Ruby on Rails and make this as fast as possible" then you can certainly get the job done.
The real tradeoff here is that to achieve real speed you must invariably give up flexibility. Even though you could write a hard drive controller in Ruby I doubt you would be satisfied with the result. I would recommend that you spend some time defining what you are trying to do and get requirements set for the areas of your application in which performance is critical. You should have real numbers here - or agreement with your user that "as fast as possible" is adequate. Take a look at SNMP as a mechanism for collecting data from remote systems - you might look at MRTG for example. Quite often you can partition the time sensitive portion out from the reporting portion. You could, for example, build status logs to report out when all is running in a pre-defined "good" way and make a nice web view that's driven from the logs. You obviously need to develop a strategy for reporting and responding to the alert and alarm states that populate the "not good" space. This is the place where time can be critical. So go for it - sounds like fun. On Sep 3, 6:03 am, jhaagmans <[email protected]> wrote: > On 2 sep, 23:52, Frederick Cheung <[email protected]> wrote: > > > > > On Sep 2, 7:13 pm, jhaagmans <[email protected]> wrote: > > > > And how can I make this an ongoing process? I don't want a cronjob- > > > powered script, for example. Later on, when there's a lot to query, we > > > might move from sending a query once every five seconds to a hundred > > > times per second. How to do this? It could also be also time-specific. > > > Some database entries only need to be monitored from 8AM to 5PM for > > > example. But not all. > > > > I hope you can help me with this, as I'm not sure where to start. If > > > you tell me to go and learn another programming language that's > > > faster, I will. Just be honest. > > > To be honest, if you're sending emails, querying remote servers etc. > > then you shouldn't be worrying about milliseconds - either of those > > two actions could take far longer than that. The smtp server you talk > > too could easily sit on your message for seconds or even minutes - > > email isn't an instant delivery protocol. Your server-monitory thing > > is going to be some sort of background process, you may find a single > > instance of that gets more done if you're using something like jruby > > that has better threading than normal ruby. Stuff like eventmachine is > > pretty cool for having a single process multiplex a lot of IO. > > > Fred > > Thanks Frederick, > > The thing is, I can't choose the tools I need to work with. I'm not > worrying about server response time from the servers that I will > query, that's just a given and I cannot do anything about it. I also > cannot worry about e-mail delivery time -after it left my machine- > because that also is just a given. The e-mails will be sent to servers > physically very close to the server sending out the e-mails. Just > believe me, any millisecond counts. That's also the reason I will be > creating this application: I will need to be able to fine-tune it > later on so that it fits perfectly. > > To Rick: > > Do you think C and/or C++ are more capable of doing this? I have no > prior experience with C, so I'll have to look into the possibilities. > > To all: > > Is Rails, or at least Ruby, able to do server monitoring on pre-set > intervals? Forget about the speed issue for a moment, but would it be > able to query a server, wait for its response (we're talking about > normal HTTP-requests), store this response and go on? There will be > three applications running on three servers. One is just querying -a > lot- of servers and it doesn't matter whether it has to wait for the > previous request to finish or not (so I guess multi-threading will not > be needed, right?). It only needs to store the last response and the > time of that last response. The second is querying only a few servers > and there are limitations to how often it can query a specific server, > but it should do a request every second (meaning that when a request > takes over 1 second, it will need to start a new thread). "Normal" > Ruby will probably not be able to do this, right? The last one will do > many requests per second to one or two servers, also on a pre-set > interval, but it also needs to send out an e-mail when the response > differs from what is expected. I guess, especially for this last > application, Ruby won't be able to help me. Am I right? > > I'm going to buy some C books, at least for app 2 and 3, I guess ;) > > Thank you both! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
