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@ _______________________________________________ smoke-room mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/smoke-room
