RSDN
 

Rebus83:
По поводу одинаковой скорости perl и php не согласен. В свое время, мы проводили тестирование различных opensource CMS (с примерно одинаковой функциональностью), написанных на perl и php в разных условиях (использовались CGI, mod_perl/mod_php, zend optimizer (вместе и вместо mod_php). Общий вывод: приложения на Perl существенно быстрее. Разница может достигать 3-4 раз в некоторых условиях.
Честно говоря, было это довольно давно, поэтому деталей уже не помню.
Вкратце — задача была, выбрать наиболее приемлимую open source CMS для одного проекта, причем производительность была одним из главных критериев. ASP не рассматривался, по причине иной платформы (нужен был Linux). Выбрали несколько подходящих по возможностям CMS (бОльшая часть была на PHP, но на Perl было тоже несколько вариантов). Затем я установил выбранные системы к себе на машину, и попробовал измерить производительность на типовых операциях с CMS. Тестировали пропускную способность сервера (число запросов в секунду, скорость отдачи страничек) на типичных для сложной CMS операциях: обслуживание главной страницы с большим количеством динамического контента, выдача "типичного" форумного треда с n иерархических записей, выдача списка статей на заданную тему, правка статьи, и прочее. Понятно, что подобные тесты мало говорят о производительности собственно платформы, а гораздо больше о мастерстве авторов CMS, но нас интересовал как-раз выбор готового продукта, а не теоретические возможности платформы. Выбранная нами CMS (написанная на Perl) одержала ОЧЕНЬ убедительную победу над конкурентами — разница в производительности в некоторых случаях достигала 4-5 и более раз. Ни одна из систем на PHP даже близко не приблизилась к результатам победителя.
Впрочем, потом, уже из чистого любопытства были сделаны несколько тестовых скриптов на perl и PHP сложностью не очень превосходящие "Hello, world": выдача простой тестовой странички на HTML, сбор строки в цикле, работа с хешами и массивами. На моей машине в некоторых тестах PHP и Perl были практически наравне, в других Perl резко опережал PHP (особенно запомнилась разница при работе с массивами).
В процессе тестирования использовались: Linux Fedora Core 4, Apache 2, MySQL 5, Perl 5.8, PHP 5, mod_perl и mod_php — из дистрибутива. Также скачал и установил с сайта Zend Optimizer, поскольку, по имеющейся информации, он мог дать существенный прирост производительности по сравнению с mod_perl. Уж очень существенного прироста, честно говоря не наблюдалось, хотя он был. Машина: Pentium D, 1GB RAM, hdd SATA: 120 GB
Как уже ранее заметил Sheridan, здесь важнее не язык, а организация. Придумаете простые и удобные правила коммита, деплоя модулей, продумаете архитектуру — будет вам Щасте.
 

cadet354:
в данный момент все зависит от рук, в вопросах безопасности надо конечно быть немного параноиком и можно предположить что MS делает закладки в своих продуктах,решать вам.
Но человеческий фактор гораздо слабее звено чем техническая часть.
в свое время я видел много сравнений(ссылки тоже не покажу ) из которых следовало, что NET+MSSQL заметно быстрее чем java+mssql, и чуть быстрее чем java+oracle
Во еще вспомнил, в блоге Гайдара (ник Gollum) он переводил свои приложения с php на .net, скорость была выше,
но когда в качестве субд были выбраны текстовые файлы php обогнал кажется net.
Это я к тому что выбор платформы надо делать вместе с выбором CУБД (это кроме тех случаем когда будете пользоваться ORM, которые в большинстве случаев скорость уровняют).
0. Платформа, доступ ко всему .NET, как реализовывать например remouting на PHP вообще не понятно.
С другой стороны оно может сейчас и не надо сейчас, но когда понадобится, что делать-то будете, строить связки PHP с тем же .NET ?
1. Скорость разработки( в это включаю с отладку(с возможностью удаленной отладки), и поддержку в дальнейшем проекта), MSDN.
2. Сам язык(С# или VB.NET) гораздо лучше чем php4(php5 лучше чем php4, но к моменту выбора он только из беты вышел).
3. Контролы для UI, как встроенные так и сторонние.
4. Найти грамотного разработчика на .NET легче чем грамотного на PHP, это я знаю не понаслышке.
Мое мнение: 80% разработчиков для ASP.NET грамотнее, чем 80% разработчиков на PHP
Если выберите linux, посмотрите еще в строну java как альтернативу PHP и Perl.
Практически все что сказано мною про net относится и к java, плюс у java большое количество хороших библиотек, они есть и в net, но они не так хороши (например сравнить Hibernate и Nhibernate).

 

Sheridan:
Выбор стоит делать между asp и php, тк редко попадаются даже perl программеры. Я знаю только одного.
Винда при протирании тряпочкой довольно хорошо работает. Линух само собой. Но линух гибче и производительней сам по себе. Особенно если тряпочкой протирать
Опять-же основное — админ и программеры. Но тут еще вопрос в софте — если с апачем мы имеем представление о багах, о их вычищении итд из багтрака, то с аспом мы можем делать выводы лиш косвенные. Мало ли что МСовцы пишут на сайте. Кода то не видно...
Мне так и не дали тестовый скрипт для asp чтобы я его переписал на php и погонял. Я за php.
Обязательно продумать архитектуру, ну и репозиторий само собой завести надо. И еще лучше не терять разработчиков.
Я так понял проект из 2х частей. Первая часть гуляет по сети и собирает инфу, вторая это дело показывает... Если все крупно, то и по железу надо это дело разнести. 1 сервер собирает, второй бд держит, третий www. Разнос сервисов по компам кстати увеличит надежность.
имхо сбор инфы лучше сделать на с++ или на перле. Отображение — пхп или асп.
Имхо всетаки изначально разносить проект на 2 подпроекта. Пусть даже они на 1 компе будут крутится.
все дело в логике работы. Собирающая часть должна пускаться либо по таймеру либо по запросу. По таймеру это для зарегестрированных динамическмх сервисов, по запросу — для собственно регистрации. Где оно будет собирать инфу это уже другой вопрос, предполагаю будет парсинк страниц, вычленение ссылок, проверки по БД, работа со стрелками для роботов в корне сайта либо просто попытка идти по сайту с корня... Для этого нужна можная машина, и желательно имхо хотябы для каждого сайта запускать отдельный процесс/поток дабы несколько процессоров не были заняты ерундой. В идеале конечно я бы предположил что собирающая софтина это программка, принимающая на вход адрес сайта, перекапывающая его вдоль и поперек и выгружающаяся. Такой подход вдобавок имхо может снять проблемы с утечкой памяти. Да и под лялихом это один из стандартных подходов. Но в этом случае понадобится так сказать "надзиратель" — следящий процесс, если необходимо будет всетаки запускать скан сайта по шедулеру. Тут в принципе можно обойтись и скриптом, но лучше всетаки именно на компилируемом языке писать, как и сканер. Быстрее будет.
WWW собственно это совершенно другой сервис, он должен уметь только показывать и оставлять так сказать заявки на сканирование.
В итоге у нас получается что... А получается что сложный проект разбит на 3 менее сложных: сканирование, шедулер и веб сервер.
Ну и БД само собой... БД кстати следует делать обдуманно, не просто накидать кучу полей в кучу таблиц а подумать как это можно более так сказать правильно сделать, потому как со временем имхо основные тормоза это будут операции с БД...