From: Teus Benschop on
When looking at PHP as used in enterprise class applications, we can see
the following happening. Let imagine that we have a site that gets a
1000 requests per second. That seems to be a good candidate for
threading so as to be able to handle the 1000 requests per second. The
site runs PHP and Apache. Well, what happens? Each request coming in is
handed of to a separate instance of Apache. Thus the site would be able
to process many requests simultaneously. It looks as if parallel
computing is taking place here, which looks much like threading. Even
though PHP itself does not know about threads, and does not need to, I
think, the whole process of handling the 1000 requests per second uses
parallel computing. There are no performance bottle-necks here. Teus.
From: Teus Benschop on
On Tue, 2010-03-23 at 19:08 -0700, Tommy Pham wrote:
> The response time, max 5 seconds, will be tested on local gigabit LAN
> to ensure the adequate response (optimized DB & code & proper
> hardware) without worrying about users' connection limit and site's
> upload bandwidth limit (which can easily rectify). Then thereafter
> will be doing stress test of about 10 concurrent users. As for the
> major queries, that's where threads come in, IMO, because those
> queries depend on 1 primary parameter (category ID) and 1 secondary
> parameter (language ID). This particular site starts with 500
> products about 15 categories, without many of those mentioned filters,
> later grew to its current state.
>
The bottle neck looking at speed in this example seems to be the
database backend, not PHP. What would be needed is a fast database, and
SQL queries optimized for speed. Teus.

From: Phpster on
Most if that stuff should only be in the db as a reference and when
editing te lists. The actual user acessed data should sit in simple
XML files that can be passed to the client, broken out by category or
prod line. The reasons are simple, database access time is going to
suck, no matter what you are running. And why would you ever need to
run translation real time. I can tell you from persoanl experience
that such solution totally blows. I lost that battle at work and the
current solution build every field on the fly each time with
translation ( supporting 12 languages) and it's damn slow. Cache out
whatever you can, to an in memory cache or to the file system. Let the
web server do it's job of serving files, not processing upteen little
bits of data from a db.

It's about design, from all I've seen, threading introduces about as
many challenges as problems it solves.

Bastien

Sent from my iPod

On Mar 23, 2010, at 9:17 PM, Tommy Pham <tommyhp2(a)gmail.com> wrote:

> Let's go back to my 1st e-commerce example. The manufacturers list is
> about 3,700. The categories is about about 2,400. The products list
> is right now at 500,000 and expected to be around 750,000. The site
> is only in English. The store owner wants to expand and be I18n:
> Chinese, French, German, Korean, Spanish. You see how big and complex
> that database gets? The store owners want to have this happens when a
> customer clicks on a category:
>
> * show all subcategories for that category, if any
> * show all products for that category, if any,
> * show all manufacturers, used as filtering, for that category and
> subcategories
> * show price range filter for that category
> * show features & specifications filter for that category
> * show 10 top sellers for that category and related subcategories
> * the shopper can then select/deselect any of those filters and
> ability to sort by manufacturers, prices, user rating, popularity
> (purchased quantity)
> * have the ability to switch to another language translation on the
> fly
> * from the moment the shopper click on a link, the response time (when
> web browser saids "Done" in the status bar) is 5 seconds or less.
> Preferably 2-3 seconds. Will be using stopwatch for the timer.
>
> Now show me a website that meets those requirements and uses PHP, I'll
> be glad to support your argument about PHP w/o threads :) BTW, this
> is not even enterprise requirement. I may have another possible
> project where # products is over 10 million easily. With similar
> requirements when the user click on category. Do you think this site,
> which currently isn't, can run on PHP?
>
> Regards,
> Tommy
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
From: Tommy Pham on
On Tue, Mar 23, 2010 at 9:06 PM, Teus Benschop <teusjannette(a)gmail.com> wrote:
> When looking at PHP as used in enterprise class applications, we can see
> the following happening. Let imagine that we have a site that gets a
> 1000 requests per second. That seems to be a good candidate for
> threading so as to be able to handle the 1000 requests per second. The
> site runs PHP and Apache. Well, what happens? Each request coming in is
> handed of to a separate instance of Apache. Thus the site would be able
> to process many requests simultaneously. It looks as if parallel
> computing is taking place here, which looks much like threading. Even
> though PHP itself does not know about threads, and does not need to, I
> think, the whole process of handling the 1000 requests per second uses
> parallel computing. There are no performance bottle-necks here. Teus.
>

# of requests / second can be solved by load balancers/clusters. What
about the multiple answers for a simple request per user as in my
example? How you would solve that if not by threading? Amazon has
about 30 million products and they have filters similar to what I
mentioned. But when clicking on one of the I18n site at the bottom,
you're taken to another server, which looks like it uses a different
DB back end (I could be wrong) and you don't get instant translation
of the category you're looking at. Their response time is about 3
seconds on my 10mbs (not cable) download. As for what programming
language they use...
From: Larry Garfield on
On Tuesday 23 March 2010 11:32:10 pm Tommy Pham wrote:
> On Tue, Mar 23, 2010 at 9:06 PM, Teus Benschop <teusjannette(a)gmail.com>
wrote:
> > When looking at PHP as used in enterprise class applications, we can see
> > the following happening. Let imagine that we have a site that gets a
> > 1000 requests per second. That seems to be a good candidate for
> > threading so as to be able to handle the 1000 requests per second. The
> > site runs PHP and Apache. Well, what happens? Each request coming in is
> > handed of to a separate instance of Apache. Thus the site would be able
> > to process many requests simultaneously. It looks as if parallel
> > computing is taking place here, which looks much like threading. Even
> > though PHP itself does not know about threads, and does not need to, I
> > think, the whole process of handling the 1000 requests per second uses
> > parallel computing. There are no performance bottle-necks here. Teus.
>
> # of requests / second can be solved by load balancers/clusters. What
> about the multiple answers for a simple request per user as in my
> example? How you would solve that if not by threading? Amazon has
> about 30 million products and they have filters similar to what I
> mentioned. But when clicking on one of the I18n site at the bottom,
> you're taken to another server, which looks like it uses a different
> DB back end (I could be wrong) and you don't get instant translation
> of the category you're looking at. Their response time is about 3
> seconds on my 10mbs (not cable) download. As for what programming
> language they use...

Honestly, how WOULD you solve that with threading? You describe a page that
needs to be generated that has a half-dozen queries against the database
ranging from simple to moderately complex, some of which are site-generic and
some are user-specific.

How does one solve that with threading?

1) Run the site-generic queries once and cache them in memory and let other
threads just use that query result. You can do that without threads. Just
render that part of the page and cache that string to disk, to the database,
or to memcache. If the memecache server is on the same box then it should be
identical to the threading version, performance-wise. (Give or take VM
considerations.)

2) Push the user-specific DB queries to separate threads so they can run in
parallel. All that does is push the hard work off onto the DB server, which is
still running the same number of queries. And PHP can't respond until all of
the queries finish anyway, and the DB server will respond no faster, so you're
really gaining nothing.

You keep saying "how would you solve this without threads?" as if they're some
magical speed fairy dust. Given the scenario you describe, I don't even see
how threads would buy you anything at all.

Where threads would be useful is for lots of very small writes on rapidly
changing data. I would never want to write, say, the World of Warcraft
servers without threading and a persistent runtime, but then I wouldn't want
to write them in PHP to begin with.

Insert that old saying about hammers and nails here.

--Larry Garfield