Re: high traffic websites

On Sep 18, 2013, at 14:26, Haluk Karamete <halukkaramete@gmail.com> wrote: >> I recommend OPCache, which is already included in PHP 5.5. > > Camilo, > I'm just curious about the disadvantageous aspects of OPcache. > > My logic says there must be some issues with it otherwise it would have come already enabled. > > > Sent from iPhone > > > On Sep 18, 2013, at 2:20 AM, Camilo Sperberg <unreal4u@gmail.com> wrote: > >> >> On Sep 18, 2013, at 09:38, Negin Nickparsa <nickparsa@gmail.com> wrote: >> >>> Thank you Sebastian..actually I will already have one if qualified for the >>> job. Yes, and I may fail to handle it that's why I asked for guidance. >>> I wanted some tidbits to start over. I have searched through yslow, >>> HTTtrack and others. >>> I have searched through php list in my email too before asking this >>> question. it is kind of beneficial for all people and not has been asked >>> directly. >>> >>> >>> Sincerely >>> Negin Nickparsa >>> >>> >>> On Wed, Sep 18, 2013 at 10:45 AM, Sebastian Krebs <krebs.seb@gmail.com>wrote: >>> >>>> >>>> >>>> >>>> 2013/9/18 Negin Nickparsa <nickparsa@gmail.com> >>>> >>>>> In general, what are the best ways to handle high traffic websites? >>>>> >>>>> VPS(clouds)? >>>>> web analyzers? >>>>> dedicated servers? >>>>> distributed memory cache? >>>>> >>>> >>>> Yes :) >>>> >>>> But seriously: That is a topic most of us spent much time to get into it. >>>> You can explain it with a bunch of buzzwords. Additional, how do you define >>>> "high traffic websites"? Do you already _have_ such a site? Or do you >>>> _want_ it? It's important, because I've seen it far too often, that >>>> projects spent too much effort in their "high traffic infrastructure" and >>>> at the end it wasn't that high traffic ;) I wont say, that you cannot be >>>> successfull, but you should start with an effort you can handle. >>>> >>>> Regards, >>>> Sebastian >>>> >>>> >>>>> >>>>> >>>>> Sincerely >>>>> Negin Nickparsa >>>>> >>>> >>>> >>>> >>>> -- >>>> github.com/KingCrunch >>>> >> >> Your question is way too vague to be answered properly... My best guess would be that it >> depends severely on the type of website you have and how's the current implementation being >> well... implemented. >> >> Simply said: what works for Facebook may/will not work for linkedIn, twitter or Google, >> mainly because the type of search differs A LOT: facebook is about relations between people, twitter >> is about small pieces of data not mainly interconnected between each other, while Google is all >> about links and all type of content: from little pieces of information through whole Wikipedia. >> >> You could start by studying how varnish and redis/memcached works, you could study about >> how proxies work (nginx et al), CDNs and that kind of stuff, but if you want more specific answers, >> you could better ask specific question. >> >> In the PHP area, an opcode cache does the job very well and can accelerate the page load by >> several orders of magnitude, I recommend OPCache, which is already included in PHP 5.5. >> >> Greetings. >> >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> The original RFC states: https://wiki.php.net/rfc/optimizerplus The integration proposed for PHP 5.5.0 is mostly 'soft' integration. That means that there'll be no tight coupling between Optimizer+ and PHP; Those who wish to use another opcode cache will be able to do so, by not loading Optimizer+ and loading another opcode cache instead. As per the Suggested Roadmap above, we might want to review this decision in the future; There might be room for further performance or functionality gains from tighter integration; None are known at this point, and they're beyond the scope of this RFC. So that's why OPCache isn't enabled by default in PHP 5.5 Greetings.