team-voice: с учетом какой у вас сервер сейчас.. мне кажется вам стоит взять какой нибудь Е5 двух процессорный с 10-14 ядер на каждом cpu (40-48 потоков на сервер) и ssd накопителями и забыть о проблеме расширения на долгое время.
Ну вот, скажем, в пик будет 10 000 запросов входящих одновременно. Выдержит это один сервер? Где-то читал, что есть некие ограничения у сетевых карт, что не будет столько запросов проходить за раз (более подробно не могу объяснить, речь была о каких-то прерываниях).
mClouds, а если нагрузка "рваная"? Вот пришел пуш в приложение всем пользователям, они его открыли - приложение у всех пошло на сервер за информацией, скачок в нагрузке. Пользователи новости прочитали и дальше "притихли" до следующего пуша. Т.е. нагрузка будет волнами.
Эх ) Сколько людей, столько и мнений. Жаль, что нельзя никак проверить то или иное решение, кроме как под реальной нагрузкой... Или может заказать на себя ддос, чтобы проверить )
Советуют довериться сохранению информации о прочитанных сообщениях сторонним облачным сервисам, типа Google Firebase. Есть ли у кого опыт? Насколько там точны данные?
Мгновенная реакция не нужна. Главное приложению отдать в ответ статус 200ОК, а не какой-нибудь 502 или 504, чтобы оно не ждало и не пыталось еще раз соединиться и отправить.
А где тогда складывать можно? По сути в очередь какую-то, откуда не спеша нормальным темпом будет в базу все раскладываться. Как такую очередь можно сделать? Какую-то базу, куда тупо инсертить данные? Но опять же - 10 000 за секунду придет в очередь разными запросами, надо как то обработать...
с учетом какой у вас сервер сейчас.. мне кажется вам стоит взять какой нибудь Е5 двух процессорный с 10-14 ядер на каждом cpu (40-48 потоков на сервер) и ssd накопителями и забыть о проблеме расширения на долгое время.
Ну вот, скажем, в пик будет 10 000 запросов входящих одновременно. Выдержит это один сервер? Где-то читал, что есть некие ограничения у сетевых карт, что не будет столько запросов проходить за раз (более подробно не могу объяснить, речь была о каких-то прерываниях).
mClouds, а если нагрузка "рваная"? Вот пришел пуш в приложение всем пользователям, они его открыли - приложение у всех пошло на сервер за информацией, скачок в нагрузке. Пользователи новости прочитали и дальше "притихли" до следующего пуша. Т.е. нагрузка будет волнами.
ддос или нет, не понятно, но тормозит сайт их ужасно. Постоянная 502.
Эх.... Загубили сервис... Печально смотреть, что стало с моим детищем...
Может стоило для начала дождаться ответа от службы поддержки или теперь по каждому случаю тему на форуме принято заводить? ))
Кто-то из сторон подал реальный иск?
Бегет подал иск к Рег.ру о признании отказа от исполнения договора недействительным. Собеседование по делу назначено на 6 сентября.
только три цифры на обороте меняются с каждым перевыпуском раз в два года.
Так вроде как раз без этих трех цифр оплату не провести никак даже если все остальные данные есть, разве нет?
Как они списали деньги с карты, если у продленной карты эти три цифры как раз поменялись?
Первый раз такое вижу, все сервисы настойчиво требуют обновления данных карты, когда срок истек.
Эх ) Сколько людей, столько и мнений. Жаль, что нельзя никак проверить то или иное решение, кроме как под реальной нагрузкой... Или может заказать на себя ддос, чтобы проверить )
Вот еще вычитал как народ извращается - https://habrahabr.ru/post/262623/
Советуют довериться сохранению информации о прочитанных сообщениях сторонним облачным сервисам, типа Google Firebase. Есть ли у кого опыт? Насколько там точны данные?
Мгновенная реакция не нужна. Главное приложению отдать в ответ статус 200ОК, а не какой-нибудь 502 или 504, чтобы оно не ждало и не пыталось еще раз соединиться и отправить.
А где тогда складывать можно? По сути в очередь какую-то, откуда не спеша нормальным темпом будет в базу все раскладываться. Как такую очередь можно сделать? Какую-то базу, куда тупо инсертить данные? Но опять же - 10 000 за секунду придет в очередь разными запросами, надо как то обработать...