C++ CGI

що JNI, e - вярно, че е по-вазелинесто ама все пак може :)

Както казваше старшината в казармата...: Всичко може, само печка от дърва не може:-)

При уеб приложения, 99% от производителността е в базата данни обикновено, ако не се правят титанични глупости.


Нали за това казах, следното "При равнопоставени приложения"?!!

Дай ми пример за CGI, в който да не е процес? Без значение за ОС или уеб сървър.

Ето да прочетеш и малко от извора:
[линк]

Зависи какви ресурси визираш. Ако махнем оригиналното ЦГИ от картинката, необходимите хардуерни и енергийни ресурси падат с порядъци. Скоростта на обработка на трафика може да стигне границите на хардуера за комуникация при конвенционални задачи. Недостатъците също не са за пренебрегване. Цената на човешките ресурси също ползва тези порядъци. Само че, нагоре, с набучена нула в дупето. Моралната стойност на продукта остарява с хардуера на който работи и технологиите на които стъпва.

Дай ми пример за CGI, в който да не е процес? Без значение за ОС или уеб сървър.

Ама нали точно затова говорим :-)

Отварянето на нов процес в Windows е доста по-ресурсоемко и трудоемко от отварянето на нов thread. Използването на CGI под Windows и IIS е меко казано неефективно.
Не случайно Microsoft създадоха FastCGI web service extension-а за IIS 7.0

В отговор на:

---

защото самата архитектура на Windows-а е multithrading базирана, а не multiprocessoors базирана

---

Това нещо не го рабрах, би ли обяснил?

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

В обявата става дума за Linux. [линк].

nginx + fastCGI++ е най-бързото решение в веб в момента, НЕ за windows разбира се. Кой е тоя олигофрен дето ще пусне windows в интернет? Единственото по-бързо е да си направиш собствен веб сървър на C++, който може да е scalable, което правя аз в момента, няма да казвам за кого. Но решението го налагат performance проблеми. Каквито и доводи да си мислите за .NET, JAVA, PHP няма да промените тези факти. C++ не се ползва масово, защото е по-скъпа разработката. Но при по-големи веб сайтове/апликейшани, излизаш на печалба от C++ performance gain-a. Все пак 99.99% от сайтовете са никому неизвестни глупости и могат да бъдат написани на каквото и да е, така че хляба ви не е застрашен. Също още доста време ще има десктоп апликейшъни, дека немат нужда от перформънс. Не търся флейм за езици. Ако проблема може да се реши с ексел, и това е най-бързия начин, така и трябва да се реши. От разработчик на това ниво. За секой влак си има пътници.

Защо веднага заговорихте за уеб, CGI не е единствено и само за това.

Тва с отделните процеси ми звучи като някакъв довод от 1999-та. Тогава Perl беше цар, MySQL беше още 3.x, а ASP-то се пишеше на VBScript и се хостваше на IIS 4.0.

CGI като технология има смисъл да се ползва единствено и само ако имаш някакъв мнооого, ама мноооого стар скрипт, писан на Perl примерно, и който ти върши някаква работа и не можеш/не искаш да го пренапишеш, или да си платиш на някой да ти го пренапише.

А пък като чуя C++, още повече и в Web среда и получавам вътрешен кръвоизлив. В смисъл ако примерно VMWare ти предлагат 5k месечно, за да пишеш CGI applications на C++ - knock yourself out дет` се вика, макар че пак би трябвало да си имаш едно наум.



Eeeeeeeeeeeeeeeaaaaaaasy rider

Нейтив кода не е "една идея" по-бърз от менаджед лайната, ами в най-лошия случай поне 5-6 пъти.
Старомодния CGI е правен при други условия и днес е действително не е добро решение, но, все пак, CGI значи предимно интерфейс към веб-сървъра и реално има мегдан за абстракции. Предполагам, точно това са имали предвид в тая фирма - Ц++ програмист, който да има идея от веб.

Цената на джавистките/пхп/дотнет човешки ресурси е по-голяма от Ц++ месото. Практиката показва, че времето за разработка обикновено е същото в добрия случай. Говорим за сериозни проекти с планирано голямо натоварване и тежки сметки. Реално няма абсолютно никаква полза един такъв проект да се почва на джава/пхп/дотнет, защото в един момент ще усетиш дебелия в гъза си и ще почнеш да мислиш разни идиотски кръпки на идиотските проблеми, възникнали поради идиотските ти решения. Виж темата за фейсбук и специалния им преводач от ПХП на Ц++.

Нали това казвам. При веб, рамките на големите проекти обезпечаващи имплементация на С++ са прекалено частен случай за да важи обобщението в първото ти изречение.

nginx + fastCGI++ е най-бързото решение в веб в момента, НЕ за windows разбира се.
Може и така да е, а може и да не е така.... Тука можем да поспорим доста, но само върху реални данни, а не в/у "волеизявления" без факти :-)

Кой е тоя олигофрен дето ще пусне windows в интернет?
Ще ти кажа кой е :-) MSDN-а на Microsoft е изцяло изграден на АСП.НЕТ под IIS!
Ето ти една web система, с повече от 1000 рекуста в секунда, система, която е с добър performance, scalable, securable и поема доста добър трафик.

Айде сега ти ми кажи една система, подобна на MSDN-а, която се хоства под nginx + fastCGI++ ?

Единственото по-бързо е да си направиш собствен веб сървър на C++, който може да е scalable, което правя аз в момента, няма да казвам за кого.
Пожелавам ти да направиш най-бързия уеб сървър, но според мен щом съществуващите технологии не могат да паснат на "Вашия стандарт за performance", не е ли по-логично да направите един анализ на приложението си и да се съсредоточите в/у refactoring-а за постигане на по-добър performance?

C++ не се ползва масово, защото е по-скъпа разработката.
Айде сега ни осветли Защо C++ е по-скъпа разработка? Кое прави тази технология по-скъпа?

Също още доста време ще има десктоп апликейшъни, дека немат нужда от перформънс.
Те от такива апликейшъни, дека немат нужда от перформънс започна да ми побелева косата баце :-)

Интересно ми е как ще се реши проблемът със скейла с C++ веб сървъра т.е как ще го сложим на клъстер. MPI?

nginx е posix базиран. Не ползва екстричките на windows. Няма Completion ports, няма асинхронен accept, да не говорим за асемблерни оптимизации и т.н.
Аз имам един проект за уеб сървър, който си го работя от около 6 години. Правя го на С/С++ х32 и х64. До сега направих около 13 проби и грешки докато намеря правилната формула за web сървър под Windows.
Но в момента преработвам самия сървър на ниско ниво - ползва драйвер за http, различни процеси могат да ползват един и същ порт - и най-якото е че всичките I/O са в windows kernel mode. На тестовете за сега е много по-бърз от nginx (windows). За момента обаче съм го зарязал, защото ако продължавам така никога няма да свърша основната задача. А тя е облаци (мастика с мента).

Една от последните версии:
[линк]
[линк]

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

Та нещо което работи под linux няма как да ползва "екстричките на windows". Нещо не си ми чел целия пост или аз не разбирам твоя.

Cluster openmp също върши работа. Зависи каква ти е политиката, после зависи от това, какво точно ще скалираш толкова.

Аз не съм много компетентен по въпроса. Нека Aaron да се изкаже. Той е спеца по многопроцесорните оси и дистрибутивните модели.

Дуре ве пич, разходи са по алексата и после поствай са няма да си губя времето да колектвам данни. Хората от години борят 10k problem, ти ми говориш за MSDN и 1000 рекуеста в секунда. При това положение директно ме отказваш изобщо да споря с теб. Всичките ти въпроси имат отговор в гоогле. Белата коса ти е лична грижа. Прочети малко статии за проблемите, които се мъчат да решават големите сайтове. Все пак енергията ще поскъпва а рекламата за сега поефтинява.

Само да спомена за МСДН. Едно време беше толко зле този сайт/система/мрежа или квото искат да се казва. Че всички си го инсталвахме локал, ако ще го ползваме. Което беше хубаво де, по бързо беше да запомняш, отколкото да ровиш. Са гоогле ни глези. Можеш да намериш и статистика в момента, какъв процент от рекуестите към МСДН идват от гоогле, което е показателно за това как хората го ползват.