lib.rus.ec как интернет приложение

У меня интерес к этому ресурсу, в основном, профессиональный -
любое приложение, которое демонстрирует такую статистику после одного года эксплуатации,
это уже научный артефакт, и может потенциально повлиять на интернет, как таковой.
На эту тему я бы с удовольствием поговорил (есть желающие?).

Комментарии

kumpelalte написал:
Вопрос номер два (извиняюсь, но чисто технический).
Я достаточно много работал с комбинацией Apache + PHP + mySQL.
Лет 5 назад перешёл на AJAX + JAVA Servlets.
по простой причине: Apache + PHP + mySQL просто не могло работать больше чем со 100 пользователями
одновременно.
Слышал подобные оценки и про Drupal и Moodle.
Тут всё вроде работает без проблем для 300 пользователей.
В чем тут дело ?
- мощное hardware (server farm) ?
- прегенерация входных страниц ?
- просто логика работы когда обмен через PHP/mySQL не очень
интенсивный, а загрузка идёт напрямую через Apache ?

- hardware - два сервера, первый держит вебморду, второй БД (Mysql).
Первый - core2duo, 2G RAM. К концу недели собираюсь заменить на 4х ядерный ксеон, должно тянуть до 1000 пользователей онлайн.
Не скажу, чтоб это было сильно мощным. Хотя по меркам пятилетней давности...

- прегенерация входных страниц - отсуствует. Присутствует кеширование на нескольких уровнях, как друпальное, так и самописное.

- просто логика работы - логика стандартная друпальная, несколько сотен запросов на страницу.

Апач нагрузку действительно держит плоховато, поэтому с клиентами общается nginx, а до апача доходят только запросы к php. Вся статика, иконки, цсс и прочее раздаётся в обход апача. Keep-alive опять же без него. Если использовать только апач то никакой памяти не хватит.

larin написал:

- просто логика работы - логика стандартная друпальная, несколько сотен запросов на страницу.

Я так и подозревал, и поэтому очень удивлялся результату.

larin написал:

Апач нагрузку действительно держит плоховато, поэтому с клиентами общается nginx, а до апача доходят только запросы к php. Вся статика, иконки, цсс и прочее раздаётся в обход апача. Keep-alive опять же без него. Если использовать только апач то никакой памяти не хватит.

Понял где собака зарыта.
Слышал, что проксu сильно помогает, но не думал что настолько.
Огромное спасибо.

kumpelalte написал:
Слышал, что проксu сильно помогает, но не думал что настолько.

Апач на каждого клиента форкает процесс.
При включённом keep-alive этот процесс висит несколько минут, на развесистой странице и медленном канале у клиента.
А то и часов - если толстый архив тянется.
Каждый процесс кушает память. В некий недобрый момент память кончается, система уходит в своп и умирает.

Nginx запускает по одному процессу на процессор и справляется с любым потоком запросов практически без потребления памяти. Как-то он умнее спроектирован.

larin написал:

Апач на каждого клиента форкает процесс.
При включённом keep-alive этот процесс висит несколько минут, на развесистой странице и медленном канале у клиента.
А то и часов - если толстый архив тянется.
Каждый процесс кушает память. В некий недобрый момент память кончается, система уходит в своп и умирает.

Это я со страшным матом наблюдал 5 лет назад.
larin написал:

Nginx запускает по одному процессу на процессор и справляется с любым потоком запросов практически без потребления памяти. Как-то он умнее спроектирован.

Жалко что мы тогда не подумали о прокси для CSS, IMG и других негенерируемых файлов.

Боюсь спросить, а вопросы безопасности можно затронуть или ну их ?

kumpelalte написал:
Боюсь спросить, а вопросы безопасности можно затронуть или ну их ?

Затронуть можно, но сказать мне нечего. Линукс, Друпал, фтп-сервер с их стандартными процедурами.

larin написал:
Затронуть можно, но сказать мне нечего. Линукс, Друпал, фтп-сервер с их стандартными процедурами.

Думал, думал, спасибо за добрую волю, но не буду.
Слишком скользко, а вдруг чего, потом не замолишь :-)
Ещё раз огромное спасибо.

larin написал:
Nginx запускает по одному процессу на процессор и справляется с любым потоком запросов практически без потребления памяти. Как-то он умнее спроектирован.

Уточнее: не умнее, а значительно лучше заточен под конкретную весьма узкую задачу: максимальная производительность при достаточно скромной функциональности.

Офигенный сайт! Капитан Ларин - это звучит!

Все когда нибудь умирает, так надо сказать спасибо Ларину, что ЛИБРУС держится.

Страницы

X