Назад | Перейти на главную страницу

Супер простой высокопроизводительный http-сервер

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

Я хотел бы иметь две отдельные службы на разных машинах.

ОБНОВИТЬ:

Сервис вообще не является сокращателем URL. Просто так это объяснить было проще.

Мне просто нужна одна машина, которая получает один HTTP-запрос и вставляет запись в базу данных. И мне нужна эта машина, чтобы выполнять эту простую задачу очень эффективно. Система будет работать на Linux (я еще не знаю дистрибутив), и я полностью открыт для любого языка или технологии. Я думал использовать Yaws, Tornado или Snap для этой службы, но я еще не знаю, и пора спланировать архитектуру для этой части. База данных будет построена на Hadoop.

Для третьей машины мне просто нужно принять один вид HTTP-петиции (GET www.domain.com/shorturl), но он должен делать это очень быстро и быть достаточно стабильным.

Вы действительно думаете, что нужен еще один сокращатель URL? Есть только очень много из них ... если вам случайно не удалось приобрести очень короткое и подходящее доменное имя, я просто не думаю, что ваш сайт будет кем-либо замечен. Конечно, всего два цента.

Во всяком случае, к технической части:

  • На каком языке вы собираетесь писать свое приложение?
  • В какой операционной системе вы планируете его запускать?
  • Будете ли вы использовать бесплатное или коммерческое программное обеспечение?

Даже не зная об этом, сложно ответить на ваш вопрос.

Единственный ответ, который здесь может иметь хоть какой-то смысл, - «избегать Java как чумы». Сервер приложений Java является излишним для многих приложений, и он наверняка будет излишним для такого простого.

Я бы выбрал Linux / Apache / MySQL / PHP здесь ... если Конечно, я мог придумать любую вескую причину даже начать этот проект.


Редактировать:

Хорошо, теперь это имеет немного больше смысла; но предложение начать как можно проще и затем беспокойство о масштабировании все еще актуально. Если ваше приложение действительно настолько простое, любая достойная комбинация веб-сервер / язык / база данных должна уметь обрабатывать лоты запросов в секунду на современном оборудовании (но я все же настоятельно рекомендую избегать Java).

Если производительность превыше всего, я бы выбрал приложение CGI, написанное на C; который будет самым быстрым решением, на порядки быстрее, чем любой интерпретируемый язык или язык виртуальных машин; и выполнение простых операций INSERT и SELECT в базе данных не должно быть так трудно. Но я думаю, что LAMP более чем достаточно для ваших нужд ... они действительно работают Facebook об этом, вы знаете?

Во-первых, я знаю, что вы сказали, что это не средство сокращения URL-адресов, но если это что-то подобное, СУБД - ужасный способ хранения этих данных; поскольку между любыми двумя частями данных нет реальной взаимосвязи, вам нужен плоский механизм хранения. Рассмотрим Mongo (или Couch, в зависимости от вашего фактического пространства для решения).

Что касается вашего решения, будьте осторожны преждевременная оптимизация. Есть много способов сойти с ума от этого; раз уж вы спросили, самое безумное, что я могу придумать навскидку, это запустить Varnish, записать все ваши страницы в VCL и подключить его к memcache на бэкэнде для хранения и извлечения соответствующих данных. Но на самом деле это блять сумасшедший, если только вы не испытываете явно абсурдную нагрузку.

Это просто запись данных или они также отправляют что-то интересное? Если они просто регистрируются, то просто используйте apache и загрузите журналы apache в hadoop. Если им нужно вернуть какие-то данные, то мне совсем не ясно, как они получают данные, которые возвращают.

Тем не менее, apache, настроенный так, чтобы просто возвращать статический файл для любого запроса, чертовски быстр.