"Тяжелые" скрипты и CGI

[Quake3]

Прошу прощения, если эта тема уже где-то обсуждалась, но через поиск я ничего вроде не нашел.
Хотелось бы обсудить актуальность использования CGI скриптов в веб-разработке, для проектировки высоконагруженных систем (админки тех же ддос ботов например) и вообще. Тема эта меня заинтересовала после обзора не помню уже чего. Там упоминалось, что системы была написана на CGI, поэтому выдерживала нагрузки лучше, чем аналогичная на php. Еще упоминался sutraTDS, в котором очень хороший редирект, опять же на этом CGI.

Действительно ли CGI кодинг актуален и дает какие-то преимущества? Или, при умении и знаниях, аналогичное можно реализовать и на php?

 

[Ar3s]

Особой разницы при программировании админки язык программирования не имеет.
Тут суть разговора была в том, как обрабатывать данные. В итоге все сошлись на мнении что никакой перл или php не сопоставим по скорости работы с бинарным приложением. И до сих пор непонятно почему не пишут связку как отдельное приложение для системы. т.е. интерпретируемые языки программирования требуют прослойки в виде обработчика. Будь то perl, php, rubby и т.д. и происходит задержка между обращением к скрипту и получением результата. Тут все зависит от того с какой скоростью система запустит тот же php5, передаст ему файл, получит результат исполнения и вернет его пользователю/браузеру.
В отличии от приложения висящего в памяти и написанного непосредственно для этих целей. Оно в разы ускорит обработку и выдачу результатов. Сложность в том, что написать такое приложение довольно сложно.

Что же касается cgi - тонкостей много, но сводятся к тому что perl позволяет создавать по-сути бинарные приложения. За счет этого и происходит такое ускорение в работе.

p.s. если где ошибаюсь - поправьте пожалуйста.

 

[E.N.G.Land]

Немножко не в тему, но все же думаю будет интересно и полезно архитектура Twitter

 

[TrueUser]

Перл тоже интерпретируемый язык программирования, как и пхп (и они оба создают промежуточный байткод ака бинарник для работы).
Приложение написанное и скомпилированное под ось (уже в виде исполняемого файла) быстрее обычного скрипта на порядки, чем скрипты с оптимизатором - на порядок, но если применять некоторые техники программирования и настройки системы можно получить и более высокие значения (например в 1000 раз быстрее).
Вообще говоря чтобы разрешить все споры о терминологии изначально CGI это Common Gateway Interface и ни коим образом не соотносится с тем как будут обработанны данные (пхп, перл, скомпилированный бинарь). Это всего навсего интерфейс взаимодействия вебсервера и приложения. Рекомендую порыться в нашей библиотеке там я положил книгу по пхп, в ней популярно все это объясняется.

Вообще говоря существуют нормальные библиотеки для c-based программирования для работы с тем же mysql если требуется ее функционал, но проще наверное работать напрямую с файлами. Кодинг на сях благополучно сопровождает легендарная 500 ошибка, но это уже детали, было бы желание.
Перед тем как что то ваять необходимо изучить детали CGI протокола обмена и желательно HTTP протокола.
Для написания сверхбыстрых приложений - memcache, потоки, приоритеты процессов в UNIX.
Я знаю, что ниша сверхпроизводительных скриптов в паблике практически свободна, UNIX программистов не так уж и много, а задача специализирована. Однако, крупные рыбы в деле трафика давно нанимают программистов для написания персональных программных пакетов, ибо та тухлятина, которой тут большинство пользуется просто напросто роняет восьмиядерные сверхоперативные сервера при трафике в несколько лямов в сутки.
Что такое лям в сутки если человек зарабатывает небольшой процент на обороте трафика - не так уж и много поверьте.

Итог: научишься грамотно кодить высокопроизводительные серверные приложения - без работы и денег н останешься.

 

[el-]

тут сложно вот так просто сказать лучше или не лучше, никто не спорит что сишные бинарники шустрее работают ибо они не компилируются как пхп, хотя от того как ты их напишешь тоже много зависит. да и оправдано ли будет разбираться с ними если пхп вполне достаточно

узкие моменты тут как раз не в скорости запуска скриптов, а например в бд или обращение к винту, тут особой разницы не будет между си и пхп.

вот к примеру обычная картина ( апачей намного больше, это просто верх списка ), на груженый мускул и 100500 процессов апача которые по сути особо ничего не жрут, но за счет своего количества нагружают память

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1125 mysql 20 0 335m 92m 7632 S 23 1.5 779:13.64 mysqld
20242 www-data 20 0 287m 13m 3584 S 2 0.2 0:00.07 apache2
20230 www-data 20 0 287m 13m 3764 S 2 0.2 0:00.22 apache2
20195 www-data 20 0 288m 13m 3732 S 1 0.2 0:00.28 apache2
19998 www-data 20 0 289m 15m 4096 S 1 0.3 0:01.27 apache2
20169 www-data 20 0 287m 13m 3812 S 1 0.2 0:00.45 apache2
20173 www-data 20 0 290m 15m 3812 S 1 0.3 0:00.24 apache2
20119 www-data 20 0 288m 13m 3880 S 0 0.2 0:00.27 apache2
20127 www-data 20 0 289m 14m 3884 S 0 0.2 0:00.31 apache2
20203 www-data 20 0 287m 13m 3840 S 0 0.2 0:00.14 apache2
20209 www-data 20 0 288m 13m 3820 S 0 0.2 0:00.08 apache2
20220 www-data 20 0 288m 13m 3632 S 0 0.2 0:00.05 apache2
20224 www-data 20 0 288m 13m 3672 S 0 0.2 0:00.08 apache2

собственно для разгрузки всего этого ( хотя и так вполне нормально ), примерно можно сделать следующие ( я все хотел попробовать, но я так не люблю что то менять, в общем руки так и не дошли )

во первых поставить ngxin который запусти дефолтное колво воркеров, тут экономится память ибо процесов будет 5-10-20, потом доставлять php-fpm ( есть в пхп 5.3 ) который опять же подымит несколько воркеров ( которые будут расти до максимального колва в случае нагрузки ), опять же экономия памяти.

во вторых заюзать eaccelerator которым скомпилить все пхп скрипты в бинарный код, дабы не тратить время на их постоянную компиляцию.

в третьих если что то читается с винта его лучше прочитать в память хз например с помощью memcached, что бы сбросит нагрузку с винтов

четвертым пунктом и основным идет мускул, который придется крепко оптимизировать а именно, расставить правильно индексы, максимально снизить размер полей ( типа ип хранить не в текстовом виде, а в unsigned int ну и так далее ). к тому же если из него постоянно что то читается, что особо не меняется ( мб какие то флаги, конфиги или еще что то ) то заюзать memcached, в принципе и мускул сам кеширует запросы но все опять же зависит от обстоятельств

к тому же такие моменты, например к вам приходят 100500 визиторов или ботов которые вы постоянно записываете в мускул, это ему крайне не нравится, если же сделать запись сразу кучей 10-20-nn полей то это опять же сильно его разгрузит, но такое реализовтаь сложно ибо пхп скрипты ничего не знают друг о друге и нельзя просто взять и собрать инфу о 10-20 ботах/визиторах надо её где то хранить, memcached для этого не подходит ибо нельзя ( вроде бы ) из него достать много данных не зная их имени. в общем самое классное, так сказать сделанное по феншую, что мне удалось найти в интернетах - это libevent демон на пхп, который принимал данные складировал их у себя в массивы ( причем всячески мог их изменять/добавлять ) и потом кучей заливал в мускул, получился такой заточенный под конкретную задачу sql/memcache
update1: пока писал вроде нашел, в xcache есть апиха xcache_list, которой вроде можно получить список данных
update2: есть же еще PDO, которая ( как говорят ) работает шустрее с мускулом

Да и по мимо мускула есть уже куча всяких альтернативных бд, redis например и т.д. сейчас так популярных nosql решений.

В действительности, я сомневаюсь что у вас такие дикие нагрузки с которыми бы не справились правильно реализованные и настроенные 4 пункта ( которые выше ) + жирный сервер ;D

 

[Ar3s]

el- замес примерно следующий:
Sutra TDS на обычной vds пропускает до ляма трафа в сутки и чувствует себя нормально.
Среднестатическая связка на той же vds более 200К не может выдать. Загибается.

Хотя ты на 100% прав в том, что загибается за счет MySQL. Я постоянно мониторил такие нагрузки. 90% загрузки CPU - это база данных. На реальной железке перешагнуть 500К становится уже сложно. Не говоря уже о лимоне.

 

[el-]

Ar3s, вы зря сравниваете тдску и связку

в случае тдс надо записать визитора, и на основание схем редиректнуть его куда то там, на тдс приходится в основно 1 или 2 запроса от визитора ( 2 если ставится кука и делается еще редирект дабы проверить куку ), с отдачей статичного контента

на связку приходится минимум 3 запроса с отдачей статичного контента ( если он собран например как в фениксе, с заменой только лишь линков ), а у некоторых контент собирается на лету, причем разница в размере отдаваемого контента велика по сравнению с тдс ( это если вы жс редирект юзаете, а так то просто хттп хидер location )

вот и получается что на связку 200, по 2-4 запроса, против одного на тдс, к тому же что большинство связов совершенно не оптимизированы и сравнивать с сутрой их вообще нельзя, это не значит что си цги безмерно круто и писать надо только на нем, можно как следует оптимизировать пхп и все будет отлично

 

[TrueUser]

Нет, ну никто не утверждает того что пхп бесконечно туп перед бинарниками, на нем порой гораздо проще реализовать многие вещи.
Тут дело в подходе вообще. Например я думаю что использование пхп и mysql для учета уников в связках не целесообразно. Опять же большинство сплойтов имеет смысл сделать статичными и по крону перекриптовывать\обфусцировать.

В угоду простоте и ленности большинство программистов не включают в свой софт поддержку многих возможностей ОС и установленного ПО. Очень жаль что так.

А собственно написание своих программ-бинарников cgi позволяет разобраться не только в особенностя протоколов и функционирования системы, но и с тем что уже наделано умными людьми для нас совершенно бесплатно, стоит только руку протянуть и потрать время на изучение.

 

[Ar3s]

а кто мешает скрестить связку и tds? В сутре делать редирект в зависимости от ОС/браузера/js на статичные страницы с сплоитами? Вспомните китайскую связку на чистом html+js. Даже статы небыло.
Вот тебе и сумасшедший прирост производительности за счет НЕиспользования SQL и отсев на уровне TDS неуников.

 

[GOONER]

А что мешает вместо MYSQL использовать какую-небудь key-value db(например Redis)?

 

[TrueUser]

Да по большому счету для отсеивания уников можно пользоваться возможностями системы, ДБ никчему просто не очень удобно, но супербыстро при этом