Аз последно като местих фирмения сайт на нов сървър си бях заплюл един с амнайсе ядра щот нали уж многоядрените са перфектни за веба. Ама викам дай все пак да тествам. И тоя процесор дето беше с най-висока честота успя да обслужи повече заявки въпреки че беше май с 2 пъти по-малко ядра. И то честотата беше от сорта на само 200-400Мхц повече.
code2
Последно редактирано на 12.01.2021 от code2, видяно: 1389 пъти. #26522
В тази сметка пропусна да отчетеш криптирането. Въпреки че в по-голяма част от времето се ползва симетрично криптиране, то последното пак не е толкова леко като обикновено прехвърляне на информация.
johnfound
Създадено на 12.01.2021, видяно: 1366 пъти. #26524
Тоест, имаме примерно 1000 операции в секунда. Това на едно ядро от виртуална машина. На 16 ядра ще имаме 16000 операции в секунда.
Няма да имаш 16 хиляди операции, особено пък със sqlite-а, всъщност там дори вероятно нема да се нахендриш на io ограничения, ще се нахендриш на съвсем различни, за да не скалираш линейно с броя на ядрата.
Аз нямах предвид точно SQLite в тия сметки, а разсъждавам въобще за база данни.
SQLite, разбира се е силно подценявана база данни, относно бързодействието, но и тя си има собствените ограничения, особено когато става въпрос за бързо записване на данни от няколко източника. Ако става въпрос само за четене, там може да се съревновава с много от големите.
ДъртиХари
Създадено на 12.01.2021, видяно: 1354 пъти. #26526
При големи мащаби обикновения SQL не върши работа. Да не говорим, че само една машина не може да върши цялата работа, дори и за средни мащаби се минава на клъстери.
johnfound
Създадено на 12.01.2021, видяно: 1344 пъти. #26528
При големи мащаби обикновения SQL не върши работа. Да не говорим, че само една машина не може да върши цялата работа, дори и за средни мащаби се минава на клъстери.
ДъртиХари
Създадено на 12.01.2021, видяно: 1329 пъти. #26529
При големи мащаби обикновения SQL не върши работа. Да не говорим, че само една машина не може да върши цялата работа, дори и за средни мащаби се минава на клъстери.
Хе хе, мдаа, като си пиша следващото резюме ще го имам пред вид. Не съм писал от 14 години, но е свежо.
ДонРеба
Създадено на 13.01.2021, видяно: 1294 пъти. #26536
В тази сметка пропусна да отчетеш криптирането. Въпреки че в по-голяма част от времето се ползва симетрично криптиране, то последното пак не е толкова леко като обикновено прехвърляне на информация.
то и асиметричното е леко, пък какво остава за симетричното.
ДонРеба
Създадено на 13.01.2021, видяно: 1292 пъти. #26537
При големи мащаби обикновения SQL не върши работа. Да не говорим, че само една машина не може да върши цялата работа, дори и за средни мащаби се минава на клъстери.
аз затова подчертах че съм убеден че бих се справил само ако тръгна да го правя като невеж и от нула. опиташ ли да си помогнеш с готови техники и инструменти, ще се накиснеш без да усетиш.
gat3way
Създадено на 13.01.2021, видяно: 1268 пъти. #26541
Абе подозирам че по тоя път ще стигнеш сам до тва дето вече са го измислили, не за друго, а защото обикновено така става.
ДонРеба
Създадено на 13.01.2021, видяно: 1261 пъти. #26542
Абе подозирам че по тоя път ще стигнеш сам до тва дето вече са го измислили, не за друго, а защото обикновено така става.
да, така става,ако си в същата среда. презумпцията тука е че не си, и че точно опита натрупан от специалистите в старите условия ги прави безпомощни. това съм го виждал в най-различни проекции в реалния свят.
Те да го оптимизират и т.н., обаче после ако трябва да обучават 2 години новия персонал да прави нещо по продукта, накрая пак няма да излезне сметката и се връщаме до трета теорема на Рабин, а тя е:
"Времето на хардуерът е по- евтино от времето на погромиста"
ДонРеба
Създадено на 13.01.2021, видяно: 1227 пъти. #26558
johnfound
Създадено на 13.01.2021, видяно: 1209 пъти. #26563
"Времето на хардуерът е по- евтино от времето на погромиста"
Това просто не е вярно. Програмата се пише веднъж, но се изпълнява много пъти. Ясно е, че рано или късно, времето за изпълнение на програмата ще стане по-скъпо от времето на програмиста.
Има и още един аспект – по-правилно е да се сравнява не машинното време с времето на програмиста, а времето на потребителя с времето на програмиста. И тогава картинката става наистина епична.
|
Създадено на 13.01.2021, видяно: 1203 пъти. #26565
Това просто не е вярно. Програмата се пише веднъж, но се изпълнява много пъти.
Програмата никога не се пише веднъж. Програмата се пише и променя ПОСТОЯННО. Иначе фирмите нямаше да назначават програмисти на щат.
Що не си гледаш хладилниците, а коментираш неща от които не разбираш?
code2
Създадено на 13.01.2021, видяно: 1199 пъти. #26566
Тя програмата се пише постоянно, но пък от друга страна се изпълнява още по-постоянно. Това е точно на принципа според който всички хора са равни, но някои са по-равни.
ДонРеба
Последно редактирано на 13.01.2021 от ДонРеба, видяно: 1199 пъти. #26567
де го хардуера :)
Четвърта теорема на Рабин:
Облакът е по- евтин от хардуера и заплатите на поддържащите го айтита.
GOTO 10 : REM Спазвай въведената от джони начална иднексация!!! code2, програмните редове не са индексация
|
Създадено на 13.01.2021, видяно: 1193 пъти. #26568
Тя програмата се пише постоянно, но пък от друга страна се изпълнява още по-постоянно. Това е точно на принципа според който всички хора са равни, но някои са по-равни.
И какво като се изпълнява постоянно, идиот? Да не би хора да изпълняват програмата?
Облакът е по- евтин от хардуера и заплатите на поддържащите го айтита.
GOTO 0 : REM Спазвай въведената от джони начална иднексация!!!
В този случай, според зависи договорът и адвокатите, може да тръгнат едни дела съдабни в онази страна, в която хората съдят деуги хора, че не написали да не слагат кучетата си в мирковълноеата.