I have a web based phone dialer, which I need to stress test. It requires human action to terminate a call and dial next call. I need to simulate a situation under which 100 users will use the service concurrently. I am not allowed to modify the javascript which dials the next number. Also, there exist a login page, after which the users can reach the dial pad.
Any idea how do I do this?
You can use Apache JMeter to stress test your web app. First setup JMeter as proxy to record the http transactions. then using those transactions as template set it up to send 100 concurrent request.
Maybe xdotool could be a good beginning to resolve your human interaction simulation. But how to solve the 100 users concurrently, I don't know yet. Hopes this helps.
Related
I don't know did I make a correct caption of my question so feel free to correct me. So I have a REST web service written on PHP (It retreives some data from database and returns some xml data). I have tested it with JMeter and made a conclusion that it responses fast (min 50 requests per second with answer faster than 5 sec.) But in my log of requests I found that sometimes I recieve the pool of requests (means ~10-20 requests at one moment) and my service is unavailable to proceed all of them. What can I do. How can I handle them? How can I make some queue and response each of them separately. Thanks
I have a web application written in PHP using a Postgres database.
The next phase of development is for background batch processes to be built that will need to be executed once a day (or adhoc as requested) for each user of the app. The process will query, await response and process the response from third-party services to feed information into the user's account within the web application.
Are there good ways to do this?
How would batches be triggered every day at 3am for each user?
Given there could be a delay in the response, is this a good scenario to use something like node.js?
Is it best to have the output of the batch process directly update the web application's database
with the appropriate data?
Or, is there some other way to handle the output?
Update: The process doesn't have to run at 3am. The key is that a few batch processes may need to run for each user. The execution of batches could be spread throughout the day.. I want this to be a "background" process separate to the app.
You could write a PHP script that runs through any users that need to be processed, and set up a cron job to run your script at 3am. Running as a cron job means you don't need to worry so much about how slow the third party call is. Obviously you'd need to store any necessary data in the database.
Alternatively, if the process is triggered by the user doing something on the site, you could use exec() to trigger the PHP script to process just that user, right away, without the user having to wait. The risk with this is that you can't control how rapidly the process is triggered.
Third option is to just do the request live and make the user wait. But it sounds like this is not an option for you.
It really depends on what third party you're calling and why. How long does the third party take to respond, how reliable they are, what kind of rate limits they might enforce, etc...
I'm not an expert on http request so this question might be trivial for some. I'm sending a request to a php script which takes a lot of time to process a file and return a response. Is there a way to send a response before this script finishes its task to let the user know about the process status? Since this task can take up to several minutes I'd like to notify the user when key parts of the process are finished.
Note: I cannot break this request into several others
I might not have the correct approach here if so do you have other ideas how this could be handled?
Technically yes, but it would require you to have fine grained control of the http-stack, which you may or may not have in a typical php setup. I would suggest you look into other solutions (E.g. Make request to start the task - then poll to get an update on the progress)
http://www.redips.net/javascript/ajax-progress-bar/
here's a great article that goes over creating ajax a progress bar to use with php.
let me know if it doesn't make sense!
I think the best way for long proccessing requests is cron jobs. You can send request which will create 'task' and catch the task by cron job. Cron job can change task status while working and you can check task status via interval requests. I can't imagine another way to inform users about request proccessing. As soon as you response your headers are sent and PHP stops.
EDIT: it should be noted that Cron jobs are only available on Linux servers. windows servers would require access to the task scheduler, which most web hosts will not allow.
I am solving an issue that I cannot figure out. I need to login and click repeteadly (thousand of times) on the specific link to create some load. I know I should use HTTP/PHP for that but do not know how to solve the login?
My next idea was to use some packet sniffer and re-send the requests..but will it work when I would close the browser?
Thanks
If you'd want to do this from a PHP script, you could use cURL to simulate the HTTP request. However, it is easier to use a benchmark tool like ab or siege to put load on certain URLs
With ab:
ab -n 1000 -c 10 http://www.example.com/login.php
From the Siege website:
Siege is a regression test and benchmark utility. It can stress test a single URL with a user defined number of simulated users, or it can read many URLs into memory and stress them simultaneously. The program reports the total number of hits recorded, bytes transferred, response time, concurrency, and return status. Siege supports HTTP/1.0 and 1.1 protocols, GET and POST directives, cookies, transaction logging, and basic authentication. Its features are configurable on a per user basis.
Also see this related question
Take a look at Selenium. You may record an action and then edit the resulting script into a loop.
How can I write a real time chat using XAJAX and PHP?
In other words, is there a way to send xajax responses from the server to multiple clients?
Or is the only possibility to check for new messages every few seconds on client side?
No. Clients must "poll" the server repeatadly.
I think the key here is to think interaction design. The trick is to fool the user into thinking that the chat is instant, but when in reality it updates once every 1 or 2 or 3 or 10 seconds.
Ideas:
1) When the user sends a message, show it directly in the chat and trigger a poll.
2) If a poll comes back with multiple messages from other users, don't add them all at once, actually add them over a period of 1-2 sec or so, with random spacing, making it look like they're coming in "instantly" and independently. (If a bunch of messages come in at once the user is very quick to realize that the chat updated there and then, and not continiously.)
3) If the user is idle for x amount of time. Drop the poll rate to once every 10sec or so.
4) If the user is active, ie sending a lot of messages, poll more often.
5) Have a static file for every channel that your write the time the chat last updated to. For instance file chat-teenfun-lastupdate.txt has the contents 1224934239 or whatever time format you prefer. Serve this file statically and let clients poll this file in order to check if the channel has updated, rather that calling chat-poll.php?ch=teenfun that does a dynamic check. Static files are served around 10-100 times faster, depending on the work involved for the dynamic script, and you're gonna need it when you get 250+ users polling.
Good luck and have fun!
/0
PS. Alternatively you could actually let clients do an ajax call to the server and keep them 'hanging'. That is you accept their request and pretend to start sending data back, but then you just pause. When something happends you finish the response with the approriate data. For this to work I believe you'd need to write your own HTTP-server though, that does this specifically, as you can't have 250 php processes hanging around in memory. Maybe Lighttpd could be used in this way somehow with that LUA cache mod. I don't know. Would be interesting though. Hell I gotta try it sometime :)
Sure there is, but I don't think it'll be very efficient with many users. You can either do polling where each client polls the server to see if there are any new messages, or you could use the comet technique in which the server can push new messages to the clients - Check out the Comet plugin for XAJAX. How this would be implemented using XAJAX and PHP is beyond me, but here's how I would try to implement it.
Let each client connect to the server (login etc), then:
For each message sent by a client (sender) update the message queue for client (receiver)
Let client poll server for new messages in the queue / Push the new messages via comet.
Update GUI if there are new messages.
Rinse, lather, repeat
Using a true IM server like ejabberd could go a long way, be more efficient and allow your users to connect via desktop clients (if that's what you want). I'd probably use that as a backend, IOW ejabberd would be the server and PHP would be the client using XMPP in PHP, and act as a proxy for the webgui.
See also:
Google Techtalk on Gmail's chat feature (and scalability issues)
That's my $0.02
As long as there there is not HTTP push technology you will never get a realtime chat only using JavaScript.
Possible workarrounds:
use a Flash Movie or a Java Applet to perform some socket communication
hold polling requests back on the server side for a few seconds
You could use websockets, but being a new HTML5 feature it's kinda limited. Lucky for you there is socksjs, which implements websockets on browsers that do not handle it.
On the hosting side you should be able to use any websockets server, there's a few for PHP.
If you are looking to implement a chat server written with a scripting language such as PHP/JSP, technique of hanging HTTP connection will have to be ticked off from your your options list. The reason is most of the web severs (specially shared hosts) don't like too many connections hanging.
You can find everything you need to implement a web client and PHP chat server in this "Optimized Chat Server Protocol for Server Side Scripting Languages" publication.
The best strategy I've seen is to do an AJAX request for messages and then restart that exact same request as soon as it finishes.
On the server side, make the script "stall" for 60 seconds or until a new message is received. This keeps the same connection open for a max of 60 seconds, but when a new message is received, it outputs it and stops immediately, prompting the client-side AJAX to open another connection.
This provides almost instant notification of new messages and is also much easier on the server than making a new connection every x seconds.