Аз последно като местих фирмения сайт на нов сървър си бях заплюл един с амнайсе ядра щот нали уж многоядрените са перфектни за веба. Ама викам дай все пак да тествам. И тоя процесор дето беше с най-висока честота успя да обслужи повече заявки въпреки че беше май с 2 пъти по-малко ядра. И то честотата беше от сорта на само 200-400Мхц повече.
облачните драми
Дон Реба gat3way проблемът е че динамичното съдържание далеч не е така, но подхода за решаването на проблема отново е още хостове зад балансъри
да, щото е най-лесно. като нямаш тая опция да видиш как ще стане и без такава мощ. просто блоатинга успешно прикрива огромната мощ на съвременния хардуер (и на човешките способности), и дори хора специалисти свикват с това и рядко си го припомнят.освен това инструментите са нагодени към тоя пайплайн, базите данни, пхптата и тн.
ще се опитам да се аргументирам малко по-детайлно защо мисля така. дори и при милиони едновременно активни потребители, транзакциите и трансфера ще се съгласиш не са чак толкова много, изключвам варианта ддос де, което си е също грижа, но е различна тема. ето аз от колко време пиша, после ще натисна "запис" и към сървъра ще се пратят само няколко десетки байта отговор. за времето на писане средния ми трансфер е бил под един байт/сек. след това ще цъкна на друга тема, той пък ще ми прати малко повече да речем няколко килобайта, аз ще се зачета, като ги прочета ще видя, може да цъкна на друга тема без да съм дочел, средния трафик пак не е голям, с уговорката че фронтенда е мислен стая идея, нямаш плосък преглед или е моднат за да дава само един уводен ред. сумарно, средния трафик от потребител е съизмерим със този който човешките възприятия имат (снякакъв множител разбирасе). процесорната мощ нужна за да го обслужи смело мога да твърдя че също не е голяма. ще кажеш "ама ровене в базата ама путки майни", ами не. тук малко ще се отплесна. като съм правил изчислително тежки задачи много съм имал проблема с оплакване от потребители "процесора не се утилизира" - ами да вярно е, не се, просто днес процесорите са толкова бързи, че трансферана данните от/към рама е всъщност най-бавното. акоси утилизираш кеша и други хитрини може и да надвиеш трансфера, но може и да не може. така или иначе, покрай тия неща се замислих какъв е коефицента процесор/трансфер на различни типове ресурсоемки задачи. забелязах че почти няма ресурсоемки задачи които искат огромен превес на процесор над трансфер, единствения пример за който се сещам е чупенето на пароли и рисуването на манделброт. всичко друго което прави "много сметки" ги прави и върху "много данни". разбираш накъде клоня, аз съм убеден че бидейки невежа, ако хвана мога да напиша туитър или форум от нула, който може да поеме милиони едновременно активни потребители. като натъртвам от нула тръгна ли да гледам "как се прави", ще се повлека по практиките създадени и развивани в изобилие на сървърна мощ и ще ударя камъка.
В тази сметка пропусна да отчетеш криптирането. Въпреки че в по-голяма част от времето се ползва симетрично криптиране, то последното пак не е толкова леко като обикновено прехвърляне на информация.
gat3way Тоест, имаме примерно 1000 операции в секунда. Това на едно ядро от виртуална машина. На 16 ядра ще имаме 16000 операции в секунда.
Няма да имаш 16 хиляди операции, особено пък със sqlite-а, всъщност там дори вероятно нема да се нахендриш на io ограничения, ще се нахендриш на съвсем различни, за да не скалираш линейно с броя на ядрата.
Аз нямах предвид точно SQLite в тия сметки, а разсъждавам въобще за база данни.
SQLite, разбира се е силно подценявана база данни, относно бързодействието, но и тя си има собствените ограничения, особено когато става въпрос за бързо записване на данни от няколко източника. Ако става въпрос само за четене, там може да се съревновава с много от големите.
При големи мащаби обикновения SQL не върши работа. Да не говорим, че само една машина не може да върши цялата работа, дори и за средни мащаби се минава на клъстери.
Ето какво ползва Твитър:
Дърти Хари При големи мащаби обикновения SQL не върши работа. Да не говорим, че само една машина не може да върши цялата работа, дори и за средни мащаби се минава на клъстери.
Ето какво ползва Твитър:
johnfound Дърти Хари При големи мащаби обикновения SQL не върши работа. Да не говорим, че само една машина не може да върши цялата работа, дори и за средни мащаби се минава на клъстери.
Ето какво ползва Твитър:
Хе хе, мдаа, като си пиша следващото резюме ще го имам пред вид. Не съм писал от 14 години, но е свежо.
code2 В тази сметка пропусна да отчетеш криптирането. Въпреки че в по-голяма част от времето се ползва симетрично криптиране, то последното пак не е толкова леко като обикновено прехвърляне на информация.
то и асиметричното е леко, пък какво остава за симетричното.
Дърти Хари При големи мащаби обикновения SQL не върши работа. Да не говорим, че само една машина не може да върши цялата работа, дори и за средни мащаби се минава на клъстери.
Ето какво ползва Твитър:
аз затова подчертах че съм убеден че бих се справил само ако тръгна да го правя като невеж и от нула. опиташ ли да си помогнеш с готови техники и инструменти, ще се накиснеш без да усетиш.
Абе подозирам че по тоя път ще стигнеш сам до тва дето вече са го измислили, не за друго, а защото обикновено така става.
gat3way Абе подозирам че по тоя път ще стигнеш сам до тва дето вече са го измислили, не за друго, а защото обикновено така става.
да, така става,ако си в същата среда. презумпцията тука е че не си, и че точно опита натрупан от специалистите в старите условия ги прави безпомощни. това съм го виждал в най-различни проекции в реалния свят.
Те да го оптимизират и т.н., обаче после ако трябва да обучават 2 години новия персонал да прави нещо по продукта, накрая пак няма да излезне сметката и се връщаме до трета теорема на Рабин, а тя е:
"Времето на хардуерът е по- евтино от времето на погромиста"
Дон Реба де го хардуера :)
Четвърта теорема на Рабин:
Облакът е по- евтин от хардуера и заплатите на поддържащите го айтита.
А първа теорема е:
Чатът в слак е по- евтин от скумът по един час.
Втора теорема е:
Ако работи, не го поправяй и не го изхвърляй.
Courvoisier "Времето на хардуерът е по- евтино от времето на погромиста"
Това просто не е вярно. Програмата се пише веднъж, но се изпълнява много пъти. Ясно е, че рано или късно, времето за изпълнение на програмата ще стане по-скъпо от времето на програмиста.
Има и още един аспект – по-правилно е да се сравнява не машинното време с времето на програмиста, а времето на потребителя с времето на програмиста. И тогава картинката става наистина епична.
johnfound Това просто не е вярно. Програмата се пише веднъж, но се изпълнява много пъти.
Програмата никога не се пише веднъж. Програмата се пише и променя ПОСТОЯННО. Иначе фирмите нямаше да назначават програмисти на щат.
Що не си гледаш хладилниците, а коментираш неща от които не разбираш?
Тя програмата се пише постоянно, но пък от друга страна се изпълнява още по-постоянно. Това е точно на принципа според който всички хора са равни, но някои са по-равни.
Courvoisier Дон Реба де го хардуера :)
Четвърта теорема на Рабин:
Облакът е по- евтин от хардуера и заплатите на поддържащите го айтита.
GOTO 10 : REM Спазвай въведената от джони начална иднексация!!! code2, програмните редове не са индексация
code2 Тя програмата се пише постоянно, но пък от друга страна се изпълнява още по-постоянно. Това е точно на принципа според който всички хора са равни, но някои са по-равни.
И какво като се изпълнява постоянно, идиот? Да не би хора да изпълняват програмата?
Дон Реба Courvoisier Дон Реба де го хардуера :)
Четвърта теорема на Рабин:
Облакът е по- евтин от хардуера и заплатите на поддържащите го айтита.
GOTO 0 : REM Спазвай въведената от джони начална иднексация!!!
В този случай, според зависи договорът и адвокатите, може да тръгнат едни дела съдабни в онази страна, в която хората съдят деуги хора, че не написали да не слагат кучетата си в мирковълноеата.