Re: [room] язычки и библиотечки

["Денис Смирнов" <mithraen@altlinux.ru>]

On Tue, Oct 24, 2006 at 10:03:08AM +0300, Michael Bochkaryov wrote:

>> Пока оказалось проще пол PHP под себя переписать :) Если серьезно --
>> mod_perl бы рулил, если бы не был так завязан на Apache. Так что рулит
>> скорее всего сейчас FastCGI.
MB> Ну, FastCGI и так рулит. Хотя бы по причине достаточной изоляции
MB> приложения от веб-сервера с сохранением нормальной скорострельности. :)

Ага. Притом что скорострелность nginx+fastcgi куда выше чем
apache+mod_perl какой, и безопасность выше -- выбора в общем-то и нет :)
Только вот инфраструктуры для удобного запуска fastcgi сервисов пока нет.

>> Если честно, я бы уже совсем обиделся и ушел на Java, написав к ней
>> несколько классов для обраобтки FastCGI, темплейтов и прочей радости, а
>> также компилятор в неё с простого PHP-like язычка. Только вот
>> инфраструктура вокруг неё какая-то кривенькая, не могу я к ней привыкнуть.
MB> Ой, мы уже попытались сделать переход в сторону J2EE.
MB> Убедился на своей шкуре, что оно очень хорошее, но далеко не для всего.
MB> Для интеграции приложений, которые разными командами делаются - оно :)

Ой, ну давай не будем о драконах? :) Java как язык сама по себе ничего,
только многословная шибко. А вот навернутая вокруг неё инфраструктура...
жуть.

>> Зато с масштабируемостью проблем вообще никаких :)
>> А разве не любое приложение, хранящее свои данные исключительно в SQL
>> легко кластеризуется?
MB> Тогда тебе может потребоваться хорошо масштабируемый SQL-сервер.
MB> Но это уже вопрос не языка, а выбора СУБД :)

Пока меня постгрес устраивал.

MB> Это мы попробовали бинари держать в постгресе - больше не хочется.

А вот с бинарями совсем все плохо. Я уж думал для такой цели какую
кластерную FS использовать... Но она должна быть в userspace. Вот смотрю
на fuse и думаю -- написал бы кто :) Благо много ей особо уметь не надо --
обычно речь идет о замещении объектов, а никак не о редактировании. Да и
резолвить конфликты просто -- кто последний тот и прав.

>> Вообще задач где при правильном программировании мне не хватило бы одного
>> физического сервера у меня не было.
MB> Везет тебе - у меня встречалось :)

Это что за мегапорталы такие? :)

>> Встроеный в ваку механизм кэширования распарсеного глючил, пришлось
>> отключить. А без него на каждый запрос уходит очень много времени. Вон
>> когда комменты спамят легко доводят страницу до того состояния, что она не
>> успевает отобразиться в 30 секунд и скрипт затыкается.
MB> А на чем оно тормозит то? БД? Парсинг текста?

Парсинг. Это основа wiki, как-никак. Там он нетривиальный, и может
склеивать текст из нескольких. Если совсем по-хорошему его надо выносить
во что-нибудь на более другом языке написаное, по крайней мере критичные
по времени куски. Но там все так тесно переплетено...

MB> Может, есть смысл этот механизм кеширования подправить?

Пока меня не шибко напрягает. Когда начнет напрягать -- возьму в руки
большущий напильник. Но, судя по статистике, это будет когда пользователей
окажется несколько тысяч в день. Сейчас там свего-то 500-600 уникальных
пользователей в день.

MB> Что там за глюки то были с ним?

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

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Ещё пара сборочных серверов, и sisyphus regression test suit у нас
в кармане.
		-- ldv in devel@