C++ CGI

В отговор на:

---

Само че не можах да го тествам, щото имам само една машина на виндовс и клавиатурата и има прах.

---

Боже боже! Пред какъв титаничен хардуерерн проблем си изправен! Няма две мнения по въпроса. Машината трябва да се изхвърли. Щото вече е омърсена от кабела на клавиатурата който влиза в нея. И докосва физически частите и...

Просто не я ползвам ... От време на време пускам некой филм на неа или музика. Визуално студио не съм отварял от една година и не ми липсва особенно.

"До сега направих около 13 проби и грешки"

Хаха, жестоко - аз редим трета генерация хава и си мислех, че съм зле

Но пасаран - требе изцяло да ти е на тебе у кухарката, заеби пънкарските комуни, които седят добре на снимката за дедо, спестявайки, как чорапите се сменят редовно - три дни налице, три дни наопъки

Teh quk bron fox jums over teh lazy dog...

При фцги се работи с отделен процес. А поне в това отношение повечето оси си приличат. Никоя не зарежда процеси в общо адресно пространство. Изключвам изродчетата създадени с учебна цел.


За какво общо адресно пространство говорим?
Тука става въпрос за "Преизползваемост на ресурсите".
Общото адресно пространство си го запази за интервюиращите:-)

А поне в това отношение повечето оси си приличат
И по какво си приличат?

FastCGI има предимството пред CGI, а именно :-)
При FastCGI има "преизполсваемост" на процесите, или така наречения "Process pooling", така както ASP.NET-а има "Thrеаd pooling".
Това е най-важното подобрение на FastCGI.


При фцги се работи с отделен процес
Ми то и при IIS 6.0 и нагоре се работи с отделен процес, защото всеки Applicaton pool при първа заявка създава нов процес, след което другите заявки отварят нов thread, но забележи в рамката на процеса..

Айде сега да направим един "анализ":-)

При FastCGI историята е следната:
1. постъпва първа заявка...създава се нов процес
2.постъпва втора заяка, докато първата не е приключила... създава се нов процес
3.постъпва трета заявка докато първите 2 не са приключили... създава се нов процес...
4. постъпва n-та заявка докато заявки от 1 до n-1 не са приключили...създава се процес n-ти...

При ASP.NET историята е следната:
1. постъпва първа заявка...създава се нов процес и нов thraed, който поема заявката
2.постъпва втора заяка, докато първата не е приключила... създава се нов thraed в рамката на процеса
3.постъпва трета заявка докато първите 2 не са приключили... създава се нов threadв рамката на процеса...
4. постъпва n-та заявка докато заявки от 1 до n-1 не са приключили...създава се n-ти thread рамката на процеса...

И като Изключим опашките, в които се нареждат заявките, които не могат да вземат process/thread, кажи ми теоретично, кой от двата модела е по-ресурсоемък, по-бавен и кой е по-надежден?

Дуре ве пич,
не ме пращай там, от където се връщам...алексата явно за теб е мадъ нейчер... В интерес на истината - разходих се, видях, запознах се...

MSDN-а беше просто един пример, но явно ти не схвана същината

Жив и здрав да си ти:-)

В отговор на:

---

При фцги се работи с отделен процес. А поне в това отношение повечето оси си приличат. Никоя не зарежда процеси в общо адресно пространство. Изключвам изродчетата създадени с учебна цел.


За какво общо адресно пространство говорим?
Тука става въпрос за "Преизползваемост на ресурсите".
Общото адресно пространство си го запази за интервюиращите:-)

А поне в това отношение повечето оси си приличат
И по какво си приличат?

FastCGI има предимството пред CGI, а именно :-)
При FastCGI има "преизполсваемост" на процесите, или така наречения "Process pooling", така както ASP.NET-а има "Thrеаd pooling".
Това е най-важното подобрение на FastCGI.


При фцги се работи с отделен процес
Ми то и при IIS 6.0 и нагоре се работи с отделен процес, защото всеки Applicaton pool при първа заявка създава нов процес, след което другите заявки отварят нов thread, но забележи в рамката на процеса..

Айде сега да направим един "анализ":-)

При FastCGI историята е следната:
1. постъпва първа заявка...създава се нов процес
2.постъпва втора заяка, докато първата не е приключила... създава се нов процес
3.постъпва трета заявка докато първите 2 не са приключили... създава се нов процес...
4. постъпва n-та заявка докато заявки от 1 до n-1 не са приключили...създава се процес n-ти...

При ASP.NET историята е следната:
1. постъпва първа заявка...създава се нов процес и нов thraed, който поема заявката
2.постъпва втора заяка, докато първата не е приключила... създава се нов thraed в рамката на процеса
3.постъпва трета заявка докато първите 2 не са приключили... създава се нов threadв рамката на процеса...
4. постъпва n-та заявка докато заявки от 1 до n-1 не са приключили...създава се n-ти thread рамката на процеса...

И като Изключим опашките, в които се нареждат заявките, които не могат да вземат process/thread, кажи ми теоретично, кой от двата модела е по-ресурсоемък, по-бавен и кой е по-надежден?

---

Това е втората редакция на тоя пост. Когато приключих първата се почувствах много кофти. Бях си обещал преди години да не бъда толкова гаден с хората. И е на - смилих се.
За съжаление си попаднал на кофти резултат. Заявката се предава през канал за комуникация към процеса. Резултата се връща по същия, след което се затваря. Остава да уточним разликите между отваряне на комуникация и стартиране на процес.

PS: PHP не прощава...

Това, че заявката преминава през канал за комуникация към процеса е вярно, но за single-threaded приложения е факт, че при постъпване на заявка, ако няма свободен процес в пула, FastCGI-а създава нов процес.
При Multi-threaded приложения може да се отворят повече канали към един процес... Надявам се обаче да не говорим за multi-threaded приложения,защото за тях и при ASP.NET например има не по-лошa производителност.

И ако съм те "засегнал" по някакъв начин в предния пост, моля за извинение, целта ми беше просто един дебат, защото може и аз някъде да греша.

P.S. На PHP и два реда не мога да напиша, а ако се наложи сигурно ще ги пиша 2 дена :-)

Дуре ве пич,
не ме пращай там, от където се връщам...алексата явно за теб е мадъ нейчер... В интерес на истината - разходих се, видях, запознах се...

Е щом се връщаш от там има ли в топ 1000 топ 10000, нещо което ползва виндовс и ИИС без msn.com и microsoft.com?

[линк]
[линк]

Защо според теб youtube ползват за serving на видео LightHTTPD, който е synchronous single thread.

[линк]

Та хайде обясни ми за какво точно спорим? Опитваш се да ми обясниш, че IIS и ASP.NET са с добър performance?

Щом си чувал за алекса за "context switch", чувал ли си.

Значи не смяташ, че фцги чака да се съберат определен брой заявки за да стартира едновременно няколко инстанции на един процес, с единствената идея, че се зареждат от общ файл? Добре, добре. Това дейста някак успокояващо. Сам разбираш, за момент си помислих най-лошото.

В отговор на:

---

При Multi-threaded приложения може да се отворят повече канали към един процес... Надявам се обаче да не говорим за multi-threaded приложения,защото за тях и при ASP.NET например има не по-лошa производителност.

---

Нали рева до преди два поста колко несигурен и платформено-ограничен бил асп.нетя? Както и да е. Нека са еднонишкови и не ползват общи ресурси изискващи синхронизация. Какъв е проблемът? Че имат допълнителен тлиб буфер ли?

...леко баце леко...

[линк]

ASP.NET + SQL2008 на не много силно желязо.

[линк]

Stackoverflow върви мисля на леко къстомизирана версия на ASP.NET MVC 1.0. Имаше на codinghorror.com някъде постове как са го направили, беше доста интересно.

Като цяло са се справили доста добре, последно май вървеше само на 4 машини.

Иначе лично на мене ми е интересно защо още не могат да правят достатъчно пари при толкова потенциал за реклама и крос-сейлове от джобс обяви, че търсят капитал:

[линк]

--
One day it will make sense.

EE въобще не им е конкурент вече, отдавна го издухаха. В момента се целят във phpBB, което вече е амбициозно.

[линк]

Гейовете като жените, преди 2 дена псува венчър капитала, сега го хвали.

--
One day it will make sense.

Целят се в phpBB?! Ако става въпрос за StackExchange то няма почти нищо общо с phpBB. Все едно да сравняваш тир с трактор.

За ЕЕ, сега видях, наистина са ги позадминали. За издухване май е рано да се говори още но с това темпо едва ли ще отнеме много време.

Задминали са го като трафик, ако гледаш Гуугъл Трендс или Алекса. Също така и като качество на отговорите. Но не е ясно дали монетаризират добре този трафик, Експерт Секс Чейндж имат платен модел и може и да успяват да си докарат доста кинти, СО са само с реклами и не е ясно.

--
One day it will make sense.

Между другото е доста малоумно да си продадеш половината гъз, след като вече си направил по-трудната част и си задвижил машината. Не мога да разбера какво ще прави с екстра кеша си, явно не съм единствен:

[линк]

--
One day it will make sense.

Такива хватки не се учат в училище. В същност Джоел иска 10 милиона не за СО, а за нов сайт, който ще има подобни неща, но за масово ползване. И не монетизира СО, защото разузнаването още с първия отчет ще му разберат пломбите в устата, а от там инвеститорите ще си направят по-точна оценка за това дали си струва да се дават 10 милиона за някакъв дял. По-добре е да продава дял на база големия ръст в трафика и ентусиазъм, от колкото на база реалната доходност. Реално не може да направи супер много пари СО за следващите няколко години - много нишов, все гийкове с ад блокъри, афилиейтите са малко накриво като бизнес и искат нърчъринг. Един вид Джоел прехвърля този риск на тях, ако някой се навие - хубаво, ако не, със сигурност сам ще го монетизира до 1 година предполагам.

Somewhat related, препоръчвам ако имаш излишен час (добре върви като фон на кърлинга от олимпийските игри)

[линк]

--
One day it will make sense.

един въпрос извън темата: тва разузнаване и тези инвеститори като са толкова печени що се оплетоха като пате в къчища и докараха финансовата система пред срив? - тоест на ръба да останат с празни ръце