LINUX.ORG.RU

Сотни тысяч HTTP запросов в секунду. Из какого железа и как собрать систему?

 , ,


0

2

Допустим, что есть приложение на основе LAMP, делающее сотни тысяч HTTP запросов в секунду. Из какого железа и как собрать систему для стабильной и плавной работы этого приложения? Есть ли готовые примеры системной архитектуры для такого проекта? Интерес вызывает именно аппаратное обеспечение. Что бы вы посоветовали почитать по данному вопросу?

★★

Странный вопрос. А что тут можно придумать, в плане аппаратного обеспечения? EPYC какой-нибудь, несколько сетевых портов, по которым будет балансироваться приложение(ну, если затык будет).

proveryam
()

Допустим, что ты не осилил непротиворечиво описать задачу...

erfea ★★★★★
()
Ответ на: комментарий от anonymous

Спасибо за уточнение, я исходил из того, что если LAMP, то речь об обработке клиентских запросов, но вы правы, тут надо уточнить. С другой стороны, если там действительно сотни тысяч запросов в секунду, то Apache, MySQL и PHP тоже как бы не к месту.

jia ★★
() автор топика

Не, лучше мы допустим, что такого приложения нет.

thesis ★★★★★
()

Интерес вызывает именно аппаратное обеспечение.

AWS load balancer может дать больше 500k в секунду. Но AWS не самый дешовый провайдер. Собирайте у какого-то облачного провайдера, по крайней мере на первых порах. Вам никто конкретно не скажет, сколько вашему приложению нужно серверов.

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)

Лучше задумайся о масштабировании своего приложения. High Load на LAMP в сингл ноду звучит странно.

filosofia
()

Кластеризовать, масштабировать и балансить. Все остальное - не решение, а говно.

pekmop1024 ★★★★★
()

Интерес вызывает именно аппаратное обеспечение

Не понятно - зачем? Ну, то есть, нюхавшие хайлоад понимают, что одна нода больше 8cpu/64ram - уже обычно признак того, что что-то пошло не так с архитектурой приложения. А балансить аппаратно можно железяками A10, например. Пупок-то не развяжется такое купить?

pekmop1024 ★★★★★
()

Если судить по данному описанию, я бы первым делом спросил: а статику чем раздаёте?

И если ситуация 10к запросов к скрипту + 20 картинок/css-ок на страничку, и всё это отдаётся апачем (а то и пхп) то я посоветовал бы поставить nginx.

Если же речь о сотнях тысяч именно запросов к скрипту (а не картинки, по 20 штук на страничке), то наверное нужно рассмотреть кэширование.

Если всё вышеперечисленное уже сделано, то я умывыаю руки и надеюсь на благородных донов в треде выше которые ставят вопросы/дают советы.

AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 1)

LAMP, делающее сотни тысяч HTTP запросов в секунду.

какой длины? какой кривости?

darkenshvein ★★★★★
()

не допустим. если есть приложение на основе LAMP, делающее сотни тысяч HTTP запросов в секунду — есть и статистика запросов, результаты их профилирования и понимание где узкие места железа, где софта а где сети. но у тебя ни приложения нет ни сотен тысяч запросов, одни маняфантазии

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()

Хз что такое lamp, но netty у меня принимала 100к/с не напрягаясь на двух старых зеонах о четырёх ядрах, правда я не особо вникал в оптимизацию и отдал под пул потоков 32гб

rukez ★★★★
()

Из какого железа

  1. Иди сюда.
  2. Возьми VPS за 2.5 евро, допустим с убунточкой.
  3. Настрой это чудесное приложение.
  4. Выключаешь vps и масштабируешь его к 16 ядер / 32 гиг озу
  5. Оцениваешь, хватает тебе или нет.

Оплата - почасово. Так что много не потратишь. Если мало, можешь взять реальную железную машину, с ЛЮБЫМ железом.

anonymous
()
Ответ на: комментарий от filosofia

Ну в общем то L, A и P худо-бедно линейно масштабируются, а вот с M могут быть проблемы.

Nastishka ★★★★★
()

Надо обратиться к знающим людям.

Legioner ★★★★★
()
Ответ на: комментарий от Harald

Raspberry Pi 4

совмещаем:

asic
anonymous (25.04.21 20:43:42)

Я действительно уже не раз слышал о какой-то феноменальной производительности RPI4 в качестве web-сервера

jia ★★
() автор топика

Выкинь апач, поставь NGINX; выкинь mysql, используй sqlite — сэкономишь на железе.

О том, что пыхпых только совсем недалекие используют, думаю, и говорить ненужно?

В общем, правильный набор: Linux + NGINX + sqlite.

Eddy_Em ☆☆☆☆☆
()
Последнее исправление: Eddy_Em (всего исправлений: 1)
Ответ на: комментарий от ddidwyll

Если у тебя БД маленькая, то sqlite будет более оправдан. С тем, что жирный апач сильно уступает nginx спорить не будешь?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

Если у тебя БД маленькая, то sqlite будет более оправдан.

И если из этих сотен тысяч 99.999% ничего не будут писать в базу.

С тем, что жирный апач сильно уступает nginx спорить не будешь?

С этим спорить смысла нет.

ddidwyll ★★★★
()
Ответ на: комментарий от jia

Почитайте про архитектуру фейсбук. У них есть бложик, в который они периодически пишут о том как они захватывают голактеку

cobold ★★★★★
()

берешь какую-нибудь циску АСЕ, rserver и балансишь на столько нод, скольно надо.

PunkoIvan ★★★★
()
Ответ на: комментарий от anonymous

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

Название-то переведено. Как и фамилия автора. В оригинале там John Zalupa.

anonymous
()
Ответ на: комментарий от Eddy_Em

выкинь mysql, используй sqlite

Хм, интересно. Подобные рекомендации я, кажется видел в книге Джона Дикхеда, «Хайлоад на телефоне в маршрутке за 12 часов».

anonymous
()
Ответ на: комментарий от Novec1230

Полноценный веб-сервер менять на разжиревший прокси-сервер?

Апач ток ПХП-ёрам и одинэсерам нужен. Для оствльного – прокси с лод-балансом.

Полноценную СУБД менять на какой-то огрызок?

Парнишка просто экономит на сетевых задержках при обращении к серверу БД, думается. Там вроде сравнимо с обращением к RAM, если норм канал.

anonymous
()
Ответ на: комментарий от anonymous

Ты еще скажи, что ruby с python используют недалёкие)

Питухон – прикладной язык для офисных и студентмков около IT. А Раби для Эни Бени.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.