tags:

views:

39

answers:

3

I have a PHP script that is run through an AJAX call, and it can sometimes take very long (up to 30 seconds) for some people. To help keep the visitor's attention, I show a progress bar of how far along the process is, as well as listing random facts about the what the web app does, etc etc.

In order to update the progress bar to show exactly how far the process is in a %, the script writes to a session what "state" the process is in, a "total" for the amount it needs to do, and a "progress" to say how much it's done. While that long AJAX call is being made, another separate AJAX call is made to a page that lists those 3 session variables so it can turn it into an accurate progress bar in JavaScript, and it repeats itself every 0.5 seconds or so.

The problem is that in order for that second AJAX call to be able to retrieve the session data, the session has to be closed. So in the length script, it opens the session, writes the data, then closes it.

Is there any significant performance loss caused by doing this? Is there a better alternative to show how far along an lengthy AJAX call is?

EDIT: I should have chosen my words more carefully. The process used to take 30+ seconds, and it felt necessary to show a real progress bar instead of a repeating gif. After changing the algorithm, it now only takes 1-5 seconds on average, but I would guess that it could get up to 10 seconds in extreme cases. It is asynchronous and there is other content on the page, and they must choose to start the process. They can go to other pages or even close the window and come back later to see it finished. Now that the timespan is significantly lower, I'm wondering if I'm hurting its fast performance by trying to show a "true" progress bar or if there's another alternative to do so.

A: 

thirty seconds is a long time for anyone to wait for anything on the web, and it sounds like this is blocking in your interface (by that i mean the user cannot go about other work, they have to wait for the task to complete). you need to be careful about letting that number get too big, it is possible to timeout a request

if you are doing something on the server that simply cannot be done quickly for some reason, i would immediately return the user to the normal flow of the UI and have some asynchronous means of updating the user of its completion (a "status" area etc). for example, many photo uploading sites will act in this way - while your photo is being processed, they will put a placeholder image up, and then refresh the user's UI with a photo once the encoding and resizing has completed.

brad clawsie
It does not block the user from doing anything. It is a section of the web app that runs if they choose to, while plenty of other content is still available on the page. It's also set up so that they can go to other pages if they want to, and come back to see if it's done. It also no longer takes 30 seconds unless there's some extreme case (there should never be) as I switched it to a far faster algorithm. Nonetheless, I would still like to keep them updated with the progress, even if it's only 4-5 seconds now.
Nick
A: 

Sounds complicated, though there's no reason to think that there's anything particularly costly about closing a session. Server in that case simply designates the listener of your connection free. Of course anything called excessively when it's not necessary is generally a bad idea. If you think this strange behavior with the long wait might be caused by closing the session, you ought to see how long it takes to run without any progress bar feedback. Time it to be sure. If it's roughly the same, I wouldn't worry too much about session closing, though I'd investigate whether or not it's really the server taking that much time. If it's significantly faster, keep in mind that it could be a number of factors, not necessarily closing of the session.

Neil
A: 

Perhaps you are pre-loading too much in the front end? People don't like waiting around for things to happen, especially if it takes up to 30 seconds. You might want to consider lazy-loading some things with asynchronous javacscript.

I'd much more concerned about this than the session time.

Bryan Denny