В сообщении от Wednesday 09 January 2008 02:22:54 Michael Shigorin написал(а): > On Fri, Dec 28, 2007 at 08:27:14PM +0300, Alexey Pechnikov wrote: > > При проектировании обеих систем я не нашел ничего подходящего, > > что имеет высокую производительность (поддержка не менее 50-100 > > одновременных пользователей на сервере целерон 2,6 ГГц с гигом > > оперативки и SATA жестким диском) > > FYI в ТЗ видно сходу три изъяна по железу: процессор, память > и количество дисков. > > Celeron -- это не процессоры, а недоразумение. Гиг оперативки > при дешёвом диске -- это экономия на кэше. А один диск -- это > перегрузка и недостраховка, если вообще хоть что-то происходит > и что-то надо хранить. > > Сейчас дешёвый сервер -- это Athlon64 X2, от пары гиг оперативки > (которые стоят чуть ли не дешевле того целерона) и _два_ хотя бы > винта. Где как минимум система и важные данные лежат на softRAID1.
У меня рабочий сервер pentium D 2.8 GHz, 2 Gb RAM, soft RAID 1. Но для минимальных требований этого слишком много, так что тестовый сервер как указан ранее. А постгрес в свое время тестировал с прототипом БД на ARM 266 MHz+32 Mb RAM и нашел несколько "узких мест". Если вы назовете проекты, в которых проведена подобная работа, буду рад расширить свой кругозор. > > > написано на функциональном языке (тикль, лисп, erlang, etc.), > > Ой, тикль уже функциональный... надо же. И сваливание в кучу > тоже радует. Или это описание разведённого зоопарка? Тикль уже почти функциональный, кое-что не реализовано, но мне жить не мешает. В кучу не сваливал, просто это список языков, на которых имхо резонно делать задуманное. Кстати, первые версии разрабатывались на перле, но на тикле оказалось существенно удобнее. Конечно, этот выбор в значительной мере вопрос личных предпочтений, но для нас важно то, что на тикле объем кода в три раза меньше, чем на перле и в десять раз меньше, чем на С++ (может, у кого-то наоборот? интересно будет узнать об этом). > > > "заточено" на работу с PostgreSQL > > Вы если наслушались про ФП -- может, ещё про иерархические или > фреймовые БД где наслушаетесь? ;-) Каждый день пользуюсь файловой системой ext3. Иерархическая, аж жуть. И вовсе не вижу резона хранить все данные в реляционной БД. > > имеет устраивающую меня модель безопасности, умеет работать с > > веб-камерами на виндовых ПК любой версии, с камерами на КПК и > > смартфонах, умеет работать с КПК и смартфонами с виндоус-хоста > > путем выполнения сценария, имеет написанный на функциональном > > языке клиент для КПК и смартфонов и проч. > > Хм, что-то не помню Вас в synce-devel@, ну да ладно. > Виндовс-хост так виндовс-хост. synce работает только со старыми версиями винмобайл, увы (и при существующей стабильности имеет смысл только под линуксом). Так что использую ffidl, успешно работает с rapi.dll из активсинка версий 4.1, 4.2, 4.5. Знаю, что аналог ffidl есть, например, в питоне, но по ряду причин не считаю его "промышленно пригодным" (посмотрел синтаксис, попробовал, впечатление такое, что даже для "домашних" утилит использовать не стану). > > > Далее, для документооборота решил применить аналогию из > > квантовой механики - проквантовать допустимые состояния > > документов и описать правила их изменения. Подобного проекта я > > также не нашел (независимо от требований выше). Почему-то все > > описания сводятся к рекламным заявлениям и некоторым интересным > > идеям, но мат. или физ. модели разработчики делать не > > удосуживаются. > > Хотя бы тот же NauDoc из близлежащего уже посмотрели? У них ограничение на несколько тысяч документов _в год_. У меня нагрузка такого порядка _в день_. Я ведь не зря говорил про железо и количество поддерживаемых пользователей. У NauDoc и других подобных систем довольно широкие возможности, но низкая эффективность. Плюс возможны проблемы с транзакционностью состояний документов - например, при выполнении одной из операций над документом должны быть разосланы сообщения заинтересованным пользователям, сохранена запись о произведенном изменении и т.п. и все это в одной транзакции. Таким образом, вся логика должна быть реализована в БД, чего я не нашел ни в одной из открытых систем (можно, конечно, делать на прикладном уровне, но поддержка в этом случае значительно усложнится). Думаю, у меня довольно типичные требования к системе документооборота, ничего сверхестественного. Позвольте вопрос - хоть одну из открытых систем документоборота вы сами стали бы использовать хотя бы для 1000 пользователей? Думаю, что нет. > > > Итак, было принято решение делать "с нуля". Это было мое личное > > решение, не будем его обсуждать, достаточно того, что созданная > > система успешно работает в нескольких десятках регионов. > > Ну мне лично таких доводов недостаточно -- зная недостатки наших > систем, работающих в нескольких десятках регионов... и той же > винды, работающей по всему миру. Ну конечно, мне бы этого тоже было недостаточно :-) Я имел в виду, что поставленная передо мной задача решена. > > Опен-сорс проект делать у меня нет свободных ресурсов - > > трудозатраты огромные, а кому оно надо... > > Надо-надо. > > Трудозатраты огромные, если планировать не уметь совсем, > а взаимодействовать -- совершенно. Иначе зачастую уже не > полвелосипеда изобретено, а большая часть. > > Иначе они _могут_ быть и не огромными по сравнению с "пилим > всё сами". Возможно. Несколько раз пробовал делать открытые проекты, интереса к ним мало. Например, в блоге по ГИС и навигации уже выкинул все исходники, поскольку никто их и не смотрит (перл, питон, тикль). А геоинформатика как дисциплина на порядки важнее, чем система документооборота (первое - фундаментальный подход к миру, последнее - просто одна из прикладных задач, их вообще сравнивать нельзя). > > > Кое-что публикую в своем блоге по постгресу, но постгресом мало > > кто пользуется всерьез. > > Разумеется. Все так, поверхностно. Ну подумаешь, подпилили > в LTC, ну что вы, право. И много таких "пилителей" - единицы, десятки? И какое отношение это имеет к "пользоваться"? > > Также мало кто готов изучить новый язык/технологии > > (postgresql+pltcl + tcl + aolserver+sqlite). > > AOL-то каким боком очутился? Сервер приложений для tcl. Через CGI много не наработаешь. > > Потому и открытое сообщество в рунете остановилось на уровне > > "как настроить апач" > > Ой, не смешите мои тапочки. > > > в то время как во всем мире создаются и успешно развиваются > > прекрасные открытые проекты. > > И в рунете создаются да успешно развиваются. Просто места знать > надо, как обычно. (ну да сейчас меня опять за рекламу погонють ;) Думаю, что рунет-сообщество там и остановилось. Как всегда в россии, есть талантливые одиночки, но им есть чем заняться и без моих проектов.