Good day...
I have developed a DSL in xtext web using eclipse. It has a login page and multiple users can login from anywhere...
Now my requirement is to test the load of this web DSL. I need to test:
"certain number of users in parallel"
how conflicts are avoided/managed"
"the perceived latency experienced by the users (the lower the better)"
Please guide me how to perform this load and stress test on Jetty server.
Thanks,
If you're talking about xtext-web it's just a matter of sending proper HTTP requests simulating your users accessing the endpoint.
Just choose a load testing tool which supports HTTP protocol (the vast majority of them does) and implement your test scenario steps. If you're looking for a Java-based one there are Apache JMeter and Gatling.
very new to the idea of using web automation with rotating proxies and headers here. I have some basic questions that I can't seem to totally have the answers confirmed from the docs.. Here are some of the questions I most want the answers to for now, please excuse if they are too basic:)
First of all, if you're using web automation for example with Selenium or Playwright, with proxies will it mean that the Selenium or Playwright scripts will be sent to the proxy servers to be used and fetch the data? Thus far, I have only been using paid proxy services that use python requests and do not offer web automation, the problem here is that sometime requests don't return full diplayed data.
Second question would be about TorPy a tool I recently found. As I understand from the manuals it is a layered process in fetching data via multiple free proxies for each request, would this be correct assumption? Many thanks.
I developed a REST API with go (golang), and now I want to design my web frontend. I don't know how can I separate frontend from backend.
I think that I have three choices:
1- Run REST API on one server and the frontend website on another server.
2- Run REST API and frontend website on the same server, but on different ports. For example run REST on port 8080 and frontend website on port 80.
3- Run Both on the same server and the same port, but use different URL paths (or subdomains) for each one.
As I don't know about this stuff, please tell me which one is true or best solution. Or is there any other solution? Does it matter how big my website is?
Either the first or second options will be mostly the same for you to set up and develop with. So you don't lose or gain anything from that perspective, the only deciding factor is your resources and how you expect your backend to be used in the future.
Currently, if you only have one application/frontend calling on the API, having them be on the same server will be the better option since it will have a marginally increased performance compared to the second option.
But, since you chose a RESTful design for your backend, you might want to reuse it for more applications in the future, and if you expect that the increase in calls to the API will start to use up the server resources, then your frontend might suffer from it and then you should consider relocating the backend to a different server.
The whole microservices, RESTful backend design "pattern" was created to decouple the front and back for better scaling, but that might not be necessary for everyone, you have to estimate the amount of use your application will realistically have and think if you might actually reuse the API elsewhere (or if you want to offer the API for others or not).
In the end, if the first and second option present a similar amount of investment for you at the moment, go for the first one, if not, just keep both front and back on the same server and if in the future you realize you need to scale out, you can just relocate the API to a different server/servers.
I am in the process of scoping the development of an iPhone app for a client. Among other things, the app will allow users to browse through and place orders on specific (tangible) products.
The client has a website that currently does a similar thing and due to their limited budget and the fact that the website runs on a third-party proprietary platform which they have no control over, we are investigating possible alternatives to building a web service.
On the website, user registration and authentication, as well as order placing is done through POST requests via secure HTTP. The response is always a formatted HTML page which will contain strings indicating whether the request was successful or not, and if there was an error, what the error is etc.
So provided I can replicate the POST requests on the phone, and parse the HTML responses to read the results of each request, do you think this is an acceptable alternative to building a web service to handle this?
Apart from the possibility of pages changing (which we can manage) and the fact that I will probably have to download and parse a relatively large HTML response, are there any other drawbacks to this solution and is there anything else that I might be missing?
Many thanks in advance for your thoughts.
Cheers,
Rog
You could create an intermediary server that will communicate with the client server, and on it expose some REST web services with json (small overhead and easy to handle) responses that will be consumed by the iPhone app.
So, you're going to parse HTML and formulate POSTs off a third-party server, and pray that they don't even so much as rename a form field.
Your question is in two parts:
Do I think that a miracle is an acceptable solution? I don't.
Do I think that aside from the fact a miracle is required, are there any other drawbacks? None that I can think of.
You didn't ask, but this is a terrible course of action. Two suggestions.
I spy an assumption that the providers of the third-party platform aren't interested in enabling third-party applications by providing an API. They have a very good business reason for this, which is that it promotes platform lock-in. Reach out to their support department and have a talk with them.
You have to sell the client on building an intermediary web service. To at least try to mitigate the damage that changes on this third-party platform can do to your app, I recommend that you build and operate a proxy that receives requests from your applications, and proxies them over to the third-party platform. You should build into this client-server protocol a means for returning "we are in maintenance mode, go away" messages to apps, for that inevitable day when the third-party server changes something that breaks your app (they swapped the billing and shipping address pages, for instance) and you have to rush through an update through Apple to deal with it.
The proxy could be written in something more flexible and easy to bash stuff out in, such as PHP, Python, Perl, or Ruby. It could be hosted at Amazon in a micro instance.
p.s. This question is inappropriately tagged objective C.
HTML is the worst because of parsing (1-2secs per page), memory, and changes, but you already know that. Check in advance that ALL the data you need is exposed on the HTML.
If you use an intermediary server you are moving work elsewhere and you have another server to maintain. I would only do that if memory is an issue. Check How To Choose The Best XML Parser for Your iPhone Project for memory/performance/xpath support. libxml2 is a good option, but it depends on your needs. And maybe you'll want to check ASIHTTPRequest features before using the SDK.
I think utilising the web language of JSON would contribute to the diminishing of the parsing time. By building a REST service that, when sent a GET request, returns the correct information for easy sorting, you could then display the output a lot faster than that of parsing straight HTML.
I prefer JSON over XML, but everyone has their personal preference. You should look at a few very good libraries that are built specifically for parsing purposes of both XML and JSON.
For XML I recommend using the inbuilt libxml parser. Albeit, this can sometimes deem very difficult to use. A simple Google search will bring up a heap of results that relate specifically to what parser should be used depending on what task is to be completed.
As for a JSON parser, I recommend SBJSON. I am currently using it one of the biggest projects I have undertaken and it is definitely working perfectly for my use.
If you need a good way to connect to a RESTful web service, you should try LRResty.
Don't go for a parsing solution on the iPhone for 4 reasons:
Server can change their design and break your application (AppStore submition is long) + They can also detect that the request are sent from an application based on user agent which you have to update the application to change it.
Some of the requests might be made thru Javascript so you not only have to parse (X)HTML but also Javascript request (which can be in the form of XMLHttpRequest, but don't have to)
Long term evolution of the mobile market : maybe your client want (or will want) an application for android, Blackberry, Bada OS (Samsung), Symbian (Nokia/ OVIStore), Java Mobile or Windows Phone 7?
Of course network traffic, Memory and CPU needed to parse HTML (look the time it takes to the browser to do it?)
Regarding the traffic, if the application will not have a huge traffic you can home-host your proxy. Or you can find some provider to host it for you. I guess you won't need more than a couple of Megabytes of storage but maybe traffic. For less than 100€/year you can find some with unlimited traffic (like OVH Pro plan or Infomaniak). But if you want to go Java have a look at Google App Engine : you pay only if your traffic is important and if your application generate many CPU Cycles. If not : you don't have to pay. And it's hosted on Google server : reliable.
If the client is open, you could consider the paypal API.
I am writing an application using GWT on Windows that needs to do some network calls.
I know that if these aren't to the same machine I'm developing on I need to setup a proxy, right?
I was just wondering if anyone could help with what my GWT code would look like?
What proxy should I use on Windows?
Thanks!
If you're simply requesting data from a RESTful service from a different domain, you can use JSONP (http://code.google.com/webtoolkit/tutorials/1.6/Xsite.html).
If you're trying to post data, you'd have to perform the network calls on the server side. (There are some hackish ways to try to submit via a hidden iframe, but they're non-standard). What this means is that you simply invoke a method on your server which does the network call (see http://code.google.com/webtoolkit/tutorials/1.6/RPC.html).
If you mean Google Web Toolkit, and you're trying to evade cross-domain scripting restrictions, check out Yahoo's how-to guide. There's even PHP sample code.
Why not perform the network calls in server side? That way you are not restricted to cross domain restrictions.
I think this is what you are looking for:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3131