1

Okay, here is my situation: I'm looking for the best design approach. I'm working in PHP/Smarty on the server-side and HTML/jQuery for the client-side, but that is not really important here.

I have this multi-user system on my server. It is a kind of ordering system. A standard user -- let's call them customer -- can order some items from the webshop. The webshop contains items from multiple sellers.

When the user (customer) places the order, the seller -- also a user in the system -- has to get notified that there is a new order and confirm/decline it.

When the seller confirms/declines the order, a notification has to be send to the user giving him/her the status of his/her order.

Orders are stored in the database, as well as order confirmations.

The only way I can think of right now is to constantly -- in short intervals with AJAX -- check for new records in the database, from the sellers' screen, and do the same thing for the customer when he/she is waiting for the confirmation.

But I'm thinking, is there any way to trigger notifications to the seller when the user(customer) places the order so the seller could load the database only when needed and not constantly in intervals?

The same goes for the customer when he/she is waiting for confirmation. But that is not so important because it doesn't happen all the time. There is a waiting limit when the order will be automatically declined if the seller doesn't respond.

I hope you understand my question.

jmort253
  • 32,054
  • 10
  • 92
  • 114
ZolaKt
  • 4,561
  • 6
  • 40
  • 66
  • 1
    I think you should look into COMET - which basically is a term that encapsulates various ways to simulate a PUSH mechanism. Check out this answer http://stackoverflow.com/questions/603201/using-comet-with-php and this one http://stackoverflow.com/questions/1320542/simple-comet-example-using-php-and-jquery I think that should give you enough to get started – Jagmag Jan 29 '11 at 18:08
  • Thanks. COMET seems like the way to go. Just I'm a little lost in these two threads. I can't find an example for a multiuser system. Any help? – ZolaKt Jan 30 '11 at 12:47
  • Ok. I read a few articles about COMET and long polling, and pretty much understand it now. The only problem is I'm stuck with an Apache server, which is not the best choice for the job. Can anyone tell me what is the max number of persistent connections Apache can work with in the same time? – ZolaKt Jan 30 '11 at 17:02
  • 1
    Apache has the CometProcessor interface which will pool the connections when you use the Http11NioProtocol. I don't however think that comet would be the right approach for this, does a seller or user really need to know right away that a new order has occurred? I think polling in 1 or 2 minute intervals is more than enough for this use case. – Andrew Jan 31 '11 at 15:26
  • It is not that important to know right away. But why not? Any cons about the comet approach, except the apache issue? – ZolaKt Jan 31 '11 at 18:04
  • Btw. 1-2min polling is way too long for this case. More like 10-20s is needed – ZolaKt Jan 31 '11 at 19:35
  • Have you though about caching this information inside for example in memcached. Create light api for this purpose, that is getting some kind id, and it only check what is status on memcached server (no database connection needed). But for this to works applications have to mark this flag in memcached when it's comfirmed or some other action. EDIT: Find more information about memcached here: http://memcached.org/ it's realy usefull and easy in implementation. It's simple storage key / value. Light, fast and has ability to set expire header for records. I think it would be good for this process. – Marek Tuchalski Feb 03 '11 at 11:44
  • Memcached in PHP: http://pl2.php.net/manual/en/book.memcached.php good luck ;) – Marek Tuchalski Feb 03 '11 at 11:48

3 Answers3

1

The answer to a similar question here on Using Comet with PHP suggests that there could be some problems with Apache threads being tied up from all the open connections to the client.

According to this blog post on PHP Continuations, it is possible to use continuations with PHP, but there just doesn't seem to be as much documentation on the subject. However, CometChat did it in PHP. It's not clear if they are using continuations, but they claim to scale to 100,000 connections. More information on PHP Comet can be found in this similar Stack Overflow Question regarding A Solution for Comet and PHP.

I was also going to suggest using Java, as Java has a really great track record for implementing scalable Comet with Continuations. Conversion Support is an example of chat software that uses comet and continuations on a Jetty Web Server.

Since your code is in PHP, you could Use Querces to run your PHP code on the JVM. Additionally, Querces PHP Benchmarks Suggest it's Faster than Apache, which gives you added advantages. Check out the Querces Project for more information.

UPDATE: I suggest you do your own benchmarks or research the speed issue yourself, as there may be some information that may suggest Apache is faster. If using Querces, it's important to understand that you would essentially be writing Java that just happens to look and feel like PHP. Thus, I'd suggest additional research there as well so that you understand the advantages and disadvantages of this approach.

Community
  • 1
  • 1
jmort253
  • 32,054
  • 10
  • 92
  • 114
0

Although instant updates would be nice, in reality, updates would never be instant anyway, there will always be a degree of latency inherent in transfering data over the internet.

The polling option seems more attractive for several reasons.

The system you describe sounds as if although it may start out small scale, it would easily scale to a multi-server configuration. Polling would allow you to create a polling server which the AJAX requests can query. This can be optimized for the small and fast nature of AJAX, where as the standard web server can be dedicated to web page display in the usual sense.

The polling idea also lends itself to a REST style API, making the polling area completely independant of the browser. You could find that further down the line, sellers on your system would prefer to have a native app, or even an iPhone/Android app. The REST API would allow you to do this from any app that can make an HTTP request.

Essentially you're avoiding being locked in to a particular technology, and that opens up future possibilties. It doesn't add any great amount of work, and provides a level of flexability that a permenent connection would not allow.

BParker
  • 164
  • 1
  • 12
0

COMET and long polling as mentioned above are common solutions to this problem. But you could also look into HTML5 web sockets. It's supported in all browsers but there are patches/polyfills for IE browsers.

You could also look at Node.js to run along side apache.

xzyfer
  • 13,077
  • 5
  • 32
  • 45