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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#15471 — Re: Performance of PHP vs. Node.js

On 6/15/2015 8:42 PM, Christoph M. Becker wrote:
> 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/>.
> :)
>

I never worked with reactphp, so I have to claim ignorance here.
Looking into it right now. They claim non-blocking IO.

Does that mean you have to re-write your script to accommodate to 
reactphp to gain the performance boon?

Regard,
Erwin Moller

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

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

#15472 — Re: Performance of PHP vs. Node.js

Erwin Moller wrote:

> On 6/15/2015 8:42 PM, Christoph M. Becker wrote:
>> 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/>.
>>
>> :)
> 
> I never worked with reactphp, [...]

Me neither.  I just wanted to point out that there may be good
alternatives to Node.js with regard to performance.

-- 
Christoph M. Becker

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

#15467

> 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.

Is it practical to use a dedicated bid-server program rather than
a web server?  The bid-server is hard-coded (if necessary, in
hand-optimized assembly language) to process exactly *ONE* query
URL, (maybe with some variable inputs) and gives out a 500 error
for anything else.  (The rest of the site you put on a different
web server.)  The program accesses no static files; these are hard-coded
into the executable.  It's unclear whether this program needs a
database, or it can *BE* a database, keeping track of at least the
current high bids in shared memory.

Is it necessary for the bid-server to wait for the client to ask
for a response, or is it acceptable to just continue generating
responses one a second until the connection breaks?


I am reminded here of the little SMTP "server" I put up once that
accepted a connection, forked, read a line of input, output "550
Spam Not Welcome Here", and went back to read another line.  On
EOF, close the socket and the child exits.  It managed to throw
away hundreds of mail messages a second (on one SMTP connection -
some spammers have been caught sending over a million SPAMs in one
SMTP connection, all of them rejected).

This machine wasn't supposed to need mail at all, and we knew of
no MX records pointing at it, it attracted a lot of incoming mail
connections.  It was supposed to be a minimum-configuration machine
for testing applications to be sure they were acceptably fast.  It
turned out that some of the GUI-ish apps needed more memory to
outrun a snail.

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

#15473

On Sunday, June 14, 2015 at 12:09:07 AM UTC+5:30, Gordon Burditt wrote:
> > 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.
> 
> Is it practical to use a dedicated bid-server program rather than
> a web server?  The bid-server is hard-coded (if necessary, in
> hand-optimized assembly language) to process exactly *ONE* query
> URL, (maybe with some variable inputs) and gives out a 500 error
> for anything else.  (The rest of the site you put on a different
> web server.)  The program accesses no static files; these are hard-coded
> into the executable.  It's unclear whether this program needs a
> database, or it can *BE* a database, keeping track of at least the
> current high bids in shared memory.
> 
> Is it necessary for the bid-server to wait for the client to ask
> for a response, or is it acceptable to just continue generating
> responses one a second until the connection breaks?
> 
> 
> I am reminded here of the little SMTP "server" I put up once that
> accepted a connection, forked, read a line of input, output "550
> Spam Not Welcome Here", and went back to read another line.  On
> EOF, close the socket and the child exits.  It managed to throw
> away hundreds of mail messages a second (on one SMTP connection -
> some spammers have been caught sending over a million SPAMs in one
> SMTP connection, all of them rejected).
> 
> This machine wasn't supposed to need mail at all, and we knew of
> no MX records pointing at it, it attracted a lot of incoming mail
> connections.  It was supposed to be a minimum-configuration machine
> for testing applications to be sure they were acceptably fast.  It
> turned out that some of the GUI-ish apps needed more memory to
> outrun a snail.

Very good suggestion Gordon but I am struggling that how would I do such when I have to store value in the database and also retrieve them.

I am thinking that I would maintain a text file and store all values on them with fwrite and them at some point run a cron that will store them in the database.

another option I am thinking is json but all that encoding,decoding and parsing will affect the performance.    

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

#15474

On 6/19/2015 2:16 AM, apoorv.kanungo@gmail.com wrote:
> On Sunday, June 14, 2015 at 12:09:07 AM UTC+5:30, Gordon Burditt wrote:
>>> 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.
>>
>> Is it practical to use a dedicated bid-server program rather than
>> a web server?  The bid-server is hard-coded (if necessary, in
>> hand-optimized assembly language) to process exactly *ONE* query
>> URL, (maybe with some variable inputs) and gives out a 500 error
>> for anything else.  (The rest of the site you put on a different
>> web server.)  The program accesses no static files; these are hard-coded
>> into the executable.  It's unclear whether this program needs a
>> database, or it can *BE* a database, keeping track of at least the
>> current high bids in shared memory.
>>
>> Is it necessary for the bid-server to wait for the client to ask
>> for a response, or is it acceptable to just continue generating
>> responses one a second until the connection breaks?
>>
>>
>> I am reminded here of the little SMTP "server" I put up once that
>> accepted a connection, forked, read a line of input, output "550
>> Spam Not Welcome Here", and went back to read another line.  On
>> EOF, close the socket and the child exits.  It managed to throw
>> away hundreds of mail messages a second (on one SMTP connection -
>> some spammers have been caught sending over a million SPAMs in one
>> SMTP connection, all of them rejected).
>>
>> This machine wasn't supposed to need mail at all, and we knew of
>> no MX records pointing at it, it attracted a lot of incoming mail
>> connections.  It was supposed to be a minimum-configuration machine
>> for testing applications to be sure they were acceptably fast.  It
>> turned out that some of the GUI-ish apps needed more memory to
>> outrun a snail.
> 
> Very good suggestion Gordon but I am struggling that how would I do such when I have to store value in the database and also retrieve them.
> 
> I am thinking that I would maintain a text file and store all values on them with fwrite and them at some point run a cron that will store them in the database.
> 
> another option I am thinking is json but all that encoding,decoding and parsing will affect the performance.    
> 

Why take an extra step of storing the data in a file?  It's just more
complication and overhead.  It will take the same amount of time to
store the data in the database, no matter how you do it.

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

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

#15475

On Friday, June 19, 2015 at 5:46:15 PM UTC+5:30, Jerry Stuckle wrote:
> On 6/19/2015 2:16 AM, apoorv.kanungo@gmail.com wrote:
> > On Sunday, June 14, 2015 at 12:09:07 AM UTC+5:30, Gordon Burditt wrote:
> >>> 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.
> >>
> >> Is it practical to use a dedicated bid-server program rather than
> >> a web server?  The bid-server is hard-coded (if necessary, in
> >> hand-optimized assembly language) to process exactly *ONE* query
> >> URL, (maybe with some variable inputs) and gives out a 500 error
> >> for anything else.  (The rest of the site you put on a different
> >> web server.)  The program accesses no static files; these are hard-coded
> >> into the executable.  It's unclear whether this program needs a
> >> database, or it can *BE* a database, keeping track of at least the
> >> current high bids in shared memory.
> >>
> >> Is it necessary for the bid-server to wait for the client to ask
> >> for a response, or is it acceptable to just continue generating
> >> responses one a second until the connection breaks?
> >>
> >>
> >> I am reminded here of the little SMTP "server" I put up once that
> >> accepted a connection, forked, read a line of input, output "550
> >> Spam Not Welcome Here", and went back to read another line.  On
> >> EOF, close the socket and the child exits.  It managed to throw
> >> away hundreds of mail messages a second (on one SMTP connection -
> >> some spammers have been caught sending over a million SPAMs in one
> >> SMTP connection, all of them rejected).
> >>
> >> This machine wasn't supposed to need mail at all, and we knew of
> >> no MX records pointing at it, it attracted a lot of incoming mail
> >> connections.  It was supposed to be a minimum-configuration machine
> >> for testing applications to be sure they were acceptably fast.  It
> >> turned out that some of the GUI-ish apps needed more memory to
> >> outrun a snail.
> > 
> > Very good suggestion Gordon but I am struggling that how would I do such when I have to store value in the database and also retrieve them.
> > 
> > I am thinking that I would maintain a text file and store all values on them with fwrite and them at some point run a cron that will store them in the database.
> > 
> > another option I am thinking is json but all that encoding,decoding and parsing will affect the performance.    
> > 
> 
> Why take an extra step of storing the data in a file?  It's just more
> complication and overhead.  It will take the same amount of time to
> store the data in the database, no matter how you do it.
> 
> -- 
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

I am thinking about overhead and latency when I enter then in the database right away.

I think it would be easier if I first enter them in the text file and later I would store them in the database.
 

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

#15476

On Sun, 21 Jun 2015 23:06:30 -0700 (PDT), apoorv.kanungo@gmail.com
wrote:

> On Friday, June 19, 2015 at 5:46:15 PM UTC+5:30, Jerry Stuckle wrote:
>
>> Why take an extra step of storing the data in a file? It's just more
>> complication and overhead. It will take the same amount of time to
>> store the data in the database, no matter how you do it.
>>
> I am thinking about overhead and latency when I enter then in the
> database right away.
>
> I think it would be easier if I first enter them in the text file and
> later I would store them in the database.

Why would it be easier? It's obviously an extra step, it's obviously
more code and therefore more code to have errors in it. And your text
file may conceivably get out of sync with your database somehow, and
then you've got a big mess to clean up. Far better to let the database
database do the work, maintain the official clock, and enforce full
transactions. 

-- 
Remember, a 12'x12'x18" raised floor can hold over a thousand gallons of
blood before it starts to seep up through the cracks.
              -- Roger Burton West in the Monastery

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

#15479

On Sun, 21 Jun 2015 23:06:30 -0700, apoorv.kanungo wrote:

> I am thinking about overhead and latency when I enter then in the
> database right away.

> I think it would be easier if I first enter them in the text file and
> later I would store them in the database.

Have you done timing tests to compare open for append, write, close on a 
file vs open, insert, close a database connection?

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#15480

On 6/23/2015 2:39 AM, Denis McMahon wrote:
> On Sun, 21 Jun 2015 23:06:30 -0700, apoorv.kanungo wrote:
> 
>> I am thinking about overhead and latency when I enter then in the
>> database right away.
> 
>> I think it would be easier if I first enter them in the text file and
>> later I would store them in the database.
> 
> Have you done timing tests to compare open for append, write, close on a 
> file vs open, insert, close a database connection?
> 

Denis,

You forgot locking and unlocking the file, as well as the time required
to later process the file and update the database.

Plus what happens when the database process has the file locked and the
file write process wants to run?

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

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

#15477

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
> 
> […]
> 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)

No.  See below.

> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
> What happens?
> a) Client request a PHP page

No, that is precisely what in most cases does _not_ happen with XHR.
Which is why it is fast as compared to traditional approaches.

> 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.

Probably true.  Which is why you do not do low-latency work this way.

  ad a) You do not request an entire document, only the data;
        the HTTP connection is still open from before;
  ad b) the server does not need to launch the PHP process because that
        is still running from before: use PHP via FastCGI, not as Apache
        module;
  ad c) the database query result is cached by the database server,
        so that the need for subsequent queries is minimized;
  ad d) the query is optimized so as to run fast, by using indexes
        and so on.
  ad e) PHP delivers only the data to the Web server, or *as* Web
        *service*, which serves it to the Web client;
  ad f) Client-side scripting uses the data from the response
        to update only parts of the document.

> Try that with 1000 clients. ;-)

No problem.  Web server software can run multiple instances of itself and 
each instance can run multiple threads.  It is merely a matter of hardware 
performance.  BTST where I am working.

> There is so much overhead involved, and networking, you can't expect
> this to run every second.

True.  But see above.

> 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.

And the data written will be out of date, and there will be concurrency 
problems, while this is heavy on the hardware.  Do not do that unless you 
want to wreck your harddisk (or memory, if you use in-memory storage) in
the long-term.

> 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.

Even heavier on resources.  How many copies do you suggest should be lying 
around on the harddisk?  This is an Incredibly Bad Idea[tm].

Also, XML is not a good format for database dumps as it has much overhead.  
JSON or YAML leaner formats, in general better suited to the task.  But not 
in this case.

The idea behind this is a good one though if the database is not updated 
every second.  The idea is called caching.  You would not do that in the 
filesystem, though, at least not directly.  Server-side sessions come to 
mind.

> 2) Use nodeJS
> Indeed, no PHP. No AJAX.
> NodeJS is extremely fast and supports sockets.

So is and does PHP.  You are comparing apples and oranges.  PHP does not 
have to run via a Web server like Apache; you can write a Web service in 
PHP, much like a nodeJS application.

> If you are a bit familiar with ECMA Script (such as Javascript), try
> this route.

_ECMAScript_, _JavaScript_.  JavaScript is an implementation of ECMAScript; 
actually JavaScript *are* implementations of ECMAScript as there are several 
implementations (but not all of them) that contain “JavaScript” in their 
name.  At the time of writing, Netscape/Mozilla JavaScript, Google V8 
JavaScript (in Chromium and nodeJS, now in Opera too), and KDE JavaScript, 
to name a few.  But there is also Microsoft JScript and Opera ECMAScript (in 
older versions).

However, it is not so much a matter of the programming language but of the 
browser environment API (e.g. the DOM), although whatever ECMAScript 
implementation the HTML user agent supports is now [HTML5] the standard 
default client-side scripting language, and implicitly has been the quasi-
standard for years.

<http://PointedEars.de/es-matrix>
 
-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#15478

Thomas 'PointedEars' Lahn wrote:

> However, it is not so much a matter of the programming language but of the
> browser environment API (e.g. the DOM), although whatever ECMAScript
> implementation the HTML user agent supports is now [HTML5] the standard
> default client-side scripting language, and implicitly has been the quasi-
> standard for years.
> 
> <http://PointedEars.de/es-matrix>

You can strike out “browser” here because you can use an ECMAScript 
implementation, or something that compiles to one, server-side, too,
nodeJS *aside*.
 
-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#15482

On 6/22/2015 6:37 PM, Thomas 'PointedEars' Lahn wrote:
> Erwin Moller wrote:
>
>
>> 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.
>
> And the data written will be out of date, and there will be concurrency
> problems, while this is heavy on the hardware.  Do not do that unless you
> want to wreck your harddisk (or memory, if you use in-memory storage) in
> the long-term.

The data the client receives is *always* out of date, no matter what you 
do. Apparently 1 second of staleness is acceptable to the OP.

My suggestion by using 1 file is not a bad idea.
--> But it assumes that all the clients need the same information. <--

eg a file containing the latest bids, like:
"red bike": $34,45
"broken I-pad2": $5,00
"Pointed Ears How to Write Better Code": $450,50
etc

It wasn't clear in the original post if each client receives the same 
data, so I gave it as a (very fast) option to consider.
Very fast compared to requerying the database for each request.

>
>> 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.
>
> Even heavier on resources.  How many copies do you suggest should be lying
> around on the harddisk?

1 copy.
Do you actually understand what situation I described?

> This is an Incredibly Bad Idea[tm].

You are entitled to your own opinion.
(But please don't present it like a fact, that confuses people who read 
this discussion and can read better than you did.)


>
> Also, XML is not a good format for database dumps as it has much overhead.
> JSON or YAML leaner formats, in general better suited to the task.  But not
> in this case.

You have that right.

>
> The idea behind this is a good one though if the database is not updated
> every second.  The idea is called caching.  You would not do that in the
> filesystem, though, at least not directly.  Server-side sessions come to
> mind.

Many roads lead to Rome.
My example used a file, because that is extremely easy to understand.


>
>> 2) Use nodeJS
>> Indeed, no PHP. No AJAX.
>> NodeJS is extremely fast and supports sockets.
>
> So is and does PHP.  You are comparing apples and oranges.  PHP does not
> have to run via a Web server like Apache; you can write a Web service in
> PHP, much like a nodeJS application.

I must claim ignorance here, since I only run PHP inside a full fledged 
webserver.


>
>> If you are a bit familiar with ECMA Script (such as Javascript), try
>> this route.
>
> _ECMAScript_, _JavaScript_.  JavaScript is an implementation of ECMAScript;
> actually JavaScript *are* implementations of ECMAScript as there are several
> implementations (but not all of them) that contain “JavaScript” in their
> name.  At the time of writing, Netscape/Mozilla JavaScript, Google V8
> JavaScript (in Chromium and nodeJS, now in Opera too), and KDE JavaScript,
> to name a few.  But there is also Microsoft JScript and Opera ECMAScript (in
> older versions).

Free advise: You might consider putting that in your sig.
That way you don't have to type it in every other post.
(Or give up your one-man crusade against 
Idiots-Who-Refuse-To-Understand-The-Difference-Between-Javascript-JavaScript-JScript-ECMAScript, 
like me.)


>
> However, it is not so much a matter of the programming language but of the
> browser environment API (e.g. the DOM), although whatever ECMAScript
> implementation the HTML user agent supports is now [HTML5] the standard
> default client-side scripting language, and implicitly has been the quasi-
> standard for years.

Correct.

>
> <http://PointedEars.de/es-matrix>
>
>


Erwin Moller


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

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

#15489

Erwin Moller wrote:

> The data the client receives is *always* out of date, no matter what you
> do.

Wrong.

> […]
> My suggestion by using 1 file is not a bad idea.

Yes, it is.  There are also limits as to how many processes can concurrently 
*read* from a single file.

> --> But it assumes that all the clients need the same information. <--

It also assumes unlimited resources.

> […]
> It wasn't clear in the original post if each client receives the same
> data, so I gave it as a (very fast) option to consider.
> Very fast compared to requerying the database for each request.

Probably slower and more limited than server-side sessions in any case.

>>> 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.
>> Even heavier on resources.  How many copies do you suggest should be
>> lying around on the harddisk?
> 
> 1 copy.
> Do you actually understand what situation I described?

It was not at all clear what you meant.

>> This is an Incredibly Bad Idea[tm].
> 
> You are entitled to your own opinion.
> (But please don't present it like a fact, that confuses people who read
> this discussion and can read better than you did.)

You mean “*guess* better”.  Only *now* *you* have introduced the condition 
that all clients get the same data.

>> […]  You would not do [caching] in the filesystem, though, at least not
>> directly.  Server-side sessions come to mind.
> 
> Many roads lead to Rome.
> My example used a file, because that is extremely easy to understand.

Bad examples are worse than no examples at all.  Especially if the caveats 
are not pointed out.

>>> If you are a bit familiar with ECMA Script (such as Javascript), try
>>> this route.
>> _ECMAScript_, _JavaScript_.  JavaScript is an implementation of
>> ECMAScript; actually JavaScript *are* implementations of ECMAScript as
>> there are several implementations (but not all of them) that contain
>> “JavaScript” in their name.  […]
> 
> Free advise: You might consider putting that in your sig.
           ^c

Too long; a sig should not exceed 4 lines à 80 characters.  Also, I would 
have to remove “Zend Certified PHP Engineer” from it, thereby an important 
hint that I am also qualified to make such statements as I did elsewhere in 
my posting.

> That way you don't have to type it in every other post.
> (Or give up your one-man crusade against
> Idiots-Who-Refuse-To-Understand-The-Difference-Between-Javascript-
> JavaScript-JScript-ECMAScript, like me.)

You are arguing like an idiot, indeed.

At this point, let me remind you of <http://thecodelesscode.com/case/195> 
which Hans-Georg Michna kindly posted in <news:comp.lang.javascript>, and 
whose point you did not seem to get back then.

HTH

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#15490

On 6/23/2015 6:06 PM, Thomas 'Pointed Head' Lahn wrote:
> Erwin Moller wrote:
> 
>> The data the client receives is *always* out of date, no matter what you
>> do.
> 
> Wrong.
>

And why not?  Stoopid Pointed Head response - says something is wrong
but too stoopid to explain why.

>> […]
>> My suggestion by using 1 file is not a bad idea.
> 
> Yes, it is.  There are also limits as to how many processes can concurrently 
> *read* from a single file.
> 

And how many is that, Pointed Head?  Too many for a web server to handle?

>> --> But it assumes that all the clients need the same information. <--
> 
> It also assumes unlimited resources.
> 

And why should it require unlimited resources?

>> […]
>> It wasn't clear in the original post if each client receives the same
>> data, so I gave it as a (very fast) option to consider.
>> Very fast compared to requerying the database for each request.
> 
> Probably slower and more limited than server-side sessions in any case.
> 

Maybe, maybe not.  It depends on a lot of factors which have not been
defined.

>>>> 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.
>>> Even heavier on resources.  How many copies do you suggest should be
>>> lying around on the harddisk?
>>
>> 1 copy.
>> Do you actually understand what situation I described?
> 
> It was not at all clear what you meant.
>

It was to me - and I would guess any *knowledgeable* person in this
newsgroup.

>>> This is an Incredibly Bad Idea[tm].
>>
>> You are entitled to your own opinion.
>> (But please don't present it like a fact, that confuses people who read
>> this discussion and can read better than you did.)
> 
> You mean “*guess* better”.  Only *now* *you* have introduced the condition 
> that all clients get the same data.
> 

I would say more of an "informed opinion" (which you don't have) rather
than a "guess". One I happen to agree with.

>>> […]  You would not do [caching] in the filesystem, though, at least not
>>> directly.  Server-side sessions come to mind.
>>
>> Many roads lead to Rome.
>> My example used a file, because that is extremely easy to understand.
> 
> Bad examples are worse than no examples at all.  Especially if the caveats 
> are not pointed out.
> 

So why do you keep expounding on bad examples?

>>>> If you are a bit familiar with ECMA Script (such as Javascript), try
>>>> this route.
>>> _ECMAScript_, _JavaScript_.  JavaScript is an implementation of
>>> ECMAScript; actually JavaScript *are* implementations of ECMAScript as
>>> there are several implementations (but not all of them) that contain
>>> “JavaScript” in their name.  […]
>>
>> Free advise: You might consider putting that in your sig.
>            ^c
> 
> Too long; a sig should not exceed 4 lines à 80 characters.  Also, I would 
> have to remove “Zend Certified PHP Engineer” from it, thereby an important 
> hint that I am also qualified to make such statements as I did elsewhere in 
> my posting.
> 

More nonsense from the pedantic troll.  This is not your personal newsgroup.

>> That way you don't have to type it in every other post.
>> (Or give up your one-man crusade against
>> Idiots-Who-Refuse-To-Understand-The-Difference-Between-Javascript-
>> JavaScript-JScript-ECMAScript, like me.)
> 
> You are arguing like an idiot, indeed.
> 

Pot - Kettle - Black.

> At this point, let me remind you of <http://thecodelesscode.com/case/195> 
> which Hans-Georg Michna kindly posted in <news:comp.lang.javascript>, and 
> whose point you did not seem to get back then.
> 
> HTH
> 

Which has absolutely nothing to do with this discussion - other than
something a troll would bring up.  But then it's what I would expect of you.

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

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

#15491

Jerry Stuckle wrote:

> On 6/23/2015 6:06 PM, Thomas 'Pointed Head' Lahn wrote:
>> Erwin Moller wrote:
>>> The data the client receives is *always* out of date, no matter what you
>>> do.
>> Wrong.
> 
> And why not?

You mean “why (is it wrong)?”?  Because there is the possibility that the 
data in the database has not changed when the response is received by the 
client.  (That was an easy one.)

>>> […]
>>> My suggestion by using 1 file is not a bad idea.
>> Yes, it is.  There are also limits as to how many processes can
>> concurrently *read* from a single file.
> 
> And how many is that, […]?

Depends.

> Too many for a web server to handle?

Impossible to say for sure.  But better be safe than sorry.

>>> --> But it assumes that all the clients need the same information. <--
>> It also assumes unlimited resources.
> 
> And why should it require unlimited resources?

Because, among others, the limit above has not been considered.

>>> […]
>>> It wasn't clear in the original post if each client receives the same
>>> data, so I gave it as a (very fast) option to consider.
>>> Very fast compared to requerying the database for each request.
>> Probably slower and more limited than server-side sessions in any case.
> 
> Maybe, maybe not.

In which cases would server-side sessions be slower or only equally fast, 
and more or only equally limited, than either of requerying the database or 
direct file system access?

> It depends on a lot of factors which have not been defined.

I do not think so.
 
>>>> […]  You would not do [caching] in the filesystem, though, at least not
>>>> directly.  Server-side sessions come to mind.
>>> Many roads lead to Rome.
>>> My example used a file, because that is extremely easy to understand.
>> Bad examples are worse than no examples at all.  Especially if the
>> caveats are not pointed out.
> 
> So why do you keep expounding on bad examples?

I am pointing out that it is a bad example, and I am explaining why.  If I 
would not point it out and explain it, and nobody else would point it out 
and explain it, the bad example could be taken as a good one.  You would not 
want that to happen, would you?
 
>> Too long; a sig should not exceed 4 lines à 80 characters.  Also, I would
>> have to remove “Zend Certified PHP Engineer” from it, thereby an
>> important hint that I am also qualified to make such statements as I did
>> elsewhere in my posting.
> 
> More nonsense from the pedantic troll.  This is not your personal
> newsgroup.

As for Usenet signature recommendations, see

<https://en.wikipedia.org/wiki/Signature_block#Signatures_in_Usenet_postings>

and

<http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>.

As for being a ZCE: We talk about that again that if and when you, too, have 
become one of the only about 11'000 people world-wide in the ZCE Directory.  
Based on the candidate IDs, I have calculated a success rate for all ZCE 
exams of about 45 %; so there is a chance that you can pass, too.

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#15492

On 6/23/2015 7:45 PM, Thomas 'Pointed Head' Lahn wrote:
> Jerry Stuckle wrote:
> 
>> On 6/23/2015 6:06 PM, Thomas 'Pointed Head' Lahn wrote:
>>> Erwin Moller wrote:
>>>> The data the client receives is *always* out of date, no matter what you
>>>> do.
>>> Wrong.
>>
>> And why not?
> 
> You mean “why (is it wrong)?”?  Because there is the possibility that the 
> data in the database has not changed when the response is received by the 
> client.  (That was an easy one.)
>

In what way?  Erwin's comment was "The data the client receives is
*always* out of date, no matter what you do."  Explain your comment *in
that context*.

>>>> […]
>>>> My suggestion by using 1 file is not a bad idea.
>>> Yes, it is.  There are also limits as to how many processes can
>>> concurrently *read* from a single file.
>>
>> And how many is that, […]?
> 
> Depends.
>  

Typical "I don't know - but I'm going to make a fool of myself and
criticize his idea anyway" comment.

If you can't define the limit, then you have no basis for your comment.

>> Too many for a web server to handle?
> 
> Impossible to say for sure.  But better be safe than sorry.
> 

See above.

>>>> --> But it assumes that all the clients need the same information. <--
>>> It also assumes unlimited resources.
>>
>> And why should it require unlimited resources?
> 
> Because, among others, the limit above has not been considered.
> 

See above.

>>>> […]
>>>> It wasn't clear in the original post if each client receives the same
>>>> data, so I gave it as a (very fast) option to consider.
>>>> Very fast compared to requerying the database for each request.
>>> Probably slower and more limited than server-side sessions in any case.
>>
>> Maybe, maybe not.
> 
> In which cases would server-side sessions be slower or only equally fast, 
> and more or only equally limited, than either of requerying the database or 
> direct file system access?
> 

Maybe, maybe not.  You made the comparison.  Based on what?

>> It depends on a lot of factors which have not been defined.
> 
> I do not think so.
>

More properly, your period should have come after "think".

>>>>> […]  You would not do [caching] in the filesystem, though, at least not
>>>>> directly.  Server-side sessions come to mind.
>>>> Many roads lead to Rome.
>>>> My example used a file, because that is extremely easy to understand.
>>> Bad examples are worse than no examples at all.  Especially if the
>>> caveats are not pointed out.
>>
>> So why do you keep expounding on bad examples?
> 
> I am pointing out that it is a bad example, and I am explaining why.  If I 
> would not point it out and explain it, and nobody else would point it out 
> and explain it, the bad example could be taken as a good one.  You would not 
> want that to happen, would you?
>  

No, you are not explaining why *anything* is a bad example.  Only
claiming that bad examples are worse than none at all.  Exactly what is
bad about it?

>>> Too long; a sig should not exceed 4 lines à 80 characters.  Also, I would
>>> have to remove “Zend Certified PHP Engineer” from it, thereby an
>>> important hint that I am also qualified to make such statements as I did
>>> elsewhere in my posting.
>>
>> More nonsense from the pedantic troll.  This is not your personal
>> newsgroup.
> 
> As for Usenet signature recommendations, see
> 
> <https://en.wikipedia.org/wiki/Signature_block#Signatures_in_Usenet_postings>
> 
> and
> 
> <http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>.
> 

And you're the only one on this newsgroup who gives a damn about it.
But then you're the only pedantic troll who thinks they own the group,
and everyone should follow your "rules"/

> As for being a ZCE: We talk about that again that if and when you, too, have 
> become one of the only about 11'000 people world-wide in the ZCE Directory.  
> Based on the candidate IDs, I have calculated a success rate for all ZCE 
> exams of about 45 %; so there is a chance that you can pass, too.
> 

Who cares?  All the certification proves is that you can pass the exam.
 Your posts here prove that passing an exam is no proof of being able to
do the work.

But then those who can't do the work depend on the exams and
certifications to prove their competence.  Those of us who are competent
do not need such artificial props.  We get plenty of work without them.

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

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

#15494

On Wednesday, June 24, 2015 at 5:51:50 AM UTC+5:30, Jerry Stuckle wrote:
> On 6/23/2015 7:45 PM, Thomas 'Pointed Head' Lahn wrote:
> > Jerry Stuckle wrote:
> > 
> >> On 6/23/2015 6:06 PM, Thomas 'Pointed Head' Lahn wrote:
> >>> Erwin Moller wrote:
> >>>> The data the client receives is *always* out of date, no matter what you
> >>>> do.
> >>> Wrong.
> >>
> >> And why not?
> > 
> > You mean "why (is it wrong)?"?  Because there is the possibility that the 
> > data in the database has not changed when the response is received by the 
> > client.  (That was an easy one.)
> >
> 
> In what way?  Erwin's comment was "The data the client receives is
> *always* out of date, no matter what you do."  Explain your comment *in
> that context*.
> 
> >>>> [...]
> >>>> My suggestion by using 1 file is not a bad idea.
> >>> Yes, it is.  There are also limits as to how many processes can
> >>> concurrently *read* from a single file.
> >>
> >> And how many is that, [...]?
> > 
> > Depends.
> >  
> 
> Typical "I don't know - but I'm going to make a fool of myself and
> criticize his idea anyway" comment.
> 
> If you can't define the limit, then you have no basis for your comment.
> 
> >> Too many for a web server to handle?
> > 
> > Impossible to say for sure.  But better be safe than sorry.
> > 
> 
> See above.
> 
> >>>> --> But it assumes that all the clients need the same information. <--
> >>> It also assumes unlimited resources.
> >>
> >> And why should it require unlimited resources?
> > 
> > Because, among others, the limit above has not been considered.
> > 
> 
> See above.
> 
> >>>> [...]
> >>>> It wasn't clear in the original post if each client receives the same
> >>>> data, so I gave it as a (very fast) option to consider.
> >>>> Very fast compared to requerying the database for each request.
> >>> Probably slower and more limited than server-side sessions in any case.
> >>
> >> Maybe, maybe not.
> > 
> > In which cases would server-side sessions be slower or only equally fast, 
> > and more or only equally limited, than either of requerying the database or 
> > direct file system access?
> > 
> 
> Maybe, maybe not.  You made the comparison.  Based on what?
> 
> >> It depends on a lot of factors which have not been defined.
> > 
> > I do not think so.
> >
> 
> More properly, your period should have come after "think".
> 
> >>>>> [...]  You would not do [caching] in the filesystem, though, at least not
> >>>>> directly.  Server-side sessions come to mind.
> >>>> Many roads lead to Rome.
> >>>> My example used a file, because that is extremely easy to understand.
> >>> Bad examples are worse than no examples at all.  Especially if the
> >>> caveats are not pointed out.
> >>
> >> So why do you keep expounding on bad examples?
> > 
> > I am pointing out that it is a bad example, and I am explaining why.  If I 
> > would not point it out and explain it, and nobody else would point it out 
> > and explain it, the bad example could be taken as a good one.  You would not 
> > want that to happen, would you?
> >  
> 
> No, you are not explaining why *anything* is a bad example.  Only
> claiming that bad examples are worse than none at all.  Exactly what is
> bad about it?
> 
> >>> Too long; a sig should not exceed 4 lines à 80 characters.  Also, I would
> >>> have to remove "Zend Certified PHP Engineer" from it, thereby an
> >>> important hint that I am also qualified to make such statements as I did
> >>> elsewhere in my posting.
> >>
> >> More nonsense from the pedantic troll.  This is not your personal
> >> newsgroup.
> > 
> > As for Usenet signature recommendations, see
> > 
> > <https://en.wikipedia.org/wiki/Signature_block#Signatures_in_Usenet_postings>
> > 
> > and
> > 
> > <http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>.
> > 
> 
> And you're the only one on this newsgroup who gives a damn about it.
> But then you're the only pedantic troll who thinks they own the group,
> and everyone should follow your "rules"/
> 
> > As for being a ZCE: We talk about that again that if and when you, too, have 
> > become one of the only about 11'000 people world-wide in the ZCE Directory.  
> > Based on the candidate IDs, I have calculated a success rate for all ZCE 
> > exams of about 45 %; so there is a chance that you can pass, too.
> > 
> 
> Who cares?  All the certification proves is that you can pass the exam.
>  Your posts here prove that passing an exam is no proof of being able to
> do the work.
> 
> But then those who can't do the work depend on the exams and
> certifications to prove their competence.  Those of us who are competent
> do not need such artificial props.  We get plenty of work without them.
> 
> -- 
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

Guys let's not fight I am sure all you guys are excellent developer and are generous to share your knowledge with rest of the world.

About My question I managed to get a prototype working using a json file right now I am testing with 10 user and I am facing some delay.

There are two parameters no of bids left and the timer no of bids is working fine but I am struggling with the timer.

About the delay I am fine with one second delay but to the user it should look like real time. 

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

#15497

On 6/24/2015 2:34 AM, apoorv.kanungo@gmail.com wrote:
> About the delay I am fine with one second delay but to the user it should look like real time.

users are used to inexplicable delays in browser refreshing.  If 
this is used over the internet there will always be latency.  If 
you are running it over a LAN then you can strive for near-real-time.

bill

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

#15527

Jerry Stuckle:

> On 6/23/2015 7:45 PM, Thomas 'Pointed Head' Lahn wrote:
[...]
>> As for Usenet signature recommendations, see
>>
>> <https://en.wikipedia.org/wiki/Signature_block#Signatures_in_Usenet_postings>
>>
>> and
>>
>> <http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>.
>>
> 
> And you're the only one on this newsgroup who gives a damn about it.

Nope - I do too. That's the reason why I limit my signature to four
lines. Many other posts here also just have 4 lines or less in their
signature. These extra "==================" in your signature are just
needless.

But this fits the invalid sender address and the need for explanations
how one can reply to your real address <jstuckle@attglobal.net>.

> But then you're the only pedantic troll who thinks they own the group,
> and everyone should follow your "rules"/

JFTR:
<http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>
is a text by the University of Manchester. If you want to blame someone
for these "rules", then go there.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#15530

On 6/25/2015 11:18 AM, Arno Welzel wrote:
> Jerry Stuckle:
> 
>> On 6/23/2015 7:45 PM, Thomas 'Pointed Head' Lahn wrote:
> [...]
>>> As for Usenet signature recommendations, see
>>>
>>> <https://en.wikipedia.org/wiki/Signature_block#Signatures_in_Usenet_postings>
>>>
>>> and
>>>
>>> <http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>.
>>>
>>
>> And you're the only one on this newsgroup who gives a damn about it.
> 
> Nope - I do too. That's the reason why I limit my signature to four
> lines. Many other posts here also just have 4 lines or less in their
> signature. These extra "==================" in your signature are just
> needless.
>
> But this fits the invalid sender address and the need for explanations
> how one can reply to your real address <jstuckle@attglobal.net>.
>

Ah, another troll speaks up.  Proven because he purposely tries to get
my email address spammed.

Sorry, sucker - it is not required you have a valid email address - only
one which can be easily decoded.

>> But then you're the only pedantic troll who thinks they own the group,
>> and everyone should follow your "rules"/
> 
> JFTR:
> <http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>
> is a text by the University of Manchester. If you want to blame someone
> for these "rules", then go there.
> 
> 

Yup, just another troll - and another pedantic one, also.

Now go tell your mommy to wash your mouth out with soap.



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

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web