Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #15445 > unrolled thread

response for server every second

Back to article view | Back to comp.lang.php

Contents

  response for server every second apoorv.kanungo@gmail.com - 2015-06-10 06:59 -0700
    Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-10 10:18 -0400
    Re: response for server every second Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-06-10 16:41 +0200
      Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-10 11:55 -0400
        Re: response for server every second Allodoxaphobia <knock_yourself_out@example.net> - 2015-06-10 16:50 +0000
          Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-10 13:23 -0400
            Re: response for server every second Richard Yates <richard@yatesguitar.com> - 2015-06-10 10:37 -0700
              Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-10 14:27 -0400
      Re: response for server every second apoorv.kanungo@gmail.com - 2015-06-10 23:38 -0700
      Re: response for server every second apoorv.kanungo@gmail.com - 2015-06-11 00:14 -0700
        Re: response for server every second Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-06-11 12:09 +0200
          Re: response for server every second apoorv.kanungo@gmail.com - 2015-06-11 04:16 -0700
            Re: response for server every second Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-06-11 14:37 +0200
              Re: response for server every second apoorv.kanungo@gmail.com - 2015-06-11 06:20 -0700
                Re: response for server every second Matthew Carter <m@ahungry.com> - 2015-06-11 13:45 -0400
              Re: response for server every second apoorv.kanungo@gmail.com - 2015-06-11 23:35 -0700
                Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-12 09:10 -0400
            Re: response for server every second Denis McMahon <denismfmcmahon@gmail.com> - 2015-06-12 03:59 +0000
              [off topic nodejs advertisement] Was Re: response for server every second Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-06-15 16:08 +0200
                Performance of PHP vs. Node.js (was: [off topic nodejs advertisement]) "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-06-15 20:42 +0200
                  Re: Performance of PHP vs. Node.js Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-06-16 00:20 +0200
                    Re: Performance of PHP vs. Node.js "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-06-16 00:58 +0200
            Re: response for server every second gordonb.890nt@burditt.org (Gordon Burditt) - 2015-06-13 13:39 -0500
              Re: response for server every second apoorv.kanungo@gmail.com - 2015-06-18 23:16 -0700
                Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-19 08:16 -0400
                  Re: response for server every second apoorv.kanungo@gmail.com - 2015-06-21 23:06 -0700
                    Re: response for server every second "Peter H. Coffin" <hellsop@ninehells.com> - 2015-06-22 08:03 -0500
                    Re: response for server every second Denis McMahon <denismfmcmahon@gmail.com> - 2015-06-23 06:39 +0000
                      Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-23 07:23 -0400
      Re: response for server every second Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-22 18:37 +0200
        Re: response for server every second Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-22 18:42 +0200
        Re: response for server every second Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-06-23 17:11 +0200
          Re: response for server every second Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-24 00:06 +0200
            Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-23 19:10 -0400
              Re: response for server every second Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-24 01:45 +0200
                Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-23 20:21 -0400
                  Re: response for server every second apoorv.kanungo@gmail.com - 2015-06-23 23:34 -0700
                    Re: response for server every second bill <william@TechServSys.com> - 2015-06-24 06:58 -0400
                  Re: response for server every second Arno Welzel <usenet@arnowelzel.de> - 2015-06-25 17:18 +0200
                    Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-25 20:31 -0400
                      Technical requiremenets for Usenet messages (was: Re: response for server every second) Arno Welzel <usenet@arnowelzel.de> - 2015-06-26 10:43 +0200
                        Re: Technical requiremenets for Usenet messages Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-26 21:47 +0200
                          Re: Technical requiremenets for Usenet messages Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-26 22:19 +0200
                    Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-25 23:07 -0400
                      Re: response for server every second Arno Welzel <usenet@arnowelzel.de> - 2015-06-26 10:21 +0200
                        Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-26 06:48 -0400
                          Technical requirements for Usenet messages (was Re: response for server every second) Arno Welzel <usenet@arnowelzel.de> - 2015-06-26 13:48 +0200
                            Re: Technical requirements for Usenet messages (was Re: response for server every second) Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-26 14:29 -0400
                              Re: Technical requirements for Usenet messages Arno Welzel <usenet@arnowelzel.de> - 2015-06-27 14:49 +0200
                                Re: Technical requirements for Usenet messages Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-27 10:25 -0400
                                  Re: Technical requirements for Usenet messages Arno Welzel <usenet@arnowelzel.de> - 2015-06-28 17:52 +0200
                                    Re: Technical requirements for Usenet messages Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-28 20:08 -0400
                                Re: Technical requirements for Usenet messages "Peter H. Coffin" <hellsop@ninehells.com> - 2015-06-27 22:14 -0500
                                  Re: Technical requirements for Usenet messages Arno Welzel <usenet@arnowelzel.de> - 2015-06-28 17:54 +0200
                                    Re: Technical requirements for Usenet messages Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-28 20:10 -0400
                                      Re: Technical requirements for Usenet messages Arno Welzel <usenet@arnowelzel.de> - 2015-06-30 09:54 +0200
                                        Re: Technical requirements for Usenet messages Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-30 08:45 -0400
                                          Re: Technical requirements for Usenet messages Arno Welzel <usenet@arnowelzel.de> - 2015-06-30 16:20 +0200
                                            Re: Technical requirements for Usenet messages Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-30 15:00 -0400
                                              Re: Technical requirements for Usenet messages Arno Welzel <usenet@arnowelzel.de> - 2015-07-06 13:36 +0200
                                                Re: Technical requirements for Usenet messages Jerry Stuckle <jstucklex@attglobal.net> - 2015-07-06 11:56 -0400
                                                  Re: Technical requirements for Usenet messages Richard Heathfield <rjh@cpax.org.uk> - 2015-07-06 18:54 +0100
                                                    Re: Technical requirements for Usenet messages Jerry Stuckle <jstucklex@attglobal.net> - 2015-07-06 16:54 -0400
                                                      Re: Technical requirements for Usenet messages Richard Heathfield <rjh@cpax.org.uk> - 2015-07-07 00:00 +0100
                                                        Re: Technical requirements for Usenet messages Jerry Stuckle <jstucklex@attglobal.net> - 2015-07-06 22:08 -0400
                                                          Re: Technical requirements for Usenet messages Richard Heathfield <rjh@cpax.org.uk> - 2015-07-07 07:24 +0100
                                                            Re: Technical requirements for Usenet messages Jerry Stuckle <jstucklex@attglobal.net> - 2015-07-07 10:41 -0400
                                                              Re: Technical requirements for Usenet messages apoorv.kanungo@gmail.com - 2015-07-09 22:52 -0700
                                  Re: Technical requirements for Usenet messages Denis McMahon <denismfmcmahon@gmail.com> - 2015-07-02 03:07 +0000
                    Re: response for server every second Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-26 21:13 +0200
              Re: response for server every second Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 09:52 +0100
                Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-24 09:21 -0400
                  Re: response for server every second Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 18:48 +0100
                    Re: response for server every second Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-24 20:55 +0200
                      Re: response for server every second Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 20:55 +0100
                    Re: response for server every second Jerry Stuckle <jstucklex@attglobal.net> - 2015-06-24 15:21 -0400
                      Re: response for server every second Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 20:35 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#15445 — response for server every second

I want to get response from server every one second, the output will contain some value which I need to process in front end.

In backend I am using some queries to read data from mysql and return me output.

Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront

None of these work for me usually it is taking 3-4 seconds to get me response,

classic example to see this working(getting output in one sec)

http://madbid.com

Please let me know if anyone has some solution for this.

[toc] | [next] | [standalone]

#15446

On 6/10/2015 9:59 AM, apoorv.kanungo@gmail.com wrote:
> I want to get response from server every one second, the output will contain some value which I need to process in front end.
> 
> In backend I am using some queries to read data from mysql and return me output.
> 
> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
> 
> None of these work for me usually it is taking 3-4 seconds to get me response,
> 
> classic example to see this working(getting output in one sec)
> 
> http://madbid.com
> 
> Please let me know if anyone has some solution for this.
> 

You're not going to be able to do it with PHP.  The HTTP protocol is a
request/response protocol; the client makes a request and the server
responds.  But there is no guarantee how long it will take for the
server to respond.  It may be 0.1s or it may be 30s.  Both are equally
valid.

You'll need to find some other means of doing it.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#15447

On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
> I want to get response from server every one second, the output will contain some value which I need to process in front end.
>
> In backend I am using some queries to read data from mysql and return me output.
>
> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
>
> None of these work for me usually it is taking 3-4 seconds to get me response,
>
> classic example to see this working(getting output in one sec)
>
> http://madbid.com
>
> Please let me know if anyone has some solution for this.
>

Hi,

I have 2 observations:

1) How many clients are requesting that info on the server?
If you have multiple clients, think over your design (i'll come back to 
that)
Let's look at XML HTTP Request (XHR) first (what you called AJAX):
What happens?
a) Client request a PHP page
b) Server much launch the process
c) PHP runs, and starts a database query
d) Database processes the query, and answers
e) PHP delivers the answer as output back to the requesting client
f) Client updates the screen

This is just not feasible every second.
Try that with 1000 clients. ;-)
There is so much overhead involved, and networking, you can't expect 
this to run every second.

Solution:
Create a cronjob that runs every second.
Let it call your PHP script that queries the database.
Instead of responding to a client, let PHP put its output in a file in a 
public directory.
Let XHR directly fetch this file.
This is much faster.

Warning: write the file as myOutput_tmp.xml, then rename to 
myOutput.xml, otherwise you risk trying to read a file that is in the 
process of being written.
I assume that your PHP script end within the second, otherwise you have 
another problem. If, for example, your DB query takes 5 secs, the whole 
adventure will fail, whatever you try.

Did you take timestamps for the whole PHP script (from start to end)?
If that is close to 1 second, you have to find another solution.

2) Use nodeJS
Indeed, no PHP. No AJAX.
NodeJS is extremely fast and supports sockets.
If you are a bit familiar with ECMA Script (such as Javascript), try 
this route.

Good luck

Regards,
Erwin Moller

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#15448

On 6/10/2015 10:41 AM, Erwin Moller wrote:
> On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
>> I want to get response from server every one second, the output will
>> contain some value which I need to process in front end.
>>
>> In backend I am using some queries to read data from mysql and return
>> me output.
>>
>> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
>>
>> None of these work for me usually it is taking 3-4 seconds to get me
>> response,
>>
>> classic example to see this working(getting output in one sec)
>>
>> http://madbid.com
>>
>> Please let me know if anyone has some solution for this.
>>
> 
> Hi,
> 
> I have 2 observations:
> 
> 1) How many clients are requesting that info on the server?
> If you have multiple clients, think over your design (i'll come back to
> that)
> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
> What happens?
> a) Client request a PHP page
> b) Server much launch the process
> c) PHP runs, and starts a database query
> d) Database processes the query, and answers
> e) PHP delivers the answer as output back to the requesting client
> f) Client updates the screen
> 
> This is just not feasible every second.
> Try that with 1000 clients. ;-)
> There is so much overhead involved, and networking, you can't expect
> this to run every second.
> 
> Solution:
> Create a cronjob that runs every second.
> Let it call your PHP script that queries the database.
> Instead of responding to a client, let PHP put its output in a file in a
> public directory.
> Let XHR directly fetch this file.
> This is much faster.
> 
> Warning: write the file as myOutput_tmp.xml, then rename to
> myOutput.xml, otherwise you risk trying to read a file that is in the
> process of being written.
> I assume that your PHP script end within the second, otherwise you have
> another problem. If, for example, your DB query takes 5 secs, the whole
> adventure will fail, whatever you try.
> 
> Did you take timestamps for the whole PHP script (from start to end)?
> If that is close to 1 second, you have to find another solutionr
>

While yours are all good suggestions, it's still no guarantee, Erwin.
Even just retrieving a static page can take more than 1 second,
depending on server load, available bandwidth, client load and even
which browser is to parsing the HTML.


> 2) Use nodeJS
> Indeed, no PHP. No AJAX.
> NodeJS is extremely fast and supports sockets.
> If you are a bit familiar with ECMA Script (such as Javascript), try
> this route.
> 

Another possibility.  So is a Java applet, .NET and probably a dozen
other ways, all of which he can find better help on an appropriate
newsgroup.

> Good luck
> 
> Regards,
> Erwin Moller
> 



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#15449

On Wed, 10 Jun 2015 11:55:51 -0400, Jerry Stuckle wrote:
> On 6/10/2015 10:41 AM, Erwin Moller wrote:
>> On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
>>> I want to get response from server every one second, the output will
>>> contain some value which I need to process in front end.
>>>
>>> In backend I am using some queries to read data from mysql and return
>>> me output.
>>>
>>> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
>>>
>>> None of these work for me usually it is taking 3-4 seconds to get me
>>> response,
>>>
>>> classic example to see this working(getting output in one sec)
>>>
>>> http://madbid.com
>>>
>>> Please let me know if anyone has some solution for this.
>> 
>> Hi,
>> 
>> I have 2 observations:
>> 
>> 1) How many clients are requesting that info on the server?
>> If you have multiple clients, think over your design (i'll come back to
>> that)
>> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
>> What happens?
>> a) Client request a PHP page
>> b) Server much launch the process
>> c) PHP runs, and starts a database query
>> d) Database processes the query, and answers
>> e) PHP delivers the answer as output back to the requesting client
>> f) Client updates the screen
>> 
>> This is just not feasible every second.
>> Try that with 1000 clients. ;-)
>> There is so much overhead involved, and networking, you can't expect
>> this to run every second.
>> 
>> Solution:
>> Create a cronjob that runs every second.
>> Let it call your PHP script that queries the database.
>> Instead of responding to a client, let PHP put its output in a file in a
>> public directory.
>> Let XHR directly fetch this file.
>> This is much faster.
>> 
>> Warning: write the file as myOutput_tmp.xml, then rename to
>> myOutput.xml, otherwise you risk trying to read a file that is in the
>> process of being written.
>> I assume that your PHP script end within the second, otherwise you have
>> another problem. If, for example, your DB query takes 5 secs, the whole
>> adventure will fail, whatever you try.
>> 
>> Did you take timestamps for the whole PHP script (from start to end)?
>> If that is close to 1 second, you have to find another solutionr
>
> While yours are all good suggestions, it's still no guarantee, Erwin.
> Even just retrieving a static page can take more than 1 second,
> depending on server load, available bandwidth, client load and even
> which browser is to parsing the HTML.
>
>> 2) Use nodeJS
>> Indeed, no PHP. No AJAX.
>> NodeJS is extremely fast and supports sockets.
>> If you are a bit familiar with ECMA Script (such as Javascript), try
>> this route.
>
> Another possibility.  So is a Java applet, .NET and probably a dozen
> other ways, all of which he can find better help on an appropriate
> newsgroup.


Of course, if this is all wholly on a _local_ network....


sigh...  
The Internet Of Things is really going to raise the noise floor 
on the interweb.....

[toc] | [prev] | [next] | [standalone]

#15450

On 6/10/2015 12:50 PM, Allodoxaphobia wrote:
> On Wed, 10 Jun 2015 11:55:51 -0400, Jerry Stuckle wrote:
>> On 6/10/2015 10:41 AM, Erwin Moller wrote:
>>> On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
>>>> I want to get response from server every one second, the output will
>>>> contain some value which I need to process in front end.
>>>>
>>>> In backend I am using some queries to read data from mysql and return
>>>> me output.
>>>>
>>>> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
>>>>
>>>> None of these work for me usually it is taking 3-4 seconds to get me
>>>> response,
>>>>
>>>> classic example to see this working(getting output in one sec)
>>>>
>>>> http://madbid.com
>>>>
>>>> Please let me know if anyone has some solution for this.
>>>
>>> Hi,
>>>
>>> I have 2 observations:
>>>
>>> 1) How many clients are requesting that info on the server?
>>> If you have multiple clients, think over your design (i'll come back to
>>> that)
>>> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
>>> What happens?
>>> a) Client request a PHP page
>>> b) Server much launch the process
>>> c) PHP runs, and starts a database query
>>> d) Database processes the query, and answers
>>> e) PHP delivers the answer as output back to the requesting client
>>> f) Client updates the screen
>>>
>>> This is just not feasible every second.
>>> Try that with 1000 clients. ;-)
>>> There is so much overhead involved, and networking, you can't expect
>>> this to run every second.
>>>
>>> Solution:
>>> Create a cronjob that runs every second.
>>> Let it call your PHP script that queries the database.
>>> Instead of responding to a client, let PHP put its output in a file in a
>>> public directory.
>>> Let XHR directly fetch this file.
>>> This is much faster.
>>>
>>> Warning: write the file as myOutput_tmp.xml, then rename to
>>> myOutput.xml, otherwise you risk trying to read a file that is in the
>>> process of being written.
>>> I assume that your PHP script end within the second, otherwise you have
>>> another problem. If, for example, your DB query takes 5 secs, the whole
>>> adventure will fail, whatever you try.
>>>
>>> Did you take timestamps for the whole PHP script (from start to end)?
>>> If that is close to 1 second, you have to find another solutionr
>>
>> While yours are all good suggestions, it's still no guarantee, Erwin.
>> Even just retrieving a static page can take more than 1 second,
>> depending on server load, available bandwidth, client load and even
>> which browser is to parsing the HTML.
>>
>>> 2) Use nodeJS
>>> Indeed, no PHP. No AJAX.
>>> NodeJS is extremely fast and supports sockets.
>>> If you are a bit familiar with ECMA Script (such as Javascript), try
>>> this route.
>>
>> Another possibility.  So is a Java applet, .NET and probably a dozen
>> other ways, all of which he can find better help on an appropriate
>> newsgroup.
> 
> 
> Of course, if this is all wholly on a _local_ network....
>

The same applies to a local network.  They can have slow response time,
also.

> 
> sigh...  
> The Internet Of Things is really going to raise the noise floor 
> on the interweb.....
> 

What is the "interweb"?  There's the world wide web, and internet.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#15451

On Wed, 10 Jun 2015 13:23:31 -0400, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>On 6/10/2015 12:50 PM, Allodoxaphobia wrote:
>> On Wed, 10 Jun 2015 11:55:51 -0400, Jerry Stuckle wrote:
>>> On 6/10/2015 10:41 AM, Erwin Moller wrote:
>>>> On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
>>>>> I want to get response from server every one second, the output will
>>>>> contain some value which I need to process in front end.
>>>>>
>>>>> In backend I am using some queries to read data from mysql and return
>>>>> me output.
>>>>>
>>>>> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
>>>>>
>>>>> None of these work for me usually it is taking 3-4 seconds to get me
>>>>> response,
>>>>>
>>>>> classic example to see this working(getting output in one sec)
>>>>>
>>>>> http://madbid.com
>>>>>
>>>>> Please let me know if anyone has some solution for this.
>>>>
>>>> Hi,
>>>>
>>>> I have 2 observations:
>>>>
>>>> 1) How many clients are requesting that info on the server?
>>>> If you have multiple clients, think over your design (i'll come back to
>>>> that)
>>>> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
>>>> What happens?
>>>> a) Client request a PHP page
>>>> b) Server much launch the process
>>>> c) PHP runs, and starts a database query
>>>> d) Database processes the query, and answers
>>>> e) PHP delivers the answer as output back to the requesting client
>>>> f) Client updates the screen
>>>>
>>>> This is just not feasible every second.
>>>> Try that with 1000 clients. ;-)
>>>> There is so much overhead involved, and networking, you can't expect
>>>> this to run every second.
>>>>
>>>> Solution:
>>>> Create a cronjob that runs every second.
>>>> Let it call your PHP script that queries the database.
>>>> Instead of responding to a client, let PHP put its output in a file in a
>>>> public directory.
>>>> Let XHR directly fetch this file.
>>>> This is much faster.
>>>>
>>>> Warning: write the file as myOutput_tmp.xml, then rename to
>>>> myOutput.xml, otherwise you risk trying to read a file that is in the
>>>> process of being written.
>>>> I assume that your PHP script end within the second, otherwise you have
>>>> another problem. If, for example, your DB query takes 5 secs, the whole
>>>> adventure will fail, whatever you try.
>>>>
>>>> Did you take timestamps for the whole PHP script (from start to end)?
>>>> If that is close to 1 second, you have to find another solutionr
>>>
>>> While yours are all good suggestions, it's still no guarantee, Erwin.
>>> Even just retrieving a static page can take more than 1 second,
>>> depending on server load, available bandwidth, client load and even
>>> which browser is to parsing the HTML.
>>>
>>>> 2) Use nodeJS
>>>> Indeed, no PHP. No AJAX.
>>>> NodeJS is extremely fast and supports sockets.
>>>> If you are a bit familiar with ECMA Script (such as Javascript), try
>>>> this route.
>>>
>>> Another possibility.  So is a Java applet, .NET and probably a dozen
>>> other ways, all of which he can find better help on an appropriate
>>> newsgroup.
>> 
>> 
>> Of course, if this is all wholly on a _local_ network....
>>
>
>The same applies to a local network.  They can have slow response time,
>also.
>
>> 
>> sigh...  
>> The Internet Of Things is really going to raise the noise floor 
>> on the interweb.....
>> 
>
>What is the "interweb"?  

Senator Ted Stevens said that it was all a "series of tubes." 

Allodoxaphobia's use is similarly ridiculous, but in his case it is an
intentional, joking neologism.

[toc] | [prev] | [next] | [standalone]

#15452

On 6/10/2015 1:37 PM, Richard Yates wrote:
> On Wed, 10 Jun 2015 13:23:31 -0400, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
> 
>> On 6/10/2015 12:50 PM, Allodoxaphobia wrote:
>>> On Wed, 10 Jun 2015 11:55:51 -0400, Jerry Stuckle wrote:
>>>> On 6/10/2015 10:41 AM, Erwin Moller wrote:
>>>>> On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
>>>>>> I want to get response from server every one second, the output will
>>>>>> contain some value which I need to process in front end.
>>>>>>
>>>>>> In backend I am using some queries to read data from mysql and return
>>>>>> me output.
>>>>>>
>>>>>> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
>>>>>>
>>>>>> None of these work for me usually it is taking 3-4 seconds to get me
>>>>>> response,
>>>>>>
>>>>>> classic example to see this working(getting output in one sec)
>>>>>>
>>>>>> http://madbid.com
>>>>>>
>>>>>> Please let me know if anyone has some solution for this.
>>>>>
>>>>> Hi,
>>>>>
>>>>> I have 2 observations:
>>>>>
>>>>> 1) How many clients are requesting that info on the server?
>>>>> If you have multiple clients, think over your design (i'll come back to
>>>>> that)
>>>>> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
>>>>> What happens?
>>>>> a) Client request a PHP page
>>>>> b) Server much launch the process
>>>>> c) PHP runs, and starts a database query
>>>>> d) Database processes the query, and answers
>>>>> e) PHP delivers the answer as output back to the requesting client
>>>>> f) Client updates the screen
>>>>>
>>>>> This is just not feasible every second.
>>>>> Try that with 1000 clients. ;-)
>>>>> There is so much overhead involved, and networking, you can't expect
>>>>> this to run every second.
>>>>>
>>>>> Solution:
>>>>> Create a cronjob that runs every second.
>>>>> Let it call your PHP script that queries the database.
>>>>> Instead of responding to a client, let PHP put its output in a file in a
>>>>> public directory.
>>>>> Let XHR directly fetch this file.
>>>>> This is much faster.
>>>>>
>>>>> Warning: write the file as myOutput_tmp.xml, then rename to
>>>>> myOutput.xml, otherwise you risk trying to read a file that is in the
>>>>> process of being written.
>>>>> I assume that your PHP script end within the second, otherwise you have
>>>>> another problem. If, for example, your DB query takes 5 secs, the whole
>>>>> adventure will fail, whatever you try.
>>>>>
>>>>> Did you take timestamps for the whole PHP script (from start to end)?
>>>>> If that is close to 1 second, you have to find another solutionr
>>>>
>>>> While yours are all good suggestions, it's still no guarantee, Erwin.
>>>> Even just retrieving a static page can take more than 1 second,
>>>> depending on server load, available bandwidth, client load and even
>>>> which browser is to parsing the HTML.
>>>>
>>>>> 2) Use nodeJS
>>>>> Indeed, no PHP. No AJAX.
>>>>> NodeJS is extremely fast and supports sockets.
>>>>> If you are a bit familiar with ECMA Script (such as Javascript), try
>>>>> this route.
>>>>
>>>> Another possibility.  So is a Java applet, .NET and probably a dozen
>>>> other ways, all of which he can find better help on an appropriate
>>>> newsgroup.
>>>
>>>
>>> Of course, if this is all wholly on a _local_ network....
>>>
>>
>> The same applies to a local network.  They can have slow response time,
>> also.
>>
>>>
>>> sigh...  
>>> The Internet Of Things is really going to raise the noise floor 
>>> on the interweb.....
>>>
>>
>> What is the "interweb"?  
> 
> Senator Ted Stevens said that it was all a "series of tubes." 
> 
> Allodoxaphobia's use is similarly ridiculous, but in his case it is an
> intentional, joking neologism.
> 

Richard, I'm not sure it is a joke.  I've seen some people who think
it's a real term.  I just don't know any more.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#15453

On Wednesday, June 10, 2015 at 8:11:38 PM UTC+5:30, Erwin Moller wrote:
> On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
> > I want to get response from server every one second, the output will contain some value which I need to process in front end.
> >
> > In backend I am using some queries to read data from mysql and return me output.
> >
> > Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
> >
> > None of these work for me usually it is taking 3-4 seconds to get me response,
> >
> > classic example to see this working(getting output in one sec)
> >
> > http://madbid.com
> >
> > Please let me know if anyone has some solution for this.
> >
> 
> Hi,
> 
> I have 2 observations:
> 
> 1) How many clients are requesting that info on the server?
> If you have multiple clients, think over your design (i'll come back to 
> that)
> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
> What happens?
> a) Client request a PHP page
> b) Server much launch the process
> c) PHP runs, and starts a database query
> d) Database processes the query, and answers
> e) PHP delivers the answer as output back to the requesting client
> f) Client updates the screen
> 
> This is just not feasible every second.
> Try that with 1000 clients. ;-)
> There is so much overhead involved, and networking, you can't expect 
> this to run every second.
> 
> Solution:
> Create a cronjob that runs every second.
> Let it call your PHP script that queries the database.
> Instead of responding to a client, let PHP put its output in a file in a 
> public directory.
> Let XHR directly fetch this file.
> This is much faster.
> 
> Warning: write the file as myOutput_tmp.xml, then rename to 
> myOutput.xml, otherwise you risk trying to read a file that is in the 
> process of being written.
> I assume that your PHP script end within the second, otherwise you have 
> another problem. If, for example, your DB query takes 5 secs, the whole 
> adventure will fail, whatever you try.
> 
> Did you take timestamps for the whole PHP script (from start to end)?
> If that is close to 1 second, you have to find another solution.
> 
> 2) Use nodeJS
> Indeed, no PHP. No AJAX.
> NodeJS is extremely fast and supports sockets.
> If you are a bit familiar with ECMA Script (such as Javascript), try 
> this route.
> 
> Good luck
> 
> Regards,
> Erwin Moller
> 
> -- 
> "That which can be asserted without evidence, can be dismissed without 
> evidence."
> -- Christopher Hitchens

Thanks for your answer Erwin If we use web sockets the whole point is that we don't have to  make connection to the database every time can we use same with php and httprequest aka ajax and use a persistent connection so that we dont have to make the connection every time we query the database would that make things faster.

[toc] | [prev] | [next] | [standalone]

#15454

On Wednesday, June 10, 2015 at 8:11:38 PM UTC+5:30, Erwin Moller wrote:
> On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
> > I want to get response from server every one second, the output will contain some value which I need to process in front end.
> >
> > In backend I am using some queries to read data from mysql and return me output.
> >
> > Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
> >
> > None of these work for me usually it is taking 3-4 seconds to get me response,
> >
> > classic example to see this working(getting output in one sec)
> >
> > http://madbid.com
> >
> > Please let me know if anyone has some solution for this.
> >
> 
> Hi,
> 
> I have 2 observations:
> 
> 1) How many clients are requesting that info on the server?
> If you have multiple clients, think over your design (i'll come back to 
> that)
> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
> What happens?
> a) Client request a PHP page
> b) Server much launch the process
> c) PHP runs, and starts a database query
> d) Database processes the query, and answers
> e) PHP delivers the answer as output back to the requesting client
> f) Client updates the screen
> 
> This is just not feasible every second.
> Try that with 1000 clients. ;-)
> There is so much overhead involved, and networking, you can't expect 
> this to run every second.
> 
> Solution:
> Create a cronjob that runs every second.
> Let it call your PHP script that queries the database.
> Instead of responding to a client, let PHP put its output in a file in a 
> public directory.
> Let XHR directly fetch this file.
> This is much faster.
> 
> Warning: write the file as myOutput_tmp.xml, then rename to 
> myOutput.xml, otherwise you risk trying to read a file that is in the 
> process of being written.
> I assume that your PHP script end within the second, otherwise you have 
> another problem. If, for example, your DB query takes 5 secs, the whole 
> adventure will fail, whatever you try.
> 
> Did you take timestamps for the whole PHP script (from start to end)?
> If that is close to 1 second, you have to find another solution.
> 
> 2) Use nodeJS
> Indeed, no PHP. No AJAX.
> NodeJS is extremely fast and supports sockets.
> If you are a bit familiar with ECMA Script (such as Javascript), try 
> this route.
> 
> Good luck
> 
> Regards,
> Erwin Moller
> 
> -- 
> "That which can be asserted without evidence, can be dismissed without 
> evidence."
> -- Christopher Hitchens

Hello Erwin Thanks for your answer The whole point of web socket is that we dont have to make the connection to the database every time but if we use persistent connection with php and ajax would that make things faster.

[toc] | [prev] | [next] | [standalone]

#15455

On 6/11/2015 9:14 AM, apoorv.kanungo@gmail.com wrote:
> On Wednesday, June 10, 2015 at 8:11:38 PM UTC+5:30, Erwin Moller wrote:
>> On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
>>> I want to get response from server every one second, the output will contain some value which I need to process in front end.
>>>
>>> In backend I am using some queries to read data from mysql and return me output.
>>>
>>> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
>>>
>>> None of these work for me usually it is taking 3-4 seconds to get me response,
>>>
>>> classic example to see this working(getting output in one sec)
>>>
>>> http://madbid.com
>>>
>>> Please let me know if anyone has some solution for this.
>>>
>>
>> Hi,
>>
>> I have 2 observations:
>>
>> 1) How many clients are requesting that info on the server?
>> If you have multiple clients, think over your design (i'll come back to
>> that)
>> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
>> What happens?
>> a) Client request a PHP page
>> b) Server much launch the process
>> c) PHP runs, and starts a database query
>> d) Database processes the query, and answers
>> e) PHP delivers the answer as output back to the requesting client
>> f) Client updates the screen
>>
>> This is just not feasible every second.
>> Try that with 1000 clients. ;-)
>> There is so much overhead involved, and networking, you can't expect
>> this to run every second.
>>
>> Solution:
>> Create a cronjob that runs every second.
>> Let it call your PHP script that queries the database.
>> Instead of responding to a client, let PHP put its output in a file in a
>> public directory.
>> Let XHR directly fetch this file.
>> This is much faster.
>>
>> Warning: write the file as myOutput_tmp.xml, then rename to
>> myOutput.xml, otherwise you risk trying to read a file that is in the
>> process of being written.
>> I assume that your PHP script end within the second, otherwise you have
>> another problem. If, for example, your DB query takes 5 secs, the whole
>> adventure will fail, whatever you try.
>>
>> Did you take timestamps for the whole PHP script (from start to end)?
>> If that is close to 1 second, you have to find another solution.
>>
>> 2) Use nodeJS
>> Indeed, no PHP. No AJAX.
>> NodeJS is extremely fast and supports sockets.
>> If you are a bit familiar with ECMA Script (such as Javascript), try
>> this route.
>>
>> Good luck
>>
>> Regards,
>> Erwin Moller
>>
>> --
>> "That which can be asserted without evidence, can be dismissed without
>> evidence."
>> -- Christopher Hitchens
>
> Hello Erwin Thanks for your answer The whole point of web socket is that we dont have to make the connection to the database every time but if we use persistent connection with php and ajax would that make things faster.
>

I cannot follow you.
As I understand you want:
- A client that gets an update on something that could happen in the 
database.
- This should happen every second.

So, do you need to query a database or not?
And yes, sockets are much faster than invoking a fresh HTTP request.

Good luck,

Regards,
Erwin Moller




-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#15456

On Thursday, June 11, 2015 at 3:39:56 PM UTC+5:30, Erwin Moller wrote:
> On 6/11/2015 9:14 AM, apoorv.kanungo@gmail.com wrote:
> > On Wednesday, June 10, 2015 at 8:11:38 PM UTC+5:30, Erwin Moller wrote:
> >> On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
> >>> I want to get response from server every one second, the output will contain some value which I need to process in front end.
> >>>
> >>> In backend I am using some queries to read data from mysql and return me output.
> >>>
> >>> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
> >>>
> >>> None of these work for me usually it is taking 3-4 seconds to get me response,
> >>>
> >>> classic example to see this working(getting output in one sec)
> >>>
> >>> http://madbid.com
> >>>
> >>> Please let me know if anyone has some solution for this.
> >>>
> >>
> >> Hi,
> >>
> >> I have 2 observations:
> >>
> >> 1) How many clients are requesting that info on the server?
> >> If you have multiple clients, think over your design (i'll come back to
> >> that)
> >> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
> >> What happens?
> >> a) Client request a PHP page
> >> b) Server much launch the process
> >> c) PHP runs, and starts a database query
> >> d) Database processes the query, and answers
> >> e) PHP delivers the answer as output back to the requesting client
> >> f) Client updates the screen
> >>
> >> This is just not feasible every second.
> >> Try that with 1000 clients. ;-)
> >> There is so much overhead involved, and networking, you can't expect
> >> this to run every second.
> >>
> >> Solution:
> >> Create a cronjob that runs every second.
> >> Let it call your PHP script that queries the database.
> >> Instead of responding to a client, let PHP put its output in a file in a
> >> public directory.
> >> Let XHR directly fetch this file.
> >> This is much faster.
> >>
> >> Warning: write the file as myOutput_tmp.xml, then rename to
> >> myOutput.xml, otherwise you risk trying to read a file that is in the
> >> process of being written.
> >> I assume that your PHP script end within the second, otherwise you have
> >> another problem. If, for example, your DB query takes 5 secs, the whole
> >> adventure will fail, whatever you try.
> >>
> >> Did you take timestamps for the whole PHP script (from start to end)?
> >> If that is close to 1 second, you have to find another solution.
> >>
> >> 2) Use nodeJS
> >> Indeed, no PHP. No AJAX.
> >> NodeJS is extremely fast and supports sockets.
> >> If you are a bit familiar with ECMA Script (such as Javascript), try
> >> this route.
> >>
> >> Good luck
> >>
> >> Regards,
> >> Erwin Moller
> >>
> >> --
> >> "That which can be asserted without evidence, can be dismissed without
> >> evidence."
> >> -- Christopher Hitchens
> >
> > Hello Erwin Thanks for your answer The whole point of web socket is that we dont have to make the connection to the database every time but if we use persistent connection with php and ajax would that make things faster.
> >
> 
> I cannot follow you.
> As I understand you want:
> - A client that gets an update on something that could happen in the 
> database.
> - This should happen every second.
> 
> So, do you need to query a database or not?
> And yes, sockets are much faster than invoking a fresh HTTP request.
> 
> Good luck,
> 
> Regards,
> Erwin Moller
> 
> 
> 
> 
> -- 
> "That which can be asserted without evidence, can be dismissed without 
> evidence."
> -- Christopher Hitchens

Yes buddy I want to query the database and I want it to happen fast so the user won't feel any latency.

It's more like a bidding platform when a user bid on a item that value is stored in database when he bids again that value is updated or new value is inserted in database with the same id and so on.

now imagine thousands of user logging in and bidding and there is a sort of timer that updates itself every time a user bids. The person who bid last when the timer expires will be declared winner of the bid.  
   

[toc] | [prev] | [next] | [standalone]

#15457

On 6/11/2015 1:16 PM, apoorv.kanungo@gmail.com wrote:
> On Thursday, June 11, 2015 at 3:39:56 PM UTC+5:30, Erwin Moller wrote:
>> On 6/11/2015 9:14 AM, apoorv.kanungo@gmail.com wrote:
>>> On Wednesday, June 10, 2015 at 8:11:38 PM UTC+5:30, Erwin Moller wrote:
>>>> On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
>>>>> I want to get response from server every one second, the output will contain some value which I need to process in front end.
>>>>>
>>>>> In backend I am using some queries to read data from mysql and return me output.
>>>>>
>>>>> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
>>>>>
>>>>> None of these work for me usually it is taking 3-4 seconds to get me response,
>>>>>
>>>>> classic example to see this working(getting output in one sec)
>>>>>
>>>>> http://madbid.com
>>>>>
>>>>> Please let me know if anyone has some solution for this.
>>>>>
>>>>
>>>> Hi,
>>>>
>>>> I have 2 observations:
>>>>
>>>> 1) How many clients are requesting that info on the server?
>>>> If you have multiple clients, think over your design (i'll come back to
>>>> that)
>>>> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
>>>> What happens?
>>>> a) Client request a PHP page
>>>> b) Server much launch the process
>>>> c) PHP runs, and starts a database query
>>>> d) Database processes the query, and answers
>>>> e) PHP delivers the answer as output back to the requesting client
>>>> f) Client updates the screen
>>>>
>>>> This is just not feasible every second.
>>>> Try that with 1000 clients. ;-)
>>>> There is so much overhead involved, and networking, you can't expect
>>>> this to run every second.
>>>>
>>>> Solution:
>>>> Create a cronjob that runs every second.
>>>> Let it call your PHP script that queries the database.
>>>> Instead of responding to a client, let PHP put its output in a file in a
>>>> public directory.
>>>> Let XHR directly fetch this file.
>>>> This is much faster.
>>>>
>>>> Warning: write the file as myOutput_tmp.xml, then rename to
>>>> myOutput.xml, otherwise you risk trying to read a file that is in the
>>>> process of being written.
>>>> I assume that your PHP script end within the second, otherwise you have
>>>> another problem. If, for example, your DB query takes 5 secs, the whole
>>>> adventure will fail, whatever you try.
>>>>
>>>> Did you take timestamps for the whole PHP script (from start to end)?
>>>> If that is close to 1 second, you have to find another solution.
>>>>
>>>> 2) Use nodeJS
>>>> Indeed, no PHP. No AJAX.
>>>> NodeJS is extremely fast and supports sockets.
>>>> If you are a bit familiar with ECMA Script (such as Javascript), try
>>>> this route.
>>>>
>>>> Good luck
>>>>
>>>> Regards,
>>>> Erwin Moller
>>>>
>>>> --
>>>> "That which can be asserted without evidence, can be dismissed without
>>>> evidence."
>>>> -- Christopher Hitchens
>>>
>>> Hello Erwin Thanks for your answer The whole point of web socket is that we dont have to make the connection to the database every time but if we use persistent connection with php and ajax would that make things faster.
>>>
>>
>> I cannot follow you.
>> As I understand you want:
>> - A client that gets an update on something that could happen in the
>> database.
>> - This should happen every second.
>>
>> So, do you need to query a database or not?
>> And yes, sockets are much faster than invoking a fresh HTTP request.
>>
>> Good luck,
>>
>> Regards,
>> Erwin Moller
>>
>>
>>
>>
>> --
>> "That which can be asserted without evidence, can be dismissed without
>> evidence."
>> -- Christopher Hitchens
>
> Yes buddy I want to query the database and I want it to happen fast so the user won't feel any latency.
>
> It's more like a bidding platform when a user bid on a item that value is stored in database when he bids again that value is updated or new value is inserted in database with the same id and so on.
>
> now imagine thousands of user logging in and bidding and there is a sort of timer that updates itself every time a user bids. The person who bid last when the timer expires will be declared winner of the bid.
>
>

OK buddy,
So you cannot use my first suggestion, because you have different 
queries for all clients, right?

In that case you have the following needs:
Some sort of socket communication with a running process on the server.
You don't even have to store it in the database, you can keep the bids 
in-process (in-memory) instead of loosing precious time on database 
communication. In-process is bloody fast.

After each auction is done, you can optionally store that data in a 
database for later examination/debugging/marketing.

In any case: go sockets. Avoid HXR (Ajax)
You will have a huge performance increase that way.

I advise NodeJS over Java Applets because there is less technical 
involvement needed on the client-side. With Applets your visitor has to 
keep Java up to date, and must possible allow certain permissions.
Many people don't get that (they let everybody on the internet these days!)
NodeJS is completely transparent for the user (but less robust/mature 
than Java I must say). But I am sure NodeJS can do the job of an auction 
just fine.

But you cannot reliable deliver an update each second. Networking over 
the whole world just isn't reliable enough for that. ;-)

Good luck.

Regards,
Erwin Moller

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#15458

On Thursday, June 11, 2015 at 6:07:55 PM UTC+5:30, Erwin Moller wrote:
> On 6/11/2015 1:16 PM, apoorv.kanungo@gmail.com wrote:
> > On Thursday, June 11, 2015 at 3:39:56 PM UTC+5:30, Erwin Moller wrote:
> >> On 6/11/2015 9:14 AM, apoorv.kanungo@gmail.com wrote:
> >>> On Wednesday, June 10, 2015 at 8:11:38 PM UTC+5:30, Erwin Moller wrote:
> >>>> On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
> >>>>> I want to get response from server every one second, the output will contain some value which I need to process in front end.
> >>>>>
> >>>>> In backend I am using some queries to read data from mysql and return me output.
> >>>>>
> >>>>> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
> >>>>>
> >>>>> None of these work for me usually it is taking 3-4 seconds to get me response,
> >>>>>
> >>>>> classic example to see this working(getting output in one sec)
> >>>>>
> >>>>> http://madbid.com
> >>>>>
> >>>>> Please let me know if anyone has some solution for this.
> >>>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> I have 2 observations:
> >>>>
> >>>> 1) How many clients are requesting that info on the server?
> >>>> If you have multiple clients, think over your design (i'll come back to
> >>>> that)
> >>>> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
> >>>> What happens?
> >>>> a) Client request a PHP page
> >>>> b) Server much launch the process
> >>>> c) PHP runs, and starts a database query
> >>>> d) Database processes the query, and answers
> >>>> e) PHP delivers the answer as output back to the requesting client
> >>>> f) Client updates the screen
> >>>>
> >>>> This is just not feasible every second.
> >>>> Try that with 1000 clients. ;-)
> >>>> There is so much overhead involved, and networking, you can't expect
> >>>> this to run every second.
> >>>>
> >>>> Solution:
> >>>> Create a cronjob that runs every second.
> >>>> Let it call your PHP script that queries the database.
> >>>> Instead of responding to a client, let PHP put its output in a file in a
> >>>> public directory.
> >>>> Let XHR directly fetch this file.
> >>>> This is much faster.
> >>>>
> >>>> Warning: write the file as myOutput_tmp.xml, then rename to
> >>>> myOutput.xml, otherwise you risk trying to read a file that is in the
> >>>> process of being written.
> >>>> I assume that your PHP script end within the second, otherwise you have
> >>>> another problem. If, for example, your DB query takes 5 secs, the whole
> >>>> adventure will fail, whatever you try.
> >>>>
> >>>> Did you take timestamps for the whole PHP script (from start to end)?
> >>>> If that is close to 1 second, you have to find another solution.
> >>>>
> >>>> 2) Use nodeJS
> >>>> Indeed, no PHP. No AJAX.
> >>>> NodeJS is extremely fast and supports sockets.
> >>>> If you are a bit familiar with ECMA Script (such as Javascript), try
> >>>> this route.
> >>>>
> >>>> Good luck
> >>>>
> >>>> Regards,
> >>>> Erwin Moller
> >>>>
> >>>> --
> >>>> "That which can be asserted without evidence, can be dismissed without
> >>>> evidence."
> >>>> -- Christopher Hitchens
> >>>
> >>> Hello Erwin Thanks for your answer The whole point of web socket is that we dont have to make the connection to the database every time but if we use persistent connection with php and ajax would that make things faster.
> >>>
> >>
> >> I cannot follow you.
> >> As I understand you want:
> >> - A client that gets an update on something that could happen in the
> >> database.
> >> - This should happen every second.
> >>
> >> So, do you need to query a database or not?
> >> And yes, sockets are much faster than invoking a fresh HTTP request.
> >>
> >> Good luck,
> >>
> >> Regards,
> >> Erwin Moller
> >>
> >>
> >>
> >>
> >> --
> >> "That which can be asserted without evidence, can be dismissed without
> >> evidence."
> >> -- Christopher Hitchens
> >
> > Yes buddy I want to query the database and I want it to happen fast so the user won't feel any latency.
> >
> > It's more like a bidding platform when a user bid on a item that value is stored in database when he bids again that value is updated or new value is inserted in database with the same id and so on.
> >
> > now imagine thousands of user logging in and bidding and there is a sort of timer that updates itself every time a user bids. The person who bid last when the timer expires will be declared winner of the bid.
> >
> >
> 
> OK buddy,
> So you cannot use my first suggestion, because you have different 
> queries for all clients, right?
> 
> In that case you have the following needs:
> Some sort of socket communication with a running process on the server.
> You don't even have to store it in the database, you can keep the bids 
> in-process (in-memory) instead of loosing precious time on database 
> communication. In-process is bloody fast.
> 
> After each auction is done, you can optionally store that data in a 
> database for later examination/debugging/marketing.
> 
> In any case: go sockets. Avoid HXR (Ajax)
> You will have a huge performance increase that way.
> 
> I advise NodeJS over Java Applets because there is less technical 
> involvement needed on the client-side. With Applets your visitor has to 
> keep Java up to date, and must possible allow certain permissions.
> Many people don't get that (they let everybody on the internet these days!)
> NodeJS is completely transparent for the user (but less robust/mature 
> than Java I must say). But I am sure NodeJS can do the job of an auction 
> just fine.
> 
> But you cannot reliable deliver an update each second. Networking over 
> the whole world just isn't reliable enough for that. ;-)
> 
> Good luck.
> 
> Regards,
> Erwin Moller
> 
> -- 
> "That which can be asserted without evidence, can be dismissed without 
> evidence."
> -- Christopher Hitchens

Thanks for valuable output and  I  think I  will only need one query for all the user that will carry their id with them.

I am keeping nodejs as an absolute last option because I am not very familiar with it and I have a shared hosting which won't support nodejs.

Can I  use html local storage I assume that will be faster and later I will store that in the database.   

[toc] | [prev] | [next] | [standalone]

#15459

apoorv.kanungo@gmail.com writes:

> Thanks for valuable output and I think I will only need one query for
> all the user that will carry their id with them.
>
> I am keeping nodejs as an absolute last option because I am not very
> familiar with it and I have a shared hosting which won't support
> nodejs.
>
> Can I use html local storage I assume that will be faster and later I
> will store that in the database.

Your options are HTTP requests or sockets.

If your requirement is 1s on the dot, you can't do it with HTTP
requests, as there is no guarantee a web server will respond within 1
second of a request firing off.

A socket is much faster, as it's a persistent connection which can
receive events (there is still no 100% guarantee of a reply every 1
second, but you'll have more success adhering to this with sockets than
HTTP requests - less overhead and not polling or request/response
based).

You could do with fine with javascript and HTTP if, instead of a firm 1s
requirement, you just make chained requests/local updates (think -
instead of using a setInterval javascript call to poll the server on a
1000ms timeout, recursively call your javascript polling function as
part of the success condition).

Maybe that would look (to the user) like an update at the 1s mark, 3s
mark, 8s mark etc.

That's going to be the best you'll get with shared hosting imho.

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [next] | [standalone]

#15463

On Thursday, June 11, 2015 at 6:07:55 PM UTC+5:30, Erwin Moller wrote:
> On 6/11/2015 1:16 PM, apoorv.kanungo@gmail.com wrote:
> > On Thursday, June 11, 2015 at 3:39:56 PM UTC+5:30, Erwin Moller wrote:
> >> On 6/11/2015 9:14 AM, apoorv.kanungo@gmail.com wrote:
> >>> On Wednesday, June 10, 2015 at 8:11:38 PM UTC+5:30, Erwin Moller wrote:
> >>>> On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
> >>>>> I want to get response from server every one second, the output will contain some value which I need to process in front end.
> >>>>>
> >>>>> In backend I am using some queries to read data from mysql and return me output.
> >>>>>
> >>>>> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
> >>>>>
> >>>>> None of these work for me usually it is taking 3-4 seconds to get me response,
> >>>>>
> >>>>> classic example to see this working(getting output in one sec)
> >>>>>
> >>>>> http://madbid.com
> >>>>>
> >>>>> Please let me know if anyone has some solution for this.
> >>>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> I have 2 observations:
> >>>>
> >>>> 1) How many clients are requesting that info on the server?
> >>>> If you have multiple clients, think over your design (i'll come back to
> >>>> that)
> >>>> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
> >>>> What happens?
> >>>> a) Client request a PHP page
> >>>> b) Server much launch the process
> >>>> c) PHP runs, and starts a database query
> >>>> d) Database processes the query, and answers
> >>>> e) PHP delivers the answer as output back to the requesting client
> >>>> f) Client updates the screen
> >>>>
> >>>> This is just not feasible every second.
> >>>> Try that with 1000 clients. ;-)
> >>>> There is so much overhead involved, and networking, you can't expect
> >>>> this to run every second.
> >>>>
> >>>> Solution:
> >>>> Create a cronjob that runs every second.
> >>>> Let it call your PHP script that queries the database.
> >>>> Instead of responding to a client, let PHP put its output in a file in a
> >>>> public directory.
> >>>> Let XHR directly fetch this file.
> >>>> This is much faster.
> >>>>
> >>>> Warning: write the file as myOutput_tmp.xml, then rename to
> >>>> myOutput.xml, otherwise you risk trying to read a file that is in the
> >>>> process of being written.
> >>>> I assume that your PHP script end within the second, otherwise you have
> >>>> another problem. If, for example, your DB query takes 5 secs, the whole
> >>>> adventure will fail, whatever you try.
> >>>>
> >>>> Did you take timestamps for the whole PHP script (from start to end)?
> >>>> If that is close to 1 second, you have to find another solution.
> >>>>
> >>>> 2) Use nodeJS
> >>>> Indeed, no PHP. No AJAX.
> >>>> NodeJS is extremely fast and supports sockets.
> >>>> If you are a bit familiar with ECMA Script (such as Javascript), try
> >>>> this route.
> >>>>
> >>>> Good luck
> >>>>
> >>>> Regards,
> >>>> Erwin Moller
> >>>>
> >>>> --
> >>>> "That which can be asserted without evidence, can be dismissed without
> >>>> evidence."
> >>>> -- Christopher Hitchens
> >>>
> >>> Hello Erwin Thanks for your answer The whole point of web socket is that we dont have to make the connection to the database every time but if we use persistent connection with php and ajax would that make things faster.
> >>>
> >>
> >> I cannot follow you.
> >> As I understand you want:
> >> - A client that gets an update on something that could happen in the
> >> database.
> >> - This should happen every second.
> >>
> >> So, do you need to query a database or not?
> >> And yes, sockets are much faster than invoking a fresh HTTP request.
> >>
> >> Good luck,
> >>
> >> Regards,
> >> Erwin Moller
> >>
> >>
> >>
> >>
> >> --
> >> "That which can be asserted without evidence, can be dismissed without
> >> evidence."
> >> -- Christopher Hitchens
> >
> > Yes buddy I want to query the database and I want it to happen fast so the user won't feel any latency.
> >
> > It's more like a bidding platform when a user bid on a item that value is stored in database when he bids again that value is updated or new value is inserted in database with the same id and so on.
> >
> > now imagine thousands of user logging in and bidding and there is a sort of timer that updates itself every time a user bids. The person who bid last when the timer expires will be declared winner of the bid.
> >
> >
> 
> OK buddy,
> So you cannot use my first suggestion, because you have different 
> queries for all clients, right?
> 
> In that case you have the following needs:
> Some sort of socket communication with a running process on the server.
> You don't even have to store it in the database, you can keep the bids 
> in-process (in-memory) instead of loosing precious time on database 
> communication. In-process is bloody fast.
> 
> After each auction is done, you can optionally store that data in a 
> database for later examination/debugging/marketing.
> 
> In any case: go sockets. Avoid HXR (Ajax)
> You will have a huge performance increase that way.
> 
> I advise NodeJS over Java Applets because there is less technical 
> involvement needed on the client-side. With Applets your visitor has to 
> keep Java up to date, and must possible allow certain permissions.
> Many people don't get that (they let everybody on the internet these days!)
> NodeJS is completely transparent for the user (but less robust/mature 
> than Java I must say). But I am sure NodeJS can do the job of an auction 
> just fine.
> 
> But you cannot reliable deliver an update each second. Networking over 
> the whole world just isn't reliable enough for that. ;-)
> 
> Good luck.
> 
> Regards,
> Erwin Moller
> 
> -- 
> "That which can be asserted without evidence, can be dismissed without 
> evidence."
> -- Christopher Hitchens

hello Erwin I hope you are doing well I am seriously considering your cron job option But I checked in the cpanel that cron job can only be set up for 
minimum of one minute so how could I set that up for one minute thanks for your help so far. 

[toc] | [prev] | [next] | [standalone]

#15466

On 6/12/2015 2:35 AM, apoorv.kanungo@gmail.com wrote:
> On Thursday, June 11, 2015 at 6:07:55 PM UTC+5:30, Erwin Moller wrote:
>> On 6/11/2015 1:16 PM, apoorv.kanungo@gmail.com wrote:
>>> On Thursday, June 11, 2015 at 3:39:56 PM UTC+5:30, Erwin Moller wrote:
>>>> On 6/11/2015 9:14 AM, apoorv.kanungo@gmail.com wrote:
>>>>> On Wednesday, June 10, 2015 at 8:11:38 PM UTC+5:30, Erwin Moller wrote:
>>>>>> On 6/10/2015 3:59 PM, apoorv.kanungo@gmail.com wrote:
>>>>>>> I want to get response from server every one second, the output will contain some value which I need to process in front end.
>>>>>>>
>>>>>>> In backend I am using some queries to read data from mysql and return me output.
>>>>>>>
>>>>>>> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
>>>>>>>
>>>>>>> None of these work for me usually it is taking 3-4 seconds to get me response,
>>>>>>>
>>>>>>> classic example to see this working(getting output in one sec)
>>>>>>>
>>>>>>> http://madbid.com
>>>>>>>
>>>>>>> Please let me know if anyone has some solution for this.
>>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have 2 observations:
>>>>>>
>>>>>> 1) How many clients are requesting that info on the server?
>>>>>> If you have multiple clients, think over your design (i'll come back to
>>>>>> that)
>>>>>> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
>>>>>> What happens?
>>>>>> a) Client request a PHP page
>>>>>> b) Server much launch the process
>>>>>> c) PHP runs, and starts a database query
>>>>>> d) Database processes the query, and answers
>>>>>> e) PHP delivers the answer as output back to the requesting client
>>>>>> f) Client updates the screen
>>>>>>
>>>>>> This is just not feasible every second.
>>>>>> Try that with 1000 clients. ;-)
>>>>>> There is so much overhead involved, and networking, you can't expect
>>>>>> this to run every second.
>>>>>>
>>>>>> Solution:
>>>>>> Create a cronjob that runs every second.
>>>>>> Let it call your PHP script that queries the database.
>>>>>> Instead of responding to a client, let PHP put its output in a file in a
>>>>>> public directory.
>>>>>> Let XHR directly fetch this file.
>>>>>> This is much faster.
>>>>>>
>>>>>> Warning: write the file as myOutput_tmp.xml, then rename to
>>>>>> myOutput.xml, otherwise you risk trying to read a file that is in the
>>>>>> process of being written.
>>>>>> I assume that your PHP script end within the second, otherwise you have
>>>>>> another problem. If, for example, your DB query takes 5 secs, the whole
>>>>>> adventure will fail, whatever you try.
>>>>>>
>>>>>> Did you take timestamps for the whole PHP script (from start to end)?
>>>>>> If that is close to 1 second, you have to find another solution.
>>>>>>
>>>>>> 2) Use nodeJS
>>>>>> Indeed, no PHP. No AJAX.
>>>>>> NodeJS is extremely fast and supports sockets.
>>>>>> If you are a bit familiar with ECMA Script (such as Javascript), try
>>>>>> this route.
>>>>>>
>>>>>> Good luck
>>>>>>
>>>>>> Regards,
>>>>>> Erwin Moller
>>>>>>
>>>>>> --
>>>>>> "That which can be asserted without evidence, can be dismissed without
>>>>>> evidence."
>>>>>> -- Christopher Hitchens
>>>>>
>>>>> Hello Erwin Thanks for your answer The whole point of web socket is that we dont have to make the connection to the database every time but if we use persistent connection with php and ajax would that make things faster.
>>>>>
>>>>
>>>> I cannot follow you.
>>>> As I understand you want:
>>>> - A client that gets an update on something that could happen in the
>>>> database.
>>>> - This should happen every second.
>>>>
>>>> So, do you need to query a database or not?
>>>> And yes, sockets are much faster than invoking a fresh HTTP request.
>>>>
>>>> Good luck,
>>>>
>>>> Regards,
>>>> Erwin Moller
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> "That which can be asserted without evidence, can be dismissed without
>>>> evidence."
>>>> -- Christopher Hitchens
>>>
>>> Yes buddy I want to query the database and I want it to happen fast so the user won't feel any latency.
>>>
>>> It's more like a bidding platform when a user bid on a item that value is stored in database when he bids again that value is updated or new value is inserted in database with the same id and so on.
>>>
>>> now imagine thousands of user logging in and bidding and there is a sort of timer that updates itself every time a user bids. The person who bid last when the timer expires will be declared winner of the bid.
>>>
>>>
>>
>> OK buddy,
>> So you cannot use my first suggestion, because you have different 
>> queries for all clients, right?
>>
>> In that case you have the following needs:
>> Some sort of socket communication with a running process on the server.
>> You don't even have to store it in the database, you can keep the bids 
>> in-process (in-memory) instead of loosing precious time on database 
>> communication. In-process is bloody fast.
>>
>> After each auction is done, you can optionally store that data in a 
>> database for later examination/debugging/marketing.
>>
>> In any case: go sockets. Avoid HXR (Ajax)
>> You will have a huge performance increase that way.
>>
>> I advise NodeJS over Java Applets because there is less technical 
>> involvement needed on the client-side. With Applets your visitor has to 
>> keep Java up to date, and must possible allow certain permissions.
>> Many people don't get that (they let everybody on the internet these days!)
>> NodeJS is completely transparent for the user (but less robust/mature 
>> than Java I must say). But I am sure NodeJS can do the job of an auction 
>> just fine.
>>
>> But you cannot reliable deliver an update each second. Networking over 
>> the whole world just isn't reliable enough for that. ;-)
>>
>> Good luck.
>>
>> Regards,
>> Erwin Moller
>>
>> -- 
>> "That which can be asserted without evidence, can be dismissed without 
>> evidence."
>> -- Christopher Hitchens
> 
> hello Erwin I hope you are doing well I am seriously considering your cron job option But I checked in the cpanel that cron job can only be set up for 
> minimum of one minute so how could I set that up for one minute thanks for your help so far. 
> 

If your hosting company won't allow you to run a cron job once a second
(most shared hosting companies won't due to the overhead), you won't be
able to get one second response times.

The more I think about it, I don't think you'll be able to reliably get
the response time you want on a shared server.  You're going to be
taking a lot of resources, especially if you get more than a handful of
users on your system at one time.

If a one second response time is critical, you will probably need to go
with a virtual private system (VPS) or, more probably, a dedicated
server.  Both require significantly more expertise as you will be
responsible for maintaining the operating system and system security as
well as your web site.  And then if you want CPanel you'll have to spend
even more.

And then, as Denis says, you'll need a good programmer to do the back
end.  There aren't that many around who are good at high performance
systems (although there are a lot who claim to be).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#15460

On Thu, 11 Jun 2015 04:16:57 -0700, apoorv.kanungo wrote:

> now imagine thousands of user logging in and bidding and there is a sort
> of timer that updates itself every time a user bids. The person who bid
> last when the timer expires will be declared winner of the bid.

You can't do High Frequency Trading in across the web using javascript 
clients. It's just not possible. You need dedicated platforms with 
compiled code connected to the exchanges using very high speed networks.

The levels of performance you are looking for are going to be made in the 
back end processing, which is going to need very careful design and 
serious performance tuning and optimisations.

Those of us who do have the knowledge to design such systems (and I am 
not one of them) probably expect to be paid a great deal of money to do 
so. You're unlikely to get that free in a newsgroup.

If you want an ebay clone, you need to recruit the sort of programmers 
and build the sort of infrastructure and codebase that ebay has.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#15468 — [off topic nodejs advertisement] Was Re: response for server every second

On 6/12/2015 5:59 AM, Denis McMahon wrote:
> On Thu, 11 Jun 2015 04:16:57 -0700, apoorv.kanungo wrote:
>
>> now imagine thousands of user logging in and bidding and there is a sort
>> of timer that updates itself every time a user bids. The person who bid
>> last when the timer expires will be declared winner of the bid.
>
> You can't do High Frequency Trading in across the web using javascript
> clients. It's just not possible.

I don't want to downplay some excellent point in your post, but nodejs + 
its built-in sockets makes an ideal solution for real time trading.

Client side isn't really the problem.
The server + network (response time) is the bottleneck.
Unless you don't know what you are doing (using some stupid framework 
for example), I don't see how the client-side scripting will be the 
bottleneck.

You can look at some impressive concurrency testing results here:
(Nodejs versus Apache/PHP)

http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php

Nodejs performs very well under high load, keeping short response times.

Of course, if you add more requirements, nodejs might not be the ideal 
solution, but it is fast.

Combine that with nodejs's included socket communication to clients, and 
you have a pretty good environment for real time trading, I expect.

I don't have experience with database connectivity in nodejs yet, but it 
supports Postgres, mysql, etc.
But everything in Nodejs is based on callback functions, so no blocking 
occurs. (Same for disk IO, etc)

Well, let's just say I am pretty impressed by Nodejs. :-)

Regards,
Erwin Moller



-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#15470 — Performance of PHP vs. Node.js (was: [off topic nodejs advertisement])

Erwin Moller wrote:

> You can look at some impressive concurrency testing results here:
> (Nodejs versus Apache/PHP)
> 
> http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php

Comparing the speed of a truck and a sports car might not be reasonable.
 So have a look at
<https://philsturgeon.uk/blog/2013/11/benchmarking-codswallop-nodejs-v-php/>.
:)

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.php

csiph-web