Судя по коду, может рухнуть при попытке сконвертировать введенную строку в число (int).
Если в задаче не оговаривается, что входные данные всегда корректные, то нужно try/except
Также количество школьников может оказаться нулевым, а тут деление.
Именно, скорее всего там где счётчик сильно отстаёт от сервера это задержка на стороне клиента и setInterval() или setTimeout() отрабатывают не по плану.
Писать клиенту о том что нужно синхронизировать игру не очень юзерфрендли.
Сгладить проблему фризов можно, если не делать обратный отсчёт по таймеру, а использовать таймер для вычисления оставшегося времени до конца хода.
Т.е. в момент получения хода нужно вычислить время его окончания и далее по таймеру находить разницу между временем окончания хода и текущим временем.
В случае залипания таймера отсчёт будет идти не равномерно, но зато время просрочки клиентского таймера относительно серверного если и будет, то будет не большим.
Время можно получать Date.now() сразу в миллисекундах.
Т.е. в начале хода
DateEnd = Date.now() + 1000*60
В таймере:
CurrDate = Date.now()
Delta = (DateEnd-CurrDate)/60
Как только Delta <= 0 происходит смена хода.
Значение Delta можно также показывать клиенту как значение таймера, по сути это время до конца хода от текущего момента.
setInterval() и settimeout() аналогичны по смыслу, они в очередь событий помещают процедуру callback, только settimeout выполняет это один раз, а setInterval пока не придет clearInterval.
Но если в процедуру callback поместить например sleep(10000), то раньше чем через 10 сек callback не сработает.
Php не причем.
Вряд ли на сервере так долго проверка происходит, хотя это тоже нужно проверить.
Под фризом таймера я подразумеваю изменение времени срабатывания callback таймера в скрипте браузера. Браузер не даёт гарантии, что интервал срабатывания указанный например в параметре процедуры settimeout() будет строго соблюдаться.
Вот хорошая статья на тему: https://habrahabr.ru/company/ruvds/blog/340508/
Так это же из-за фриза таймера на клиенте. Не будет фриза, не будет и таких задержек.
А чтобы не было фриза нужно брать абсолютное время конца хода, а не то которое обратным отсчетом по таймеру получается.
Хотя странно выходит, у вас каждые 10 сек уходит запрос на сервер, значит в худьшем случае таймер клиента должен отставать не более чем на 10 сек от таймера сервера.
Или запросы из-за фриза таймера клиента тоже уходят не каждые 10 сек, а сильно реже?
Каждый клиент сам для себя вычисляет своё время. Т.е.берет то что на часах, прибавляет 90 секунд и получает своё локальное время окончания хода. Даже если клиент поменяет свои часы чтобы обмануть игру, то все равно решение о передаче хода принимает сервер, как только клиент свяжется с сервером все встанет на свои места.
Ясно.
В вычислениях есть странный момент:
злоумышленник залогинился с 195.10.34.123, user agent: Chrome, Country: Belarus записей для этого пользователя с таким ip - 1, с user agent - 10, с geo - 10, всего логинов - 1, (10/1 * 1/1 * 1/1 * 1/11) = 9,090909091
(10/1 * 1/1 * 1/1 * 1/11) = 9,090909091
Почему первый множитель 10/1, а не наоборот (1/10)?
Ведь вероятность это количество исходов, того когда событие появилось к общему количеству исходов.
Общее должно быть больше.
Да, но тут есть нюанс, если будут искать только по "Киркоров", то не сработает.
А Like с шаблоном типа такого % ..% с индексами работает не эффективно.
Есть ещё момент, для left join и Right join, тут левая или правая таблица всегда полностью выводится, а во втрой таблице при связывании если нет нужной строки, то значения всех колонок равны null. Это удобно использовать, когда нужно например вывести все записи одной таблицы для которых нет записей в другой
Олег Петров, можно написать bat-ник из которого запускать ваш exe.
В батнике, что-то вроде такого написать
notepad >> c:\temp\a.log
А сам батник повесить на автозапуск.
Вместо notepad ваш exe нужно вписать.
Если что-то пойдет не так по идее в a.log должен быть вывод того что попало в консоль до появления ошибки.
Судя по коду тут full join для таблиц c,d,e и записи в выборке перемножаются. В итоге вместо 1000 записей возвращается 1000 миллиардов записей и сервер падает при попытке построить датасет.
Так вторая же ссылка, про масштабирование изображений. При использовании интерполяции и для случая уменьшения исходного изображения каждому пикселю уменьшенного изображения соответствует несколько пикселей исходного и чтобы определить результирующий цвет берут квадратичную или кубическую функцию от исходных цветов пикселей. В итоге от границы к центру области происходит небольшое отклонение от исходного цвета. Вот здесь про resize на canvas хорошо написано.
В таком случае, как вариант можно построить индекс по дате события в отдельном массиве, индекс должен состоять из трёх полей:номера элемента индекса, даты и идентификатора события.
В индексе записи должны быть отсортированы по дате.
В таком случае можно по индексу отбирать события, а для ускорения поиска использовать бинарный поиск. Правда появляется необходимость поддерживать этот индекс. Но зато, если обращения к событиям будут происходить часто - это сильно сэкономит время на поиск и отбор событий.
Kooper_pro, это может быть связано с особенностями растеризации при отрисовке линий. Так делается чтобы линии казались более гладкими без ступенек.
Подробнее вот в этой статье почитать. https://habrahabr.ru/post/343876/
Либо с интерполяцией цветом при масштабировании. compgraph.tpu.ru/scale.htm
Конечно делал(я таким образом определял грань на 3D модели, которую выбрали мышью. Т.е. строил проекции всех видимых граней, которые попадали во viewport, на плоскость экрана, и у каждой грани делал заливку цветом соответсвующим номеру грани, а дальше по координатам мыши определял грань), поэтому и пишу. Вы нарисовали у каждой области свою границу, но по условию задачи это не так. Граница задается отрезком соединяющим две точки - это одна линия, а у вас по факту две рядом идущие границы.
Я в общем то и не критикую это решение, просто Вы его упомянули как универсальное и всегда работающее, а по факту тут есть границы применимости и нужно о них знать чтобы понимать можно использовать метод для решения задачи или нет.
Тут тоже есть нюанс. При таком подходе граница включается в ту область, которая выводится раньше. Т.е. порядок вывода областей в буфер меняться не должен иначе немного изменят границы объектов. Например если 6 область выводить последней ее северная граница будет на 1-2 пикселя смещена вниз, но если выводит области в обратном порядке, то южная граница области 1 будет смещена вверх на те же 1-2 пикселя.
Кроме этого, если исходная картинка имеет размер больше чем размер экрана, т.е. есть скролл или зум, то закрашенные области не всегда будут точно решать задачу из-за погрешностей вычисления координат в цветовом буфере по координатам исходной картинки. И тут придётся заново перестроитраивать цветовой буфер как только картинка поменяет масштаб.
Алгоритм заливки области требует указания границы области, например цветом. Как вы предлагаете делать заливку не указав контуров? Особенно это касается стыков областей, т.е. внутренних рёбер, которые как бы принадлежат нескольким областям.
Если в задаче не оговаривается, что входные данные всегда корректные, то нужно try/except
Также количество школьников может оказаться нулевым, а тут деление.