Здравствуйте, rss354, Вы писали:

R>Выбор платформы для написания веб-сервисов (главные критерии: надежность, масштабируемость, скорость) – помогите определиться с выбором платформы

R>Помогите определиться с выбором платформы.

R>Из кандидатов:
R>1. Perl
R>2. PHP
R>3. ASP (ASP .NET)
R>4. Ruby, Python (другие?)...

R>skip
C++ однозначно, потом Python, PHP

Здравствуйте, rss354, Вы писали:

R>А что делали приложения? Какого рода были тесты?
R>К примеру это была обработка текста, формирование объемного контента, выборка из базы...

R>Можно немного подробней?

Честно говоря, было это довольно давно, поэтому деталей уже не помню.

Вкратце — задача была, выбрать наиболее приемлимую 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

Здравствуйте, rss354, Вы писали:

R>Главное:
R>1. Запросы данных (http и https).
есть
R>2. Парсинг html и xml.
есть
R>3. Юникод.
есть
R>4. Работа с базой (MySQL или Postgree, может просто хранилище).
есть, хотя я на своей домашней странице без БД прекрассно обхожусь.

Все в стандартном наборе насколько я помню...

S>>Обязательно продумать архитектуру, ну и репозиторий само собой завести надо. И еще лучше не терять разработчиков.
R>Архитектура — обязательно. Репозиторий — тоже. Насчет разработчиков — согласен, но идеала трудно достичь
Если несколько человек пишут 1 проект то имхо репозиторий обязателен.

S>>Я так понял проект из 2х частей. Первая часть гуляет по сети и собирает инфу, вторая это дело показывает... Если все крупно, то и по железу надо это дело разнести. 1 сервер собирает, второй бд держит, третий www. Разнос сервисов по компам кстати увеличит надежность.

R>Да, так и есть. Насчет чтобы разнести — тоже такие мысли изначально были — все зависит от популярности сервиса.
Согласен.

R>Возможно сначала лучше сделать тестовый вариант, а не закладываться изначально "сделать по хорошему" — иначе долго делаться будет.
Имхо всетаки изначально разносить проект на 2 подпроекта. Пусть даже они на 1 компе будут крутится.
все дело в логике работы. Собирающая часть должна пускаться либо по таймеру либо по запросу. По таймеру это для зарегестрированных динамическмх сервисов, по запросу — для собственно регистрации. Где оно будет собирать инфу это уже другой вопрос, предполагаю будет парсинк страниц, вычленение ссылок, проверки по БД, работа со стрелками для роботов в корне сайта либо просто попытка идти по сайту с корня... Для этого нужна можная машина, и желательно имхо хотябы для каждого сайта запускать отдельный процесс/поток дабы несколько процессоров не были заняты ерундой. В идеале конечно я бы предположил что собирающая софтина это программка, принимающая на вход адрес сайта, перекапывающая его вдоль и поперек и выгружающаяся. Такой подход вдобавок имхо может снять проблемы с утечкой памяти. Да и под лялихом это один из стандартных подходов. Но в этом случае понадобится так сказать "надзиратель" — следящий процесс, если необходимо будет всетаки запускать скан сайта по шедулеру. Тут в принципе можно обойтись и скриптом, но лучше всетаки именно на компилируемом языке писать, как и сканер. Быстрее будет.
WWW собственно это совершенно другой сервис, он должен уметь только показывать и оставлять так сказать заявки на сканирование.
В итоге у нас получается что... А получается что сложный проект разбит на 3 менее сложных: сканирование, шедулер и веб сервер.
Ну и БД само собой... БД кстати следует делать обдуманно, не просто накидать кучу полей в кучу таблиц а подумать как это можно более так сказать правильно сделать, потому как со временем имхо основные тормоза это будут операции с БД...

Здравствуйте, rss354, Вы писали:

R>Здравствуйте, Sheridan, Вы писали:

R>>>5. Наличие готовых стандартных библиотек "на все случаи жизни" (обработка XML, юникод и т.д.).
S>>asp пользует дотнет, у php тоже дофига всякого есть. Что надо?

Для Perl:
R>Главное:
R>1. Запросы данных (http и https).
LWP, CURL на выбор.
R>2. Парсинг html и xml.
Опять на выбор, десяток парсеров XML. С HTML — скромнее, но, пара найдется. Это, конечно, не считая регекспов.
R>3. Юникод.
Полностью поддерживается, внутреннее представление строк: UTF-8.
R>4. Работа с базой (MySQL или Postgree, может просто хранилище).
DBI.

R>>>Как здесь обстоит дело? Если исходить из того, что это будет не пара скриптов, а система, которую будет разрабатывать команда (около 5-10 человек) в течении минимум полугода и потом она будет активно развиваться — что в этом случае предпочтительней?
Как уже ранее заметил Sheridan, здесь важнее не язык, а организация. Придумаете простые и удобные правила коммита, деплоя модулей, продумаете архитектуру — будет вам Щасте.

R>>>Если более конкретизировать задачу — то это будет что-то типа мета-поисковика (сбор информации из разных сайтов, парсинг и занесение в базу, отображение результатов пользователю по поисковому запросу).
S>>Я так понял проект из 2х частей. Первая часть гуляет по сети и собирает инфу, вторая это дело показывает... Если все крупно, то и по железу надо это дело разнести. 1 сервер собирает, второй бд держит, третий www. Разнос сервисов по компам кстати увеличит надежность.
+1, но зависит от обстоятельств (нагрузка, серверное железо, итд). В некоторых случаях, объединение, скажем, сервера БД и сервера приложений может заметно увеличить производительность за счет исключения сетевых задержек.

Здравствуйте, rss354, Вы писали:


R>Естественно, много чего зависит от рук — в том же PHP к примеру.
в данный момент все зависит от рук, в вопросах безопасности надо конечно быть немного параноиком и можно предположить что MS делает закладки в своих продуктах,решать вам.
Но человеческий фактор гораздо слабее звено чем техническая часть.

C>>а что будет у тебя больше, да и вообще какая база данных?

R>Скорее всего MySQL или PostgreeSQL. Или какое-то более специфическое хранилище.
R>Это в случае Linux, а если Windows — то MSSQL.
в свое время я видел много сравнений(ссылки тоже не покажу ) из которых следовало, что NET+MSSQL заметно быстрее чем java+mssql, и чуть быстрее чем java+oracle
Во еще вспомнил, в блоге Гайдара (ник Gollum) он переводил свои приложения с php на .net, скорость была выше,
но когда в качестве субд были выбраны текстовые файлы php обогнал кажется net.
Это я к тому что выбор платформы надо делать вместе с выбором CУБД (это кроме тех случаем когда будете пользоваться ORM, которые в большинстве случаев скорость уровняют).
R>>>Если был опыт в разработке крупных систем (пусть они совсем не похожи на мета-поиск) — какие возникали проблемы, насколько они хорошо решались на разных платформах? В пользу чего в итоге был сделан выбор? По каким соображениям и критериям?

R>Почему? Т.е. какие факторы стали для вас определяющими в выборе?
0. Платформа, доступ ко всему .NET, как реализовывать например remouting на PHP вообще не понятно.
С другой стороны оно может сейчас и не надо сейчас, но когда понадобится, что делать-то будете, строить связки PHP с тем же .NET ?
1. Скорость разработки( в это включаю с отладку(с возможностью удаленной отладки), и поддержку в дальнейшем проекта), MSDN.
2. Сам язык(С# или VB.NET) гораздо лучше чем php4(php5 лучше чем php4, но к моменту выбора он только из беты вышел).
3. Контролы для UI, как встроенные так и сторонние.
4. Найти грамотного разработчика на .NET легче чем грамотного на PHP, это я знаю не понаслышке.
Мое мнение: 80% разработчиков для ASP.NET грамотнее, чем 80% разработчиков на PHP
R>Спасибо!
Если выберите linux, посмотрите еще в строну java как альтернативу PHP и Perl.
Практически все что сказано мною про net относится и к java, плюс у java большое количество хороших библиотек, они есть и в net, но они не так хороши (например сравнить Hibernate и Nhibernate).

Здравствуйте, rss354, Вы писали:

R>Из кандидатов:
R>1. Perl
R>2. PHP
R>3. ASP (ASP .NET)
R>4. Ruby, Python (другие?)...
Выбор стоит делать между asp и php, тк редко попадаются даже perl программеры. Я знаю только одного.

R>Если составить базовый список критериев, то получится:
R>1. Надежность (99,999%)
Это в любом случае криворукость админа и программеров. Винда при протирании тряпочкой довольно хорошо работает. Линух само собой. Но линух гибче и производительней сам по себе. Особенно если тряпочкой протирать

R>и безопасность.
Опять-же основное — админ и программеры. Но тут еще вопрос в софте — если с апачем мы имеем представление о багах, о их вычищении итд из багтрака, то с аспом мы можем делать выводы лиш косвенные. Мало ли что МСовцы пишут на сайте. Кода то не видно...

R>2. Масштабируемость.
имхо в обоих случаях освояемо.

R>3. Скорость.
По этому поводу в СВ было много споров. Мне так и не дали тестовый скрипт для asp чтобы я его переписал на php и погонял. Я за php.

R>4. Работа с большими нагрузками – большие объемы трафика, большое количество одновременно работающих пользователей.
Через стенку у меня сидит админ. У него шабашка есть — поддерживает пару веб серваков линух + апач + php. Средняя нагрузка 500 запросов в секунду. Влет.

R>4. Что здесь предпочтительней? Платформа на основе PHP/Perl или на основе ASP?
Имхо всетаки линукс+пхп. Гибче.

R>1. Скорость написания кода.
Зависит от программистов.

R>2. Удобство отладки.
Насколько я понимаю — в обоих случаях тестовые echo

R>3. Сопровождение кода (тем-же или другим человеком).
Опятьже зависит от человека.

R>4. Расширение функциональности действующей системы.
Зависит от архитектуры проекта.

R>5. Наличие готовых стандартных библиотек "на все случаи жизни" (обработка XML, юникод и т.д.).
asp пользует дотнет, у php тоже дофига всякого есть. Что надо?

R>... вообщем полный цикл поддержки системы.
Сложного и там и там мало. Зависит от персонала.

R>Как здесь обстоит дело? Если исходить из того, что это будет не пара скриптов, а система, которую будет разрабатывать команда (около 5-10 человек) в течении минимум полугода и потом она будет активно развиваться — что в этом случае предпочтительней?
Обязательно продумать архитектуру, ну и репозиторий само собой завести надо. И еще лучше не терять разработчиков.

R>Если более конкретизировать задачу — то это будет что-то типа мета-поисковика (сбор информации из разных сайтов, парсинг и занесение в базу, отображение результатов пользователю по поисковому запросу).
Я так понял проект из 2х частей. Первая часть гуляет по сети и собирает инфу, вторая это дело показывает... Если все крупно, то и по железу надо это дело разнести. 1 сервер собирает, второй бд держит, третий www. Разнос сервисов по компам кстати увеличит надежность.
имхо сбор инфы лучше сделать на с++ или на перле. Отображение — пхп или асп.

Здравствуйте, cadet354, Вы писали:

C>конечно нет, а как ты думаешь как получаются данные из БД для маппинга.
Тогда не вижу разницы между этим и стандартным способом, кроме тормозов.

S>>От того что сахар назвать не белым, а рассыпчатым, его сладость не изменится.
S>>В чем сложность написания данного дела? Чем оно отличается от обычной страницы? Тем, что не браузером открывается?
C>тем что он ориентирован не на браузер, а на код.
C>Например, тебе надо получить курс валют, ты можешь скачать страничку с курсом, распарсить и вывести(и тут на сайте поменяли дизайн, приходится заново переписывать парсер), или вызвать веб сервис, который тебе вернет xml с этими курсами который потом автоматически (в теории) преобразуется в твои классы.

Я уже говорил про сахар. Повторить фразу с перцем в главной роли?
Со стороны сервера какие различия? Правильно, никаких. И для этого нужен специальный камаз?

Выбор платформы для написания веб-сервисов (главные критерии: надежность, масштабируемость, скорость) – помогите определиться с выбором платформы

Помогите определиться с выбором платформы.

Из кандидатов:
1. Perl
2. PHP
3. ASP (ASP .NET)
4. Ruby, Python (другие?)...

Для написания небольших задач — наверное что лучше знаешь и что больше нравится — то и выбирай.
По крайней мере для небольшой задачи я бы так и сделал
А что лучше выбрать при больших нагрузках (исходим из того, что сервер свой и поставить туда можно что угодно)?

Если составить базовый список критериев, то получится:
1. Надежность (99,999%) и безопасность.
2. Масштабируемость.
3. Скорость.
4. Работа с большими нагрузками – большие объемы трафика, большое количество одновременно работающих пользователей.

По результатам поиска в интернете получается:
1. Самый надежный и безопасный — Perl. Следом — ASP, потом PHP (с безопасностью для него ситуация вроде довольно быстро меняется в лучшую сторону – благодаря PHP Security Consortium).
2. По масштабируемости — неясно. PHP активно используют крупные компании – к примеру Yahoo и JupiterMedia (http://www.citnews.ru/news/341/), про ASP встречал упоминания eBay.com. Идеальный вариант — чтобы в случае большой нагрузки можно было просто добавить новый сервер с минимальным переконфигурированием. Что в этом случае лучше?
3. По скорости — получается что Perl и PHP приблизительно одинаковы при использовании mod_perl и mod_php. А как в случае использования ASP .NET? Если разделить задачи на расчетные (скажем формирование контента) и выборки/занесения данных из базы?
4. Что здесь предпочтительней? Платформа на основе PHP/Perl или на основе ASP?


Конечно есть и другие не менее важные критерии:
1. Скорость написания кода.
2. Удобство отладки.
3. Сопровождение кода (тем-же или другим человеком).
4. Расширение функциональности действующей системы.
5. Наличие готовых стандартных библиотек "на все случаи жизни" (обработка XML, юникод и т.д.).

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

Как здесь обстоит дело? Если исходить из того, что это будет не пара скриптов, а система, которую будет разрабатывать команда (около 5-10 человек) в течении минимум полугода и потом она будет активно развиваться — что в этом случае предпочтительней?

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

Поделитесь пожалуйста вашим личным опытом — он самый ценный!
Если был опыт в разработке крупных систем (пусть они совсем не похожи на мета-поиск) — какие возникали проблемы, насколько они хорошо решались на разных платформах? В пользу чего в итоге был сделан выбор? По каким соображениям и критериям?

Спасибо за ответы!

P.S. Буду также благодарен за ссылки на статьи, обсуждения в форумах, проясняющие вопрос — возможно я что-то упустил при поиске информации.

Мой e-mail для приватных сообщений — rss354_собака_rambler_точка_ru

Здравствуйте, rss354, Вы писали:

R>Выбор платформы для написания веб-сервисов (главные критерии: надежность, масштабируемость, скорость) – помогите определиться с выбором платформы

R>Помогите определиться с выбором платформы.

R>Из кандидатов:
R>1. Perl
R>2. PHP
R>3. ASP (ASP .NET)
R>4. Ruby, Python (другие?)...

R>Для написания небольших задач — наверное что лучше знаешь и что больше нравится — то и выбирай.
R>По крайней мере для небольшой задачи я бы так и сделал
R>А что лучше выбрать при больших нагрузках (исходим из того, что сервер свой и поставить туда можно что угодно)?

R>Если составить базовый список критериев, то получится:
R>1. Надежность (99,999%) и безопасность.
R>2. Масштабируемость.
R>3. Скорость.
R>4. Работа с большими нагрузками – большие объемы трафика, большое количество одновременно работающих пользователей.

R>По результатам поиска в интернете получается:
R>1. Самый надежный и безопасный — Perl. Следом — ASP, потом PHP (с безопасностью для него ситуация вроде довольно быстро меняется в лучшую сторону – благодаря PHP Security Consortium).
R>2. По масштабируемости — неясно. PHP активно используют крупные компании – к примеру Yahoo и JupiterMedia (http://www.citnews.ru/news/341/), про ASP встречал упоминания eBay.com. Идеальный вариант — чтобы в случае большой нагрузки можно было просто добавить новый сервер с минимальным переконфигурированием. Что в этом случае лучше?
R>3. По скорости — получается что Perl и PHP приблизительно одинаковы при использовании mod_perl и mod_php. А как в случае использования ASP .NET? Если разделить задачи на расчетные (скажем формирование контента) и выборки/занесения данных из базы?
R>4. Что здесь предпочтительней? Платформа на основе PHP/Perl или на основе ASP?

По поводу одинаковой скорости perl и php не согласен. В свое время, мы проводили тестирование различных opensource CMS (с примерно одинаковой функциональностью), написанных на perl и php в разных условиях (использовались CGI, mod_perl/mod_php, zend optimizer (вместе и вместо mod_php). Общий вывод: приложения на Perl существенно быстрее. Разница может достигать 3-4 раз в некоторых условиях.

Здравствуйте, XPGeeK, Вы писали:

R>>Помогите определиться с выбором платформы.

R>>Из кандидатов:
R>>1. Perl
R>>2. PHP
R>>3. ASP (ASP .NET)
R>>4. Ruby, Python (другие?)...

R>>skip
XPG>C++ однозначно, потом Python, PHP

Как лучше обосновать? Т.е. почему именно C++. Насчет скорости — понятно. Насчет безопасности? Сопровождения?

Чем Python в данном случае предпочтительней PHP (не ради флейма — интересно ваше личное мнение).

Спасибо!

Здравствуйте, Rebus83, Вы писали:

R> По поводу одинаковой скорости perl и php не согласен. В свое время, мы проводили тестирование различных opensource CMS (с примерно одинаковой функциональностью), написанных на perl и php в разных условиях (использовались CGI, mod_perl/mod_php, zend optimizer (вместе и вместо mod_php). Общий вывод: приложения на Perl существенно быстрее. Разница может достигать 3-4 раз в некоторых условиях.

А что делали приложения? Какого рода были тесты?
К примеру это была обработка текста, формирование объемного контента, выборка из базы...

Можно немного подробней?

Спасибо!

Здравствуйте, Rebus83, Вы писали:

R>Здравствуйте, rss354, Вы писали:

R>>А что делали приложения? Какого рода были тесты?
R>>К примеру это была обработка текста, формирование объемного контента, выборка из базы...

R>>Можно немного подробней?

R>Честно говоря, было это довольно давно, поэтому деталей уже не помню.

R>Вкратце — задача была, выбрать наиболее приемлимую open source CMS для одного проекта, причем производительность была одним из главных критериев. ASP не рассматривался, по причине иной платформы (нужен был Linux). Выбрали несколько подходящих по возможностям CMS (бОльшая часть была на PHP, но на Perl было тоже несколько вариантов). Затем я установил выбранные системы к себе на машину, и попробовал измерить производительность на типовых операциях с CMS. Тестировали пропускную способность сервера (число запросов в секунду, скорость отдачи страничек) на типичных для сложной CMS операциях: обслуживание главной страницы с большим количеством динамического контента, выдача "типичного" форумного треда с n иерархических записей, выдача списка статей на заданную тему, правка статьи, и прочее. Понятно, что подобные тесты мало говорят о производительности собственно платформы, а гораздо больше о мастерстве авторов CMS, но нас интересовал как-раз выбор готового продукта, а не теоретические возможности платформы. Выбранная нами CMS (написанная на Perl) одержала ОЧЕНЬ убедительную победу над конкурентами — разница в производительности в некоторых случаях достигала 4-5 и более раз. Ни одна из систем на PHP даже близко не приблизилась к результатам победителя.

R>Впрочем, потом, уже из чистого любопытства были сделаны несколько тестовых скриптов на perl и PHP сложностью не очень превосходящие "Hello, world": выдача простой тестовой странички на HTML, сбор строки в цикле, работа с хешами и массивами. На моей машине в некоторых тестах PHP и Perl были практически наравне, в других Perl резко опережал PHP (особенно запомнилась разница при работе с массивами).

R>В процессе тестирования использовались: 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

Тетировние сделанное недавно PHP vs Perl.

Возникла мысль сделать некий сборник мнений разных авторов — и выложить его в свободный доступ.
Думаю не я первый и не я последний интересуюсь этой темой — а так уже будет готов небольшой сборник мнений на эту тему.
Я думаю это будет очень полезная вещь — поскольку здесь будет показан опыт нескольких авторов, который высказывает именно свои соображения исходя из своего опыта, а не понаслышке.
Ну а мне в свою очередь хочется сделать полезное сетевому сообществу.

Что для этого нужно — просто высказать свое мнение. Приблизительная табличка (это мое мнение) — во вложении.
Лучше все содержание стереть, и заполнить своим. Это не обязательно будет табличка. Вообще пишете то, что считаете нужным (с чем вы сталкивались).

Я очень надеюсь что инициатива найдет поддержку с вашей стороны — с моей стороны — я буду "склеивать" ваши мнения, потом всю информацию оформлю и выложу в открытый доступ.
Кто публиковал свои мнения — я включу ваши мнения в документ. Если есть уточнения или возражения — высказывайте, я их учту.

Ключевые моменты:
1. Тема "Выбор платформы для веб на основе С++, Java, PHP, Perl, ASP" (возможны другие языки).
2. Каждый пишет только то, что считает нужным (т.е. нет задачи описать все). Это может быть просто пару абзацев о вашем инструменте и о опыте использования.
3. Это ваше субъективное мнение. Задача читателя — сформировать свое объективное мнение.
4. Напишите также кратко кто вы и чем занимаетесь и откуда. Cвоеобразная реклама авторам в благодарность за потраченное время

Очень надеюсь что инициатива не заглохнет и документ появится и будет полезен всем.
В своем роде это будет уникальный документ — _практическое_ мнение _разных_ участников.

Можно отвечать в форуме, или если удобней — то на мою почту (rss354_собака_rambler_точка_ru) — я обязательно пришлю подверждение о получении письма.

Само вложение http://www.rsdn.ru:80/File/57981/Comparison.doc — в предыдущем письме забыл

Здравствуйте, XPGeeK, Вы писали:

XPG>Тетировние сделанное недавно PHP vs Perl.

Я посмотрел скрипты, которыми человек пользовался при тестировании. Этот тест не стоит того места на сайте, которое он занимает. Под mod_perl ТАК — HTML test code, и ТАК — MySQL test code не пишут!!!

Особенно ржал от строчки:

I performed no tuning on any component of the LAMP stack as delivered from Red Hat. In a hosted environment, being able to change system components is a rare luxury.

Этот чудак (здесь должно быть другое слово) не понимает в программировании под mod_perl ничерта. Кстати, в комментах к оригиналу теста об этом сказано.

As someone who uses mod_perl professionally, I'm disappointed to say that your testing methodology is all wrong. Though I doubt that you've done so intentionally, you have used mod_perl in a way that is (a) not recommended and (b) does not take advantage of mod_perl's performance potential.

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

No matter where and what the performance advantage is, PHP will be the choice for many. Perl has number of advantages over PHP, but it is not easy to learn, even for developers with experience in other languages.

Здравствуйте, rss354, Вы писали:

ну еще есть java.
R>По результатам поиска в интернете получается:
R>1. Самый надежный и безопасный — Perl.
дайте ссылки, где про это пишут.
R> Следом — ASP, потом PHP (с безопасностью для него ситуация вроде довольно быстро меняется в лучшую сторону – благодаря PHP Security Consortium).
R>2. По масштабируемости — неясно. PHP активно используют крупные компании – к примеру Yahoo и JupiterMedia (http://www.citnews.ru/news/341/), про ASP встречал упоминания eBay.com.
а майкрософт, что уже не крупная компания?
R> Идеальный вариант — чтобы в случае большой нагрузки можно было просто добавить новый сервер с минимальным переконфигурированием. Что в этом случае лучше?
R>3. По скорости — получается что Perl и PHP приблизительно одинаковы при использовании mod_perl и mod_php. А как в случае использования ASP .NET? Если разделить задачи на расчетные (скажем формирование контента) и выборки/занесения данных из базы?
а что будет у тебя больше, да и вообще какая база данных?
R>4. Что здесь предпочтительней? Платформа на основе PHP/Perl или на основе ASP?


R>Как здесь обстоит дело? Если исходить из того, что это будет не пара скриптов, а система, которую будет разрабатывать команда (около 5-10 человек) в течении минимум полугода и потом она будет активно развиваться — что в этом случае предпочтительней?
а что разработчики знают или только будет подбираться команда?
Найти команду из 5-10 разработчиков на python будет ИМНО весьма сложно.
R>Понятно, что в целом ответы зависят от того что нужно сделать.
R>Если более конкретизировать задачу — то это будет что-то типа мета-поисковика (сбор информации из разных сайтов, парсинг и занесение в базу, отображение результатов пользователю по поисковому запросу).

R>Поделитесь пожалуйста вашим личным опытом — он самый ценный!
R>Если был опыт в разработке крупных систем (пусть они совсем не похожи на мета-поиск) — какие возникали проблемы, насколько они хорошо решались на разных платформах? В пользу чего в итоге был сделан выбор? По каким соображениям и критериям?
Я могу сравнить только PHP и ASP.NET(из личного опыта), я бы посоветовал ASP.NET

Здравствуйте, cadet354, Вы писали:

R>>2. По масштабируемости — неясно. PHP активно используют крупные компании – к примеру Yahoo и JupiterMedia (http://www.citnews.ru/news/341/), про ASP встречал упоминания eBay.com.
C>а майкрософт, что уже не крупная компания?
Я был бы удивлен если бы МС использовала не асп

Здравствуйте, Sheridan, Вы писали:

S>Опять-же основное — админ и программеры. Но тут еще вопрос в софте — если с апачем мы имеем представление о багах, о их вычищении итд из багтрака, то с аспом мы можем делать выводы лиш косвенные. Мало ли что МСовцы пишут на сайте. Кода то не видно...
можно пойти впереди европы всей и ASP.NET закрутить на Mono
тогда код будет виден, но где найти на наших просторах людей которые в нем разбирутся?
R>>2. Удобство отладки.
S>Насколько я понимаю — в обоих случаях тестовые echo
можно поставить remotdebug в ASP.NET, а это гораздо лучше чем тестовые echo

R>>5. Наличие готовых стандартных библиотек "на все случаи жизни" (обработка XML, юникод и т.д.).
S>asp пользует дотнет, у php тоже дофига всякого есть. Что надо?
есть то много, но качество у большинства в свое время юзал довольно много библиотек с PEAR(единственно, что не вызвало нареканий это ADODB, а так практически во все приходилось залазить,хотя бы чтоб понять как это работает, документации вообще кот наплакал) , с веб-сервисами работал с помощью NuSOAP(там вообще напильником очень много было чего).
Но может за полгода изменилось, мой опыт основывается на 4 версии.
По качеству и количеству библиотек ИМНО рулит java, но найти 5-10 разработчиков так же не фонтан (но отсюда бюджет не виден).

Здравствуйте, cadet354, Вы писали:

C>Здравствуйте, Sheridan, Вы писали:

S>>Опять-же основное — админ и программеры. Но тут еще вопрос в софте — если с апачем мы имеем представление о багах, о их вычищении итд из багтрака, то с аспом мы можем делать выводы лиш косвенные. Мало ли что МСовцы пишут на сайте. Кода то не видно...
C>можно пойти впереди европы всей и ASP.NET закрутить на Mono
C>тогда код будет виден, но где найти на наших просторах людей которые в нем разбирутся?
mono это жалкое подобие левой руки. Мне стыдно даже за линух...

R>>>5. Наличие готовых стандартных библиотек "на все случаи жизни" (обработка XML, юникод и т.д.).
S>>asp пользует дотнет, у php тоже дофига всякого есть. Что надо?
C>есть то много, но качество у большинства в свое время юзал довольно много библиотек с PEAR(единственно, что не вызвало нареканий это ADODB, а так практически во все приходилось залазить,хотя бы чтоб понять как это работает, документации вообще кот наплакал) , с веб-сервисами работал с помощью NuSOAP(там вообще напильником очень много было чего).

Насчет "библиотек"...
Что нужно было из PEAR? Что такое вообще SOAP? Зачем?

Здравствуйте, Sheridan, Вы писали:


S>mono это жалкое подобие левой руки. Мне стыдно даже за линух...

S>Насчет "библиотек"...
S>Что нужно было из PEAR?
на память:
доступ к БД, логирование&bench(это кстати тоже не вызвало нареканий),
отправка почты(организация очередей отправки и т.д.),
написание в excel под unix(генерация прайсов ),
ORM,
phpunit.
S>Что такое вообще SOAP? Зачем?
веб сервисы это иногда web service

Здравствуйте, cadet354, Вы писали:

C>Здравствуйте, Sheridan, Вы писали:


S>>mono это жалкое подобие левой руки. Мне стыдно даже за линух...

S>>Насчет "библиотек"...
S>>Что нужно было из PEAR?
C>на память:
C>доступ к БД, логирование&bench(это кстати тоже не вызвало нареканий),
Пишется руками под свои нужды за денек.

C>отправка почты(организация очередей отправки и т.д.),
За пару часов имхо, на крайняк денек.

C>написание в excel под unix(генерация прайсов ),
гм... html отменили? обязательно эксель? Дурдом.

C>ORM,
что за зверь?

C>phpunit.
что за зверь?

S>>Что такое вообще SOAP? Зачем?
C>веб сервисы это иногда web service
Что это такое? под вебсервисом я понимаю апач+пхп+сессии.

Здравствуйте, Sheridan, Вы писали:

C>>доступ к БД, логирование&bench(это кстати тоже не вызвало нареканий),
S>Пишется руками под свои нужды за денек.
я не любитель велосипедов.
C>>отправка почты(организация очередей отправки и т.д.),
S>За пару часов имхо, на крайняк денек.

C>>написание в excel под unix(генерация прайсов ),
S>гм... html отменили? обязательно эксель? Дурдом.
заказчик всегда прав.
C>>ORM,
S>что за зверь?
object relation mapping, это грубо говоря когда таблица из БД мапится на класс php.
C>>phpunit.
S>что за зверь?
юнит тесты
S>>>Что такое вообще SOAP? Зачем?
C>>веб сервисы это иногда web service
S>Что это такое? под вебсервисом я понимаю апач+пхп+сессии.
а я понимаю именно web service, пример тут
http://www.rsdn.ru/ws/janus.asmx

Здравствуйте, cadet354, Вы писали:

C>я не любитель велосипедов.
Понимаеш, когда кроме собственно велосипеда внагрузку еще камаз дается на жесткой сцепке это имхо перебор. Уж лучше я без камаза поеду. Оно проще и быстрее будет.

C>заказчик всегда прав.
Заказчик не всегда адекватно представляет необходимость всякого. Может он хочет сортировку любую просто? А если у потенциальных посетителей канал узкий для прайса? Это необходимо обсуждать.

C>object relation mapping, это грубо говоря когда таблица из БД мапится на класс php.
Какой ужас. А какже sql? Боком?

C>юнит тесты
Что это такое? Я тупой, мне надо ражжевывать.

S>>Что это такое? под вебсервисом я понимаю апач+пхп+сессии.
C>а я понимаю именно web service, пример тут
C>http://www.rsdn.ru/ws/janus.asmx
От того что сахар назвать не белым, а рассыпчатым, его сладость не изменится.
В чем сложность написания данного дела? Чем оно отличается от обычной страницы? Тем, что не браузером открывается?

Здравствуйте, Sheridan, Вы писали:

S>Понимаеш, когда кроме собственно велосипеда внагрузку еще камаз дается на жесткой сцепке это имхо перебор. Уж лучше я без камаза поеду. Оно проще и быстрее будет.
проще врядли, а быстрее это экономия на спичках будет(чужой велосипед с умом надо выбирать, а то можно не то, что камаз получить а даже дорожный каток).
C>>заказчик всегда прав.
S>Заказчик не всегда адекватно представляет необходимость всякого. Может он хочет сортировку любую просто? А если у потенциальных посетителей канал узкий для прайса? Это необходимо обсуждать.
ты думаешь это не обсуждалось?
C>>object relation mapping, это грубо говоря когда таблица из БД мапится на класс php.
S>Какой ужас. А какже sql? Боком?
конечно нет, а как ты думаешь как получаются данные из БД для маппинга.
C>>юнит тесты
S>Что это такое? Я тупой, мне надо ражжевывать.
сомневаюсь google поможет, можешь еще погуглить по фразе Test Driven Development.
S>>>Что это такое? под вебсервисом я понимаю апач+пхп+сессии.
C>>а я понимаю именно web service, пример тут
C>>http://www.rsdn.ru/ws/janus.asmx
S>От того что сахар назвать не белым, а рассыпчатым, его сладость не изменится.
S>В чем сложность написания данного дела? Чем оно отличается от обычной страницы? Тем, что не браузером открывается?
тем что он ориентирован не на браузер, а на код.
Например, тебе надо получить курс валют, ты можешь скачать страничку с курсом, распарсить и вывести(и тут на сайте поменяли дизайн, приходится заново переписывать парсер), или вызвать веб сервис, который тебе вернет xml с этими курсами который потом автоматически (в теории) преобразуется в твои классы.

Здравствуйте, Sheridan, Вы писали:

R>>и безопасность.
S>Опять-же основное — админ и программеры. Но тут еще вопрос в софте — если с апачем мы имеем представление о багах, о их вычищении итд из багтрака, то с аспом мы можем делать выводы лиш косвенные. Мало ли что МСовцы пишут на сайте. Кода то не видно...

Исходники .net лежат на сайте MS.

R>>3. Скорость.
S>По этому поводу в СВ было много споров. Мне так и не дали тестовый скрипт для asp чтобы я его переписал на php и погонял. Я за php.

Тестовый скрипт ничего не определяет. Это сферический конь в вакууме. Его можно написать так чтобы он работал отлично или тормозил и там и там. Все зависит от программера.

R>>4. Что здесь предпочтительней? Платформа на основе PHP/Perl или на основе ASP?
S>Имхо всетаки линукс+пхп. Гибче.

Чем гибче-то?

R>>2. Удобство отладки.
S>Насколько я понимаю — в обоих случаях тестовые echo

ээээ??? что? Как это Мне правда жаль людей которые для отладки пользуются тестовым echo.
Мы по старинке — контрольные точки, отладка по шагам, просмотр переменных, параметров, стека вызова и прочего
Про юнит-тесты кстати не забываем

R>>5. Наличие готовых стандартных библиотек "на все случаи жизни" (обработка XML, юникод и т.д.).
S>asp пользует дотнет, у php тоже дофига всякого есть. Что надо?

asp.NET пользует дотнет. asp не использует.

R>>Как здесь обстоит дело? Если исходить из того, что это будет не пара скриптов, а система, которую будет разрабатывать команда (около 5-10 человек) в течении минимум полугода и потом она будет активно развиваться — что в этом случае предпочтительней?
S>Обязательно продумать архитектуру, ну и репозиторий само собой завести надо. И еще лучше не терять разработчиков.

И еще я бы дополнил — документировать исходники. В случае смены программеров — это СИЛЬНО помогает.

Здравствуйте, denisio_mcp, Вы писали:

_>Исходники .net лежат на сайте MS.
Где?

_>Тестовый скрипт ничего не определяет. Это сферический конь в вакууме. Его можно написать так чтобы он работал отлично или тормозил и там и там. Все зависит от программера.
Угу. Только вот сначала виндузятники говорят что асп имеет пхп везде а потом говорят что скрипт писать впадлу, программер крутой попадется или там лунная тень в свете болотного газа....

S>>Имхо всетаки линукс+пхп. Гибче.
_>Чем гибче-то?
Да тем чтоты имееш более полный контроль над машиной.

R>>>2. Удобство отладки.
S>>Насколько я понимаю — в обоих случаях тестовые echo
_>ээээ??? что? Как это Мне правда жаль людей которые для отладки пользуются тестовым echo.
Мне кажется что в любом случае даже в с++ при росте проекта все реже и реже рука тянется к отладке. Как правило делают какойто тестовый выв0д.

_>Мы по старинке — контрольные точки, отладка по шагам, просмотр переменных, параметров, стека вызова и прочего
в аспе???

_>Про юнит-тесты кстати не забываем
Что это?

_>asp.NET пользует дотнет. asp не использует.
Чтото свое есть?

S>>Обязательно продумать архитектуру, ну и репозиторий само собой завести надо. И еще лучше не терять разработчиков.
_>И еще я бы дополнил — документировать исходники. В случае смены программеров — это СИЛЬНО помогает.
Лучше писать самодокументирующийся код.... ну типа переменные называть не s1, gddd, а понятными словами. Ну и конечно в сложных местах комментарии оставлять.

Здравствуйте, Sheridan, Вы писали:

_>>Исходники .net лежат на сайте MS.
S>Где?

первая ссылка в поиске

_>>Тестовый скрипт ничего не определяет. Это сферический конь в вакууме. Его можно написать так чтобы он работал отлично или тормозил и там и там. Все зависит от программера.
S>Угу. Только вот сначала виндузятники говорят что асп имеет пхп везде а потом говорят что скрипт писать впадлу, программер крутой попадется или там лунная тень в свете болотного газа....

Давайте не будем говорить за всех. Меняйте таких программеров.

S>>>Имхо всетаки линукс+пхп. Гибче.
_>>Чем гибче-то?
S>Да тем чтоты имееш более полный контроль над машиной.

А в Windows не имеешь? За последние 5 лет я убедился, что все вопросы категории "подземный стук", "долбаная винда", "чорт знает что она делает" или "опять глючит" сводятся к простому незнанию порой даже принципов функционирования некоторых сервисов. Да и админом щас принято называть человека, который знает что такое загрузочный диск и способен установить винду с него.

R>>>>2. Удобство отладки.
S>>>Насколько я понимаю — в обоих случаях тестовые echo
_>>ээээ??? что? Как это Мне правда жаль людей которые для отладки пользуются тестовым echo.
S>Мне кажется что в любом случае даже в с++ при росте проекта все реже и реже рука тянется к отладке. Как правило делают какойто тестовый выв0д.

_>>Мы по старинке — контрольные точки, отладка по шагам, просмотр переменных, параметров, стека вызова и прочего
S>в аспе???

asp.net — да. Я открыл что-то новое для тебя? Посмотри поподробнее на VS 2005. Она умеет многие приятные вещи, без которых жизнь программера порой печальна

_>>Про юнит-тесты кстати не забываем
S>Что это?

Это автоматизированное средство тестирования твоих модулей. Если вкратце. Если подробно — здесь или здесь

_>>asp.NET пользует дотнет. asp не использует.
S>Чтото свое есть?

это две разные технологии. ASP — скриптовая и интерпретируемая соответственно ISAPI-модулем, ASP.NET — компилируемая.
Скажем так, они друг с другом не связаны никак кроме названия.

S>>>Обязательно продумать архитектуру, ну и репозиторий само собой завести надо. И еще лучше не терять разработчиков.
_>>И еще я бы дополнил — документировать исходники. В случае смены программеров — это СИЛЬНО помогает.
S>Лучше писать самодокументирующийся код.... ну типа переменные называть не s1, gddd, а понятными словами. Ну и конечно в сложных местах комментарии оставлять.

Ну вот в том же VS2005 можно очень удобно документировать код.

Здравствуйте, denisio_mcp, Вы писали:

_>Здравствуйте, Sheridan, Вы писали:

_>>>Исходники .net лежат на сайте MS.
S>>Где?
_>первая ссылка в поиске

Shared Source Common Language Infrastructure 2.0 Release
Brief Description
The Shared Source CLI is a compressed archive of the source code to a working implementation of the ECMA CLI and the ECMA C# language specification. This implementation builds and runs on Windows XP.

Это исходники дотнета?

S>>Угу. Только вот сначала виндузятники говорят что асп имеет пхп везде а потом говорят что скрипт писать впадлу, программер крутой попадется или там лунная тень в свете болотного газа....
_>Давайте не будем говорить за всех. Меняйте таких программеров.
При чем тут замена программера? разговор идет о том что дайте мне скрипт на аспе, я его переделаю в пхп и прогоню.

S>>>>Имхо всетаки линукс+пхп. Гибче.
_>>>Чем гибче-то?
S>>Да тем чтоты имееш более полный контроль над машиной.
_>А в Windows не имеешь? За последние 5 лет я убедился, что все вопросы категории "подземный стук", "долбаная винда", "чорт знает что она делает" или "опять глючит" сводятся к простому незнанию порой даже принципов функционирования некоторых сервисов. Да и админом щас принято называть человека, который знает что такое загрузочный диск и способен установить винду с него.
В винде не имею. Как отключить графический интерфейс сервака, к которому монитор подключается 3 раза в год?

_>>>Мы по старинке — контрольные точки, отладка по шагам, просмотр переменных, параметров, стека вызова и прочего
S>>в аспе???
_>asp.net — да. Я открыл что-то новое для тебя? Посмотри поподробнее на VS 2005. Она умеет многие приятные вещи, без которых жизнь программера порой печальна
Ты думаеш я студии не видел? Посмотри в about януса.
А по линии — гуд конечно что в аспе появилась отладка. Только вот повторю что редко она всеравно пригождается. Особенно для скриптовых языков.

_>>>Про юнит-тесты кстати не забываем
S>>Что это?
_>Это автоматизированное средство тестирования твоих модулей. Если вкратце. Если подробно — здесь или здесь
Автоматика это конечно хорошо, но надо щупать...

_>>>asp.NET пользует дотнет. asp не использует.
S>>Чтото свое есть?
_>это две разные технологии. ASP — скриптовая и интерпретируемая соответственно ISAPI-модулем, ASP.NET — компилируемая.
_>Скажем так, они друг с другом не связаны никак кроме названия.
теперь ясно, спасибо

S>>Лучше писать самодокументирующийся код.... ну типа переменные называть не s1, gddd, а понятными словами. Ну и конечно в сложных местах комментарии оставлять.
_>Ну вот в том же VS2005 можно очень удобно документировать код.
в kdevelop встроено 3 или 4 тулзы для документирования типа как в студии. И что? Если их не пользовать само не задокументируется.

Здравствуйте, cadet354, Вы писали:

R>>1. Самый надежный и безопасный — Perl.
C>дайте ссылки, где про это пишут.

Ссылку не приведу — не подумал сразу сохранить, но смысл (своими словами) был такой:

Perl — есть меченные данные, изначально большое внимание уделялось безопасности.
ASP — технология закрытая, всего не видно, но в целом вполне безопасна.
PHP — только в 2004 году (или 2005 — точно не помню) появилась PHP Security Consortium — дело стало меняться к лучшему.
Естественно, много чего зависит от рук — в том же PHP к примеру.


R>>2. По масштабируемости — неясно. PHP активно используют крупные компании – к примеру Yahoo и JupiterMedia (http://www.citnews.ru/news/341/), про ASP встречал упоминания eBay.com.
C>а майкрософт, что уже не крупная компания?

Я не брал примеры типа microsoft.com и php.net

R>> Идеальный вариант — чтобы в случае большой нагрузки можно было просто добавить новый сервер с минимальным переконфигурированием. Что в этом случае лучше?
R>>3. По скорости — получается что Perl и PHP приблизительно одинаковы при использовании mod_perl и mod_php. А как в случае использования ASP .NET? Если разделить задачи на расчетные (скажем формирование контента) и выборки/занесения данных из базы?
C>а что будет у тебя больше, да и вообще какая база данных?

Скорее всего MySQL или PostgreeSQL. Или какое-то более специфическое хранилище.
Это в случае Linux, а если Windows — то MSSQL.

R>>Если был опыт в разработке крупных систем (пусть они совсем не похожи на мета-поиск) — какие возникали проблемы, насколько они хорошо решались на разных платформах? В пользу чего в итоге был сделан выбор? По каким соображениям и критериям?
C>Я могу сравнить только PHP и ASP.NET(из личного опыта), я бы посоветовал ASP.NET

Почему? Т.е. какие факторы стали для вас определяющими в выборе?

Спасибо!

Здравствуйте, Sheridan, Вы писали:

S>>>Где?
_>>первая ссылка в поиске
S>

S>Shared Source Common Language Infrastructure 2.0 Release
S>Brief Description
S>The Shared Source CLI is a compressed archive of the source code to a working implementation of the ECMA CLI and the ECMA C# language specification. This implementation builds and runs on Windows XP.

S>Это исходники дотнета?

Первую версию дотнета (третья ссылка помоему в поиске) собирали под bsd и компиляли там софтину. Работало.
Вторую не пробовали, ибо ненадо пока.

S>>>Угу. Только вот сначала виндузятники говорят что асп имеет пхп везде а потом говорят что скрипт писать впадлу, программер крутой попадется или там лунная тень в свете болотного газа....
_>>Давайте не будем говорить за всех. Меняйте таких программеров.
S>При чем тут замена программера? разговор идет о том что дайте мне скрипт на аспе, я его переделаю в пхп и прогоню.

Нету у меня отвязанных от проекта скриптов. А переделывать webservice с датасетами это времени дохрена займет.

_>>А в Windows не имеешь? За последние 5 лет я убедился, что все вопросы категории "подземный стук", "долбаная винда", "чорт знает что она делает" или "опять глючит" сводятся к простому незнанию порой даже принципов функционирования некоторых сервисов. Да и админом щас принято называть человека, который знает что такое загрузочный диск и способен установить винду с него.
S>В винде не имею. Как отключить графический интерфейс сервака, к которому монитор подключается 3 раза в год?

А надо? У меня стоит сервер на collocation (Win2003, MSSQL 2000), монитор не подключен, работал год 24/7, выключали для добавления памяти один раз.

_>>>>Мы по старинке — контрольные точки, отладка по шагам, просмотр переменных, параметров, стека вызова и прочего
S>>>в аспе???
_>>asp.net — да. Я открыл что-то новое для тебя? Посмотри поподробнее на VS 2005. Она умеет многие приятные вещи, без которых жизнь программера порой печальна
S>Ты думаеш я студии не видел? Посмотри в about януса.
S>А по линии — гуд конечно что в аспе появилась отладка. Только вот повторю что редко она всеравно пригождается. Особенно для скриптовых языков.

Ну ты сам был удивлен, откуда же мне знать. Вот я и написал. Она появилась со студии 2003 ещо.

Здравствуйте, Sheridan, Вы писали:

R>>5. Наличие готовых стандартных библиотек "на все случаи жизни" (обработка XML, юникод и т.д.).
S>asp пользует дотнет, у php тоже дофига всякого есть. Что надо?

Главное:
1. Запросы данных (http и https).
2. Парсинг html и xml.
3. Юникод.
4. Работа с базой (MySQL или Postgree, может просто хранилище).

R>>Как здесь обстоит дело? Если исходить из того, что это будет не пара скриптов, а система, которую будет разрабатывать команда (около 5-10 человек) в течении минимум полугода и потом она будет активно развиваться — что в этом случае предпочтительней?
S>Обязательно продумать архитектуру, ну и репозиторий само собой завести надо. И еще лучше не терять разработчиков.

Архитектура — обязательно. Репозиторий — тоже. Насчет разработчиков — согласен, но идеала трудно достичь

R>>Если более конкретизировать задачу — то это будет что-то типа мета-поисковика (сбор информации из разных сайтов, парсинг и занесение в базу, отображение результатов пользователю по поисковому запросу).
S>Я так понял проект из 2х частей. Первая часть гуляет по сети и собирает инфу, вторая это дело показывает... Если все крупно, то и по железу надо это дело разнести. 1 сервер собирает, второй бд держит, третий www. Разнос сервисов по компам кстати увеличит надежность.

Да, так и есть. Насчет чтобы разнести — тоже такие мысли изначально были — все зависит от популярности сервиса. Возможно сначала лучше сделать тестовый вариант, а не закладываться изначально "сделать по хорошему" — иначе долго делаться будет.

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

Спасибо!

http://www.rsdn.ru/File/57981/PlatformChoose.zip

Получилось не так обширно как хотелось, но тем не менее есть информация к размышлению.
Комментарии и исправления приветствуются!

Спасибо всем участникам!

Романча Сергей.
Мой e-mail для приватных сообщений — rss354_собака_rambler_точка_ru