I need to check how much response time of a web service .Suppose a web service is being hit by 10000 users at same time so how much time it is taking both on local and production. I need to check for both get and post request.I have look on internet but I am getting jmeter which I think is for java.Can anyone suggest me tools for rails.
Try blazemeter. There are some restrictions on free tests but still it may help. Additionally maybe you can use native ruby benchmark command.
Related
Can someone point me in the right direction here? Suprisingly, I cannot find any info via Google searches (Probably because I don't know what to search for).
Anyway, I have built a site that does some API calls and saves some data to a database. This was done manually, but now would like to be able to just have the server make this call once a night.
However, I don't even know where to begin to get info on the subject. Can someone point me in the right direction?
Thanks
First of All, the windows service is a good option for such a case.
Start first by testing the API using an ASP.NET site as a client to consume this API. If you have done so, start looking for WebRequest and HttpWebRequest (both in System.Net namespace).
Another advice, you can use a Console Application to start testing the above mentioned classes, which makes debugging and the job easier at the beginning.
If you are considering using multithreading, do it asynchronously to take advantage of the APM.
I have a Web App that i have developed I am looking to develop a plugin for this app so that i can pull information from the users accounts package such as sage or quickbooks(offline version). Ideally I would like to do this without them having to have a static ip etc.
Unfortunately this is way over my head I currently have no idea on how to do this.
Please can some one guide me in the right direction I will probably use json data between the webapp and the client service that I will make and im fine with that part its just the initial connection that I am confused about.
Any help would be really really appreciated I hope this makes sense.
Thanks
Ash
The way the Shopify Quickbooks integration (Quickify) works is by setting up a tiny local server that listens on a high port number and is able to play with the local filesystem. The web app part of the solution sends JSON back to it.
I'm trying to create a ruby on rails ecommerce application, where potential customers will be able to place an order and the store owner will be able to receive the order in real-time.
The finalized order will be recorded into the database (at the moment SQLite), and the storeowner will have a browser window open, where the new orders will appear just after the order is finalized.
(Application info: I'm using the HOBO rails framework, and planning to host the app in Heroku)
I'm now considering the best technology to implement this, as the application is expected to have a lot of users sending in a lot of orders:
1) Each browser window refreshes the page every X minutes, polling the server continuously for new records (new orders). Of course, this puts a heavy load on the server.
2) As above, but poll the server with some kind of AJAX framework.
3) Use some kind of server push technology, like 'comet' asynchronous messaging. Found Juggernaut, only problem is that it is using Flash and custom ports, and this could be a problem as my app should be accessible behind corporate firewalls and NAT.
4) I'm also checking node.js framework, seems to be efficient for this kind of asynchronous messaging, though it is not supported in Heroku.
Which is the most efficient way to implement this kind of functionality? Is there perhaps another method that I have not thought of?
Thank you for your time and help!
Node.js would probably be a nice fit - it's fast, loves realtime and has great comet support. Only downside is that you are introducing another technology into your solution. It's pretty fun to program in tho and a lot of the libraries have been inspired by rails and sinatra.
I know heroku has been running a node.js beta for a while and people were using it as part of the recent nodeknockout competition. See this blog post. If that's not an option, you could definitely host it elsewhere. If you host it at heroku, you might be able to proxy requests. Otherwise, you could happily run it off a sub domain so you can share cookies.
Also checkout socket.io. It does a great job of choosing the best way to do comet based on the browser's capabilities.
To share data between node and rails, you could share cookies and then store the session data in your database where both applications can get to it. A more involved architecture might involve using Redis to publish messages between them. Or you might be able to get away with passing everything you need in the http requests.
In HTTP, requests can only come from the client. Thus the best options are what you already mentioned (polling and HTTP streaming).
Polling is the easier to implement option; it will use quite a bit of bandwidth though. That's why you should keep the requests and responses as small as possible, so you should definitely use XHR (Ajax) for this.
Your other option is HTTP streaming (Comet); it will require more work on the set up, but you might find it worth the effort. You can give Realtime on Rails a shot. For more information and tips on how to reduce bandwidth usage, see:
http://ajaxpatterns.org/Periodic_Refresh
http://ajaxpatterns.org/HTTP_Streaming
Actually, if you have your storeowner run Chrome (other browsers will follow soon), you can use WebSockets (just for the storeowner's notification though), which allows you to have a constant connection open, and you can send data to the browser without the browser requesting anything.
There are a few websocket libraries for node.js, but i believe you can do it easily yourself using just a regular tcp connection.
I use a web service to convert files. The service returns the converted file as an HTTP POST, along with identifier data. My app receives the response, updates its database and saves the file to the appropriate location.
At least that's the idea, but how do I develop and test this on a local machine? Since it isn't publicly facing, I can't provide a directive URL. What's the best way to handle this? I want to keep the process as clean as possible, and the only ideas I can come up with have seemed excessively kludgey.
Given how common REST API development is, I assume there are well-established best practices for this. Any help appreciated.
The solution will change a bit depending on which server your using.
But the generally accepted method is using the loopback address: 127.0.0.1 in place of a fully qualified domain name. Your server may need to be reconfigured to listen on this IP address, but that's usually a trivial fix.
example: http://127.0.0.1/path/to/resource.html
You can use curl or even your browser if your application has a proper frontend. There are many other similar tools to test this from a command line, and each language has a set of libraries for establishing http connections and transferring data along them.
If your machine isn't accessible to the service you are using, then your only option would really be to build a local implementation of the service that will exercise your API. A rake task that sends the POST with the file and the info would be a nice thing so you could start your rails app locally, and then kick off the task with some params to run your application through its paces.
This is the case any time you are trying to develop a system that can't connect to a required resource during development. You need to build a development harness of sorts so that you can exercise all the different types of actions the external service will call on your application.
This certainly won't be easy or straight forward, especially if your interface to this external service is complicated. Be sure to have your test cases send bad POSTs to your application so that you are sure you handle both what you expect, and what you don't.
Also make sure that you do some integration testing with the actual service before you "go-live" with the application. Hopefully you can deploy to an external server that the web service will be able to access in order to test. Amazon's EC2 hosting environment would let you set up a server very quickly, run your tests, and then shut down without much cost at all.
You have 2 options:
Set up dynamic dns and expose your app to the outside world. This only works if you have full control over your network.
Use something like webrat to fake the posts to your app. Since it's only 1 request, this seems pretty trivial.
Considering that you should be writing automated tests for this, I'd go with #2. I used to do #1 when developing facebook apps since there was far to many requests to mock them all out with webrat.
If your question is about testing, why don't you use mocks to fake the server? It's more elegant than using Webrat, and easier to deploy (you only have one app instead of an app and a test environment).
More info about mocks http://blog.floehopper.org/presentations/lrug-mock-objects-2007-07-09/
You've got some info about mocks with Rspec here http://rspec.info/documentation/mocks/
Is it possible to integrate MS Outlook/Exchange tasks with Rails? I know how to send emails with Rails, but that isn't using anything "special" about exchange, just pointing it at the server.
What is "special" about an Outlook Task and how I can I create/read/update/delete them from Rails. (Even a subset of CRUD would be great.)
PS. I am on a linux based rails system, so solutions that rely on a windows-only function won't work for me.
If you are running Exchange 2007 you should also look at Exchange web services to manipulate things.
I am in the process of building a MS Exchange client access library in Ruby that uses MS Exchange Web services. The code is GPL'd so have at it. Please let me know what kind of issues you have and what other features you'd like to see. It's pretty heavy in development at this point.
http://github.com/zenchild/Viewpoint
Cheers,
Dan Wanek
WebDAV might be the way to go, if you'd like to do it in Ruby. There is a ruby gem call rexchange that can do the trick. However, MSFT is phasing out WebDAV and replacing it with the Exchange Web Services, which is Zoredache suggested. Unfortunately, MSFT only provides API in C# (technically, it's SOAP stuff that is language-agnostic, some Java developers seem to sucessfully build some stuff using EWS, but I have yet known anyone has done this in Ruby.)
Assuming that the tasks are stored in Exchange, you should be able to access the tasks through WebDAV.