Въпрос за мощности
- Автор gLaVoReZa
- Начална дата
kriss каза:\\offtopic ти ако имаш сайт с 20 000 000 посещения на ден няма да те е грижа много много колко ще ти стрував българя засега такива сайтове няма...\\
Ще те е грижа колко струва ако сайта ти е на някакъв недостатъчно стабилен хостинг и изведнъж изникнат толкова потребители
Сайтът ще бъде лек. Ако има видеоклипове в него, той ще е само 1, който да описва сайта и предназначението му. Няма да има потребителски вход или други сложни скриптове, ами ще има само изображения и текст, и малко PHP код, който естествено ще е оптимизиран до мозъка на костите си.
random_oracle
Registered
Какво значи 20 милиона посещения на ден? 20 милиона уникални посещения? 20 милиона импресии? 20 милиона заявки? Една "импресия" включва поне няколко заявки (картинки, банери, PHP, CSS, JS файлове), едно посещение включва поне няколко "импресии".
В най-добрият случай нека означава 20 милиона заявки на ден:
20 000 000 / (24*3600) = 231 заявки в секунда.
Колкото и да си оптимизираш PHP кода, ако ползваш apache/mod_php, ще сгънеш която и да е машина при такъв load. Това значи над 200 running процеса на машината и поне няколко гигабайта РАМ (влезнеш ли в swap-а си ебало майката).
И това е при положение че говорим за 20 милиона заявки на ден. Ако става въпрос за 20 милиона импресии или посещения, нещата стават с порядъци по-брутални.
Така че това далеч не може да се реши само с писане на "оптимизиран код" (каквото и да значи това). И статично съдържание да предоставяш само, това натоварване е смазващо.
Тези неща не се правят така, изграждат се server farm-и, определени машини сервират статично съдържание, определени сервират динамично, вероятно ще се наложи наличието на кеширащ SQL заявки слой (memcached сървъри), конфигурират се load-balancer-и, конфигурират се споделени файлови системи (примерно NFS). Аз лично съм администрирал такава ферма (портал на мобилен оператор) и доволно добре знам колко е сложно. Въпреки че далеч нямахме 20 милиона посещения на ден.
И като цяло, не мисля, че PHP е добър вариант за такова приложение, не е мислен да се scale-ва до такава степен. Не че е невъзможно, facebook го правят, но далеч не е лесно.
В най-добрият случай нека означава 20 милиона заявки на ден:
20 000 000 / (24*3600) = 231 заявки в секунда.
Колкото и да си оптимизираш PHP кода, ако ползваш apache/mod_php, ще сгънеш която и да е машина при такъв load. Това значи над 200 running процеса на машината и поне няколко гигабайта РАМ (влезнеш ли в swap-а си ебало майката).
И това е при положение че говорим за 20 милиона заявки на ден. Ако става въпрос за 20 милиона импресии или посещения, нещата стават с порядъци по-брутални.
Така че това далеч не може да се реши само с писане на "оптимизиран код" (каквото и да значи това). И статично съдържание да предоставяш само, това натоварване е смазващо.
Тези неща не се правят така, изграждат се server farm-и, определени машини сервират статично съдържание, определени сервират динамично, вероятно ще се наложи наличието на кеширащ SQL заявки слой (memcached сървъри), конфигурират се load-balancer-и, конфигурират се споделени файлови системи (примерно NFS). Аз лично съм администрирал такава ферма (портал на мобилен оператор) и доволно добре знам колко е сложно. Въпреки че далеч нямахме 20 милиона посещения на ден.
И като цяло, не мисля, че PHP е добър вариант за такова приложение, не е мислен да се scale-ва до такава степен. Не че е невъзможно, facebook го правят, но далеч не е лесно.
@random_oracle, благодаря за полезната информация. Тези работи дето разправяш, очевидно няма да мога да ги направя сам, прочитайки няколко manualа. Явно трябва много отбран и професионален екип за тая работа.
Промяна:
Забравих да спомена, че става въпрос за ~20 000 000 уникални на ден.
Промяна:
Забравих да спомена, че става въпрос за ~20 000 000 уникални на ден.
random_oracle
Registered
Това не е работа само на уеб девелопъри, такива неща изискват системни администратори да настройват сървърите, софтуерни архитекти, които да измислят целия дизайн по начин, който да позволява лесно да се scale-ва в зависимост от натоварването, вероятно мрежови администратори да се занимават с vlan-и, хардуерни load-balancer-и ако има и т.н.
Пак казвам, PHP не е добра идея за такива уеб-приложения. Разните комерсиални j2ee сървъри имат къде по-големи възможности. Примерно два много прости казуса ще ти дам.
Първият е със сесиите, очевидно трябва да ги пазиш някъде. Като имаш простичко PHP приложение, което се хоства на един сървър, не мислиш много за това. Ползваш или файлове, или SQL база. Като имаш няколко машини, които се занимават с динамичното съдържание и load-balancer, който разпределя натоварването, става сложно. Може balancer-а да е умен и да stick-ва сесиите към определен бекенд в зависимост от сесийното cookie. Но дори при това положение, какво става ако една от машините, които търкаля динамичното съдържание крашне или трябва да се спре за подръжка? Ако се е ползвала локална файлова система, всичките сесии отиват по дяволите и хората псуват. Ако се ползва споделена файлова система за сесиите, става грозно, създава се доста мрежов трафик, доста локване и е бавно. Ако се ползва SQL база тотално си ебало майката, неприемливо много SELECT-и. J2EE приложенията могат да си имат сесийни обекти и сесийна репликация между нодовете, това нещо се пише лесно и ти идва почти наготово. PHP не може да прави такива неща, там RPC не се използва.
Втори казус: искаш да разпределиш натоварването по равно между отделните сървъри, които сервират динамично съдържание. Само дето load-balancer-а обикновено е тъп и няма никаква идея за CPU load-а на машините, за изразходваната памет. Могат да станат грозни сцени от сорта на един от бекендите кляка при десетина паралелни заявки, които обаче са тежки, докато останалите си кютат щастливо при 5 пъти повече паралелни заявки. Очевидно това не е оптимално. Това е проблем, който е решен в J2EE света, при PHP ще ти трябва някой C програмист, който да ти напише някакъв бърз load-balancer, който да взема предвид това, защото няма наготово такъв софтуер (vbox-а тръгнаха по този път).
Та такива работи. Пак казвам, фейсбук могат да го правят това, но далеч не е лесно.
Пак казвам, PHP не е добра идея за такива уеб-приложения. Разните комерсиални j2ee сървъри имат къде по-големи възможности. Примерно два много прости казуса ще ти дам.
Първият е със сесиите, очевидно трябва да ги пазиш някъде. Като имаш простичко PHP приложение, което се хоства на един сървър, не мислиш много за това. Ползваш или файлове, или SQL база. Като имаш няколко машини, които се занимават с динамичното съдържание и load-balancer, който разпределя натоварването, става сложно. Може balancer-а да е умен и да stick-ва сесиите към определен бекенд в зависимост от сесийното cookie. Но дори при това положение, какво става ако една от машините, които търкаля динамичното съдържание крашне или трябва да се спре за подръжка? Ако се е ползвала локална файлова система, всичките сесии отиват по дяволите и хората псуват. Ако се ползва споделена файлова система за сесиите, става грозно, създава се доста мрежов трафик, доста локване и е бавно. Ако се ползва SQL база тотално си ебало майката, неприемливо много SELECT-и. J2EE приложенията могат да си имат сесийни обекти и сесийна репликация между нодовете, това нещо се пише лесно и ти идва почти наготово. PHP не може да прави такива неща, там RPC не се използва.
Втори казус: искаш да разпределиш натоварването по равно между отделните сървъри, които сервират динамично съдържание. Само дето load-balancer-а обикновено е тъп и няма никаква идея за CPU load-а на машините, за изразходваната памет. Могат да станат грозни сцени от сорта на един от бекендите кляка при десетина паралелни заявки, които обаче са тежки, докато останалите си кютат щастливо при 5 пъти повече паралелни заявки. Очевидно това не е оптимално. Това е проблем, който е решен в J2EE света, при PHP ще ти трябва някой C програмист, който да ти напише някакъв бърз load-balancer, който да взема предвид това, защото няма наготово такъв софтуер (vbox-а тръгнаха по този път).
Та такива работи. Пак казвам, фейсбук могат да го правят това, но далеч не е лесно.