Re: Will PHP ever "grow up" and have threading?
| From: | Rene Veerman | Date: | Wed, 24 Mar 2010 20:44:37 +0000 |
| Subject: | Re: Will PHP ever "grow up" and have threading? | ||
| References: | 1 2 3 4 5 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-303377@lists.php.net to get a copy of this message | ||
Rene:
>and btw, use of sql where other solutions (like shared mem and threading!) is exactly what
>i'm against.
should read "where other solutions (...) are very likely to work
better / more efficiently"..
On Wed, Mar 24, 2010 at 10:42 PM, Rene Veerman <rene7705@gmail.com> wrote:
> On Wed, Mar 24, 2010 at 10:34 PM, Sancar Saran <sancar.saran@evodot.com> wrote:
>> On Wednesday 24 March 2010 21:42:53 Tommy Pham wrote:
>>> On Wed, Mar 24, 2010 at 10:18 AM, Sancar Saran <sancar.saran@evodot.com>
>> wrote:
>>> > On Wednesday 24 March 2010 03:17:56 Tommy Pham 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
>>> >
>>> > If you design and code correctly. Yes.
>>> >
>>> >
>>> > If you want to use someting alredy. Try TYPO3.
>>> >
>>> > PS: Your arguments are something about implementation not something about
>>> > platform abilities. You can do this things any server side programming
>>> > with enough hardware.
>>> >
>>> > Regards
>>> >
>>> > Sancar
>>>
>>> Platform abilities = PHP with/without threads.
>>> Implementation = If PHP has threads, how do I implement it. If not,
>>> what work around / hacks do I need to do.
>>
>>
>> Please forgive my low ability on English and you sound like.
>>
>> "I can drive a car, if it has a diesel engine and we want Ferrari for our
>> need. Is there any way to fit a diesel engine in Ferrari ?"
>>
>> Your problem isn't php, You problem is your way to think...
>>
>> You are trying to bend php to fit your way of the building web sites.
>>
>> I'm sorry, things does not work like that.
>>
>> You are trying to represent your business logic as "ENTERPRISE SOFTWARE
>> STANDARTS".
>>
>> I'm sorry, it wont !
>>
>> Even with provocative subject, it still business logic at large.
>>
>> On Large Web sites, Site has own standards which enterprise must have to
>> obey.. (like Facebook or any other uber number cruncher you name it)
>>
>> Anyway...
>>
>> You want to build a damn huge web site with damn huge data set and damn huge
>> requests per second.
>>
>> and you still want to use that SQL for primary data store for reading..
>>
>> ARE YOU NUTS ???
>>
>> With this kind of approach,
>>
>> You will be in deep trouble with any language, with any Reational SQL Server.
>>
>> If your customers need that kind of thing. You need lots of sophisticated
>> people which know how to handle big things under web enviroment.
>>
>> Good luck to you.
>>
>> Regards
>>
>
> how dramatic.
> how elitist.
>
> and btw, use of sql where other solutions (like shared mem and
> threading!) is exactly what i'm against.
>
> if you ppl just stop barracading, you'll see that with relatively
> minimal effort php can evolve with the times and make such things
> possible for us mere mortals.
>