Ущебный метод, который не решает задачу:
1. Вы читаете весь файл, который согласно вашему коду 10к строк, каждая из строк содержит REQUEST_URI
При get запросах REQUEST_URI может достигать нескольких килобайт, а ваш файл нескольких мегабайт. И таким образом каждый раз вы будите читать из файла несколько мегабайт и заново их записывать. Тут в файл просто пишутся запросы, а длина файла ограничена 10к строк
2. Состояние гонки при чтении и запись в файл. Первый запрос прочитал файл, пока считает количество, вставляет там строку (всё исходя из вашего кода), второй запрос тоже читает файл. Оба они прочитали одинаковый файл, оба изменили по своему. Оба записали. Но состояние данных в файле в таком случае будет соответствовать только последнему запросу
3. Метод определения IP очень странный/старый. Всякие заголовки HTTP_CLIENT_IP HTTP_X_FORWARDED_FOR используются если у вас стоит балансир и т.п. В общем случае траф идёт ещё через какой-нить сервер. Просто так этим заголовкам я бы не доверял
P.S. Дмитрий HTTP_X_FORWARDED_FOR ни как не зависит от браузера. Я его могу отослать как с клиента серверу, так и прокинуть на сервере дальше
P.P.S. Кстати, где же количество одновременных клиентов?
Анатолий, ни как. Быть может вы не знали как редис хранит данные. И вполне возможно ваше "жрёт" по объёму равно данным, которые в него поступают из вашего приложения
Эдуард Баженов, нет)))
Смотрите. Живой пример. Вы изготовили три изделия:
1. 2000*1500 с 20 ламелями красного цвета высотой 1500
2. 3000*1500 с 30 ламелями жёлтого цвета высотой 1500
3. 3000*2000 с 30 ламелями красного цвета высотой 2000
Как храним:
Таблица цветов (tabel_c):
id, name
1 Красный
2 Жёлтый
Таблица ламелей (tabel_l) - здесь все ламели по описанию уникальны! Если длина и совпадает, то цвет отлиыается, или другая характеристика
id height color_id
1 1500 1 (высота 1500 красный)
2 1500 2 (высота 1500 жёлтый)
3 2000 1 (высота 2000 красный)
Таблица изделия (tabel_p)
id height, width, lamel_id, count
1 1500 2000 1 20 (2000*1500 с 20 ламелями красного цвета высотой 1500)
2 1500 3000 2 30 (3000*1500 с 30 ламелями жёлтого цвета высотой 1500)
3 2000 3000 3 30 (3000*2000 с 30 ламелями красного цвета высотой 2000)
Эдуард Баженов, ваша таблица с продуктом - это как чертёж со спецификацией. Поля с шириной, высотой изделия и т.п. - это сам чертёж. Ссылка на ламели - это как спецификация (вы же в ней не пишете 10 раз ламель такой-то), вы указываете ссылку на чертёж ламеля и пишете сколько единиц
Вы немного не поняли. В таблице с ламелями находятся различные вариации ламелей, типа как образцы (не знаю как лучше объяснить). А вот в таблице с изделием вы ссылаетесь на эту таблицу (иными словами говорите, что для этого изделия мне надо вот такой конфигурации ламели, в количестве - поле в таблице с изделия)
Дмитрий, какое правило нарушает этот запрос?) Я, кстати, не ищу ответ, я знаю что там будет и откуда что достать. Я просто Вас подталкиваю к более полному ответу на Ваш же вопрос, хотя товарищ Nujabes37 дал уже ответ.
Насчёт правил. Тривиальный запрос к api на создание ресурса как раз будет отправлен методом POST, а в теле будет json строка с параметрами для создания
Дмитрий, вы попробуйте. Например в теле запроса просто ["text"] и всё. Просто строка. Без названия параметра, без значения, как Вы привыкли. Из какого массива Вы её достанете и как?
