Григорий Дикий: привет, в моем примере я не использовал unix сокет, а указал адрес 127.0.0.1:8000, в настройках nginx прописал следующее
upstream tastyapi {
server 127.0.0.1:8000;
}
server {
listen 80;
server_name tastyapi.rs;
charset UTF-8;
client_max_body_size 75M;
location / {
uwsgi_pass tastyapi;
include uwsgi_params;
}
beduin01: каждый файл является модулем. В конфиге проекта прописываются названия используемых либ и пути до них, потом в своих модулях прописываешь названия либ и они подключаются непосредственно перед исполнением кода в твоем модуле. Также модули можно использовать в других модулях. Все это позволяет структурировать код проекта, например, в backbone есть модели, представления, коллекции, роутеры, их можно распихать по отдельным модулям и переиспользовать в других модулях.
@AM5800 по подсчетам из int -37 вышло float -6,8056472782053657584265955775406e+38, то есть double его воспроизведет ,вроде его диапазон подходит. А что за quiet, это он из других ячеек памяти, которые были рядом, взял данные?
@plasticmirror не мне надо проверить что будет быстрее работать в предыдущем посте, так что нужно прогонять для каждого пользователя все действия и потом находить среднее на 1млн посетителей время
Делаем служебную БД с таблицей для "эмулятора сессий" в SQL или в NOSQL субд(@fornit1917)
Таким образом в БД храню hash=sha1(id) CHAR(40), время жизни куки в минутах TINYINT, sha1(ip) CHAR(40), sha1(user_agent) CHAR(40), итого на 1млн получается 115 мб + файлы индексов(варьируется)
@Patroskan
хотел сделать примерно такое же, а именно: подготовленные запросы в PDO; в hash записывается sha1(id+некоторая соль ) и есть отдельно проверка user-agent при обновлениях страницы; в pass записывается sha1(пароль+некоторая соль); куки с id берутся у клиента и ,преобразованные в sha1(id+некоторая соль ), сравниваются с hash;
Если стащут БД для восстановления id из 40 символов уйдет 36^40 переборов, я использую нижний регистр английского алфавита и цифры для генерации id
Если стащут сам id с кук, то им еще нужно найти подходящий user-agent, тут надо добавить больше защиты, жизнь куков установлена примерно до часа, если украсть значение куки с id, то можно подставлять ее сколько угодно при подходящем user-agent т.к в БД hash остался, поэтому на сервере нужно тоже отсчитывать время жизни куки с id и выставлять hash в NULL, и при разлогине тоже выставлять hash в NULL.
@nepster09 можно провести исследование и определить среднее время между обновлениями страниц для множества пользователей, результаты будут более менее точные, т.к. погрешность с каждым опытом снижается. И записывать время смерти на найденное значение в будущем, как вариант.
PS: исследование следующего характера, записывать в БД время каждый раз после обновления страниц юзером, найти разницу между каждым обновление и дальше найти среднее значение, в конце концов найти средние средних значений пользователей.
upstream tastyapi {
server 127.0.0.1:8000;
}
server {
listen 80;
server_name tastyapi.rs;
charset UTF-8;
client_max_body_size 75M;
location / {
uwsgi_pass tastyapi;
include uwsgi_params;
}
location /static/ {
root /home/rs/dev/django/tastyapi/project;
expires 30d;
}
location /media/ {
root /home/rs/dev/django/tastyapi/project;
expires 30d;
}
}