Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 102
А о чем вообще этот пост?
Показать цифры тестов которые я собрал, а также те проблемные места, с которыми можно столкнуться. Тотже Prototype встерчается очень часто, когда задачи мелкие оно не видно, и порой девелоперы не понимают куда убегает время.
Тоже касается и базы, когда сложные расчеты запихивают в PHP надеясь что PHP с легкостью с этим справится, но на самом деле оказывается что PHP как раз болеет скоростью в аналитике.
Тоже касается и базы, когда сложные расчеты запихивают в PHP надеясь что PHP с легкостью с этим справится, но на самом деле оказывается что PHP как раз болеет скоростью в аналитике.
Простите… но вот конкретно тест clear vs prototype vs jquery… (к слову давненько я не встречал проектов на prototype, да и то что он медленный это уже давно известно).
Я правильно вас понимаю? Вас удивляет что просто обработка цикла занимает в десять раз меньше времени чем создание XmlHTTPRequest Объекта, накладные расходы на обертку, отправка запроса (а это занимает порядком времени), вставка в тег через обертку (все же метод html() немного не то же самое что и innerHtml)? Мне кажется результат вполне себе предсказуем. Обычно в JS больше всего времени тратится именно на работу с DOM и на ожидание запроса.
Я правильно вас понимаю? Вас удивляет что просто обработка цикла занимает в десять раз меньше времени чем создание XmlHTTPRequest Объекта, накладные расходы на обертку, отправка запроса (а это занимает порядком времени), вставка в тег через обертку (все же метод html() немного не то же самое что и innerHtml)? Мне кажется результат вполне себе предсказуем. Обычно в JS больше всего времени тратится именно на работу с DOM и на ожидание запроса.
Вы явно не поняли. в тесте чистое время обработки массива без учета Ajax. Там проблема не во времени загрузки, а в выполнении JavaScript кода через eval(). Я не рылся в глубиннах prototype и jquery и видимо подход совершенно разный, и скорее всего первый парсит на строки или куски выполняя eval() а второй видммо делает это целиком. Но это тллько пога догадки.
опять же что удивительного в том что eval отрабатывает значительно медленнее? Лучше было бы попробовать через $.getScript это же проделать. В этом случае скрипт загружается через тег скрипт (для обеспечения возможности кросдоменных запросов, как я понимаю) и потеря производительности в теории будет не такой значительной.
вся суть в проблеме темплейтов которые грузятся через Ajax.
Кто знает об этой проблеме просто молодцы. Но я вижу таких около 90% того что есть щас в инете. Все девелоперы кто строят web 2.0, грузят все аяксом не задумываясь, и благо им непопадаются задачи с большими расчетами, потому как таких задач мало, и это больше к торговым площадкам относится, чем к другим задачам. Но проблема есть, многие не знают, и пост был на то и расчитан чтобы показать что может ожидать, а также для себя сравнить с другими платформами, хотябы ради интереса.
Кому было полезно, значит хорошо.
Кто знает об этой проблеме просто молодцы. Но я вижу таких около 90% того что есть щас в инете. Все девелоперы кто строят web 2.0, грузят все аяксом не задумываясь, и благо им непопадаются задачи с большими расчетами, потому как таких задач мало, и это больше к торговым площадкам относится, чем к другим задачам. Но проблема есть, многие не знают, и пост был на то и расчитан чтобы показать что может ожидать, а также для себя сравнить с другими платформами, хотябы ради интереса.
Кому было полезно, значит хорошо.
Дополнения.
1) База. MySQL по дефолту имеет my.cnf для работы на очень маленьком объеме памяти и разумеется очень фигово работает при больших объемах данных Поэтому сравнивать производительность имеет смысл только на оттюненных конфигах, ну а говорить о тестировании не приводя конфиг — неправильно.
2) php и массивы. При больших объемах потребление памяти/скорость работы частично решается spl структурами данных.
1) База. MySQL по дефолту имеет my.cnf для работы на очень маленьком объеме памяти и разумеется очень фигово работает при больших объемах данных Поэтому сравнивать производительность имеет смысл только на оттюненных конфигах, ну а говорить о тестировании не приводя конфиг — неправильно.
2) php и массивы. При больших объемах потребление памяти/скорость работы частично решается spl структурами данных.
Проэкт был чужой и потому находя проблемные места, сразу сравнивал с другими вариантами. Доступ к настройкам сервера получить не удалось, да и запуск налокальном сервере показал все теже проблемы. При том что MS SQL сервер сидел в виртуалке, с ограниченными ресурсами, да и сама редакция Web сильно урезана, но ей это не мешает выплнять гараздо сложные запросы и при гараздо больше данных, с легкостью.
MySQL тестировал на совершенно разных трех вариантах серверов… думаю статистически уже понятно что MySQL даже близко не сможет снизить время до MS SQL, поэтому игра в милисекунды уже не существенна. Даже вместо 30сек получить 15сек, все также убивает проэкт, это не 1сек.
MySQL тестировал на совершенно разных трех вариантах серверов… думаю статистически уже понятно что MySQL даже близко не сможет снизить время до MS SQL, поэтому игра в милисекунды уже не существенна. Даже вместо 30сек получить 15сек, все также убивает проэкт, это не 1сек.
Подождите, вам говорят о тюнинге конфига, поскольку MySQL можно поставить на уйму операционок, и у каждой — свои ообенности. А вы — «Вот MSSQL — и он работает». Поставьте MSSQL на Debian и тогда поговорим, что у кого как и когда работает.
Дайте мускулу больше памяти под данные, подрихтуйте конфиг, разберитесь в ее тонкостях — и все станет хорошо. А так — это предвзятый пост «вот я сравниваю с MSSQL, который хороший, который я люблю — и MySQL мне не нравится и тормозит». Вам не нравятся кошки? Право, вы просто не умеете их готовить!
Дайте мускулу больше памяти под данные, подрихтуйте конфиг, разберитесь в ее тонкостях — и все станет хорошо. А так — это предвзятый пост «вот я сравниваю с MSSQL, который хороший, который я люблю — и MySQL мне не нравится и тормозит». Вам не нравятся кошки? Право, вы просто не умеете их готовить!
Речь вообще не о игре в настройки и попытке вытащить по пару процентов производительности. Или вы сможете второй вариант запросы с подсчетом SUM из вложенного запроса, выполнить хотябы близкое к 1 сек? даже 5 сек, при выборе за месяц это уже катастрофа. А при выборе за пол года или год, MySQL просто умрет. И снова начинаем играться в изобретения велосипеда. Для аналитики и больших расчетов, есть подходящие для этого базы. С таким успехом можно взять MongoDB и там начать играться в лего. Ктото и на SQLite умудряется посадить задачи с аналитикой, зато мол мобильность и бесплатность.
На мускуле делаю запрос для аналитики. Объем таблицы — 8 КК. Для диапазона в месяц выполняется за 1,2 сек. Покрывающий индекс вывозит.
первый заброс выборка да, я умудрился до 0,7 времени разогнать, но вот сразу получить SUM() поверх выборки… муська уходит в небытие и безвозвратно, даже уменьшение периода в 3-5 дней, так и не дождался, т.е. полюбому нужноили через временные таблицы гонять или снова на PHP доделывать. И снова получается, то что модно выполнить за один проход — делаем разные манипуляции и обходы.
Я выполняю AVG. Не берусь утверждать, но думаю другого быстрого способа кроме как найти SUM и разделить на COUNT не существует. Значит моя операция даже сложнее, чем ваша. У меня есть реальная база, на которой я могу это потестить. У меня за месяц получается около 300 к записей. Т.е. получается, что индекс помогает мне: выбрать эти самые 300к записей, в некоторых случаях отсортировать (когда я не сумму ищу, а хочу посмотреть топ-10). А затем сумма по 300к в памяти и занимает добрую часть времени. Но это никак не 30 секунд, как описали Вы, а что-то около 1-2 секунд без кеширования. Причем количество записей у вас меньше чем у меня. Компьютер на котором у меня все это крутится — не передовой сервак. Серверу уже почти 5 лет ) Отсюда делаю вывод: вы неверно назначили\использовали индексы, что привело к такому результату. Покажите уже эксплейн этого запроса, в котором будет указано время выполнения и план. Тогда я смогу посмотреть, что использовались такие индексы, лучше их никак не сделать, время выполнения действительно 30 секунд.
PostgreSQL был протестирован сразу также. но он и близко не дал результаты в 1сек, Да быстрее чем MySQL но не идеально. К базе MS SQL был доступ, потому было очень интересно проверить что будет там. Думаю тоже самое выдаст и Oracle, эти базы практически одного уровня. Но вот минуса нахватал видимо упрекнув в чемто MySQL и похвалив MS SQL… старая добрая вражда против MS, почти что линух проти винды. странная порой реакцию у людей, И почемуто иметь базу данных на MS сервере для всех вызывает такой шок.
Да никакой связки то и нету :) с таким же успехом можно придраться, по поводу VBS и других вариантов.
просто тест производительности одинакового варинта кода в разных условиях. и все! был бы доступ к Oracle и другим базам, обязательно бы проверил. Потому и выложил в конце поста код скрипта, который можно импортировать в другую базу и проверить если у кого то есть под рукой. Это чисто сравнение и я не предлагал хозяевам проекта переходить на MS. Мой совет касательно базы, был только в генерации статичной развертки, дабы все будущие отчеты не мудрить на PHP коде девелоперам.
просто тест производительности одинакового варинта кода в разных условиях. и все! был бы доступ к Oracle и другим базам, обязательно бы проверил. Потому и выложил в конце поста код скрипта, который можно импортировать в другую базу и проверить если у кого то есть под рукой. Это чисто сравнение и я не предлагал хозяевам проекта переходить на MS. Мой совет касательно базы, был только в генерации статичной развертки, дабы все будущие отчеты не мудрить на PHP коде девелоперам.
Скажите, а сколько лет Вы администрируете MySQL, PostreSQL, MSSQL?
Шок вызывает неумение конфигурировать среду разработки под конкретные цели и задачи.
Подход «а давайте влупим быструю СУБД и добавим оперативы» без необходимой оптимизации — заведомо провальный. Ну и кривая архитектура приложения заодно. Бывают случаи, когда выгоднее пересмотреть архитектуру и переписать часть логики, чем сразу в омут с головой и смена платформы. Вы бы ещё готовое приложение на .NET предложили переписать.
Подход «а давайте влупим быструю СУБД и добавим оперативы» без необходимой оптимизации — заведомо провальный. Ну и кривая архитектура приложения заодно. Бывают случаи, когда выгоднее пересмотреть архитектуру и переписать часть логики, чем сразу в омут с головой и смена платформы. Вы бы ещё готовое приложение на .NET предложили переписать.
Вам тут объясняют: минусы вы нахватали не потому, что сравнили MySQL и MS SQL, а потому, что неправильно сравнили и делаете выводы на основании неправильного сравнения. Чтобы вашему некорректному сравнению не дай бог кто-нибудь не поверил, вас и минусуют.
а в чем суть неправельного сравнения? давайте забудем о PHP, и если речь идет чисто о базе даных, то каждому продукту свои задачи. Никто не будет предлагать ставить какойто форум на Oracle или SQL Server, это понятно всем. Но почемуто если вопрос идет касательно большой и быстро растучщей базе, при том что задача ее изначально под аналитику, т.е. это и кроссовые запросы, и pivot выводы, расчеты по периодам. и т.д. Мое мнение — MySQL не для таких задачь. Можете минусовать это ваше право, но для задачь со сложной аналитикой и большими данными, экономить на базе и все садить на MySQL, изначально неверное решение.
Иначе можно закрывать Oracle, SQL Server и другие, по вашим словам и всем будет прекрасно и бесплатно на MySQL. Зачем платить больше? Н упусть не 150 ms расчет а 5 sec, но зато бесплатно.
Иначе можно закрывать Oracle, SQL Server и другие, по вашим словам и всем будет прекрасно и бесплатно на MySQL. Зачем платить больше? Н упусть не 150 ms расчет а 5 sec, но зато бесплатно.
именно поэтому Oracle купил «бесплатную» MySQL
>> Иначе можно закрывать Oracle, SQL Server и другие, по вашим словам и всем будет прекрасно и бесплатно на MySQL. Зачем платить больше?
Да причем здесь платить, не платить. Вам пытаются объяснить, что Вы настраивать не умеете MySQL, но при этом делаете выводы о его производительности.
Да причем здесь платить, не платить. Вам пытаются объяснить, что Вы настраивать не умеете MySQL, но при этом делаете выводы о его производительности.
вы уж простите, но разве девелопер должен настраивать сервера? вы все ничего тут не перепутали? Я специально стараюсь как можно дальше держаться от настроек серверов. Мне хватает своей головной боли в моих задачах. А для серверов есть люди которые этим обязаны заниматься а не программисты. Или вы будете указывать каждому хостеру что без вашего вмешательтсва, все работать не будет. Я потому и проверял код на разных серверах. Да и кто я такой чтобы указывать хостерам 1and1, rackspace, goddady и т.д.? о чем вообще идет речь? почему пост о сравнении производительности при равных условиях и алгоритме, вызвал такую реацию и упреки изучать мат часть по установке и настройке серверов?
Я девелопер, я должен выжать из того что мне представленно, максимум скорости. И если тотже PHP тупит на обработке массивов и я это вижу, то я должен найти лучшее решение а не кидаться в админов и отписывать хозяину что PHP тормозит потому что у него сервер убогий, и пусть ищет сервер которые не 10сек будет считать, а 50ms.
Я девелопер, я должен выжать из того что мне представленно, максимум скорости. И если тотже PHP тупит на обработке массивов и я это вижу, то я должен найти лучшее решение а не кидаться в админов и отписывать хозяину что PHP тормозит потому что у него сервер убогий, и пусть ищет сервер которые не 10сек будет считать, а 50ms.
Я не на столько жесток к MySQL :)… и проверял скорость даже на своем компьютере, как в чистой среде, прямо с консоли без хоста. тоже делал и в виртуалке. Да я не проверял это под линухом. А всеголишь использовал несколько вариантов локальных хостов для теста: xamp, wampserver, open_server и usbWebserver. Плюс на двух доступных серверах: rackspace и goddady. Половина вариантов на втором запросе с SUM() по подзапросу, попросту слетало по таймауту не дождавшись.
SQL Server как я и сказал был в Web редакции… это бесплатная база от MS с самой низкой производительностью, да и сама виртуалка была на 1 ядро и 1 гиг мозгов. Да условия не равные, но и разница в скорости запредельная. чтобы заставить SQL Server подумать 10 сек, нужно было виртуалку видимо ставить на нетбук.
С Oracle справится не смог, времени не так много было, но было желание проверить и его всетаки
SQL Server как я и сказал был в Web редакции… это бесплатная база от MS с самой низкой производительностью, да и сама виртуалка была на 1 ядро и 1 гиг мозгов. Да условия не равные, но и разница в скорости запредельная. чтобы заставить SQL Server подумать 10 сек, нужно было виртуалку видимо ставить на нетбук.
С Oracle справится не смог, времени не так много было, но было желание проверить и его всетаки
Как «девелопер» — не знаю, а вот хороший инженер-программист должен понимать как работает его инструмент на максимально низком уровне. В идеале, PHP-программист должен знать принципы работы zend engine, особенно если он пишет какой-то масштабный и важный проект. Отсюда и познание в настройке сервера, как побочный продукт. А если уж на то пошло, то рядовому девелоперу не то что до настройки сервера, ему и на оптимизации кода особого дела нет.
Хотелось бы уточнить. У вас в первом запросе получается, что выдаст цепочку событий, где конец предыдущего события всегда будет началом следующего для каждого event_point. В таком случае напрашивается вывод, что у вас в запросе присутствуют всего 2 записи для каждого event_point. Так ли это?
Да верно. Это чтото типа: старт и стоп зажигания, включение и выключение поворотника, начало заправки и конец заправки. и все в таком духе. Потому нужно просто найти в списке завершение эвента который гдето ниже по времени.
База и проэкт не мой, потому задача стояла найти проблемы, а то что базу нужно было строить по другому это уже отдельный вопрос.
База и проэкт не мой, потому задача стояла найти проблемы, а то что базу нужно было строить по другому это уже отдельный вопрос.
В таком случае не было бы проще сделать так?
SELECT event_point, MIN(event_date) AS start_date, MAX(event_date) AS end_date FROM test_events as ev1
WHERE
ev1.event_date BETWEEN '2012-1-1' AND '2012-1-31' AND ev1.event_type IN (1, 2)
GROUP BY
event_point
Или «Да верно» относилось только к первой части моего комментария?
SELECT event_point, MIN(event_date) AS start_date, MAX(event_date) AS end_date FROM test_events as ev1
WHERE
ev1.event_date BETWEEN '2012-1-1' AND '2012-1-31' AND ev1.event_type IN (1, 2)
GROUP BY
event_point
Или «Да верно» относилось только к первой части моего комментария?
Запрос не совсем правильный, я его привел просто как пример, если что.
видимо мы друг друга не поняли.
за данный период, может быть много комбинаций между эвентами. т.е. тотже поворотник в машине, может включаться и выключаться много раз, но если поворотник идет подряд, то вот к примеру ближний свет, может иметь большую разницу по времени и иметь много других событий внутри, потому и нужно линковать таблицу подбирая ближний OFF для данного события.
И кстати при тестах MIN() проигрывал варианту с LIMIT во много раз для MySQL.
И даже допустим что вы сможете всетаки выиграть время комбинациями и получить более менее вам приемлемый результат, НО! вы уже не сможете в MySQL тутже получить сверху готовый подсчет без огромной потери времени. Т.е. то что я показал во втором примере с SUM(), где MS SQL справился без каких либо проблем. Я уверен что Oracle также с этим справится на томже уровне
за данный период, может быть много комбинаций между эвентами. т.е. тотже поворотник в машине, может включаться и выключаться много раз, но если поворотник идет подряд, то вот к примеру ближний свет, может иметь большую разницу по времени и иметь много других событий внутри, потому и нужно линковать таблицу подбирая ближний OFF для данного события.
И кстати при тестах MIN() проигрывал варианту с LIMIT во много раз для MySQL.
И даже допустим что вы сможете всетаки выиграть время комбинациями и получить более менее вам приемлемый результат, НО! вы уже не сможете в MySQL тутже получить сверху готовый подсчет без огромной потери времени. Т.е. то что я показал во втором примере с SUM(), где MS SQL справился без каких либо проблем. Я уверен что Oracle также с этим справится на томже уровне
Видимо да.
Насчет готового подсчета. MySQL используется в основном для горизонтально масштабируемых решений. Будет ли заметна разница во времени написания оптимального запроса, если эта таблица будет разделена партицированием на 10 таблиц раскиданных по 10 серверам? Потому что разница в стоимости между 10 серверами на MSSQL и на MySQL будет весьма заметна.
Насчет готового подсчета. MySQL используется в основном для горизонтально масштабируемых решений. Будет ли заметна разница во времени написания оптимального запроса, если эта таблица будет разделена партицированием на 10 таблиц раскиданных по 10 серверам? Потому что разница в стоимости между 10 серверами на MSSQL и на MySQL будет весьма заметна.
Исследование вы конечно провели, но пользы от этого очень мало.
Секрет MS SQL скорее всего кроется в начальной конфигурации сервера, мускул же из коробки настроен очень плохо, память сильно экономит и все операции сложные операции проводит через дисковые временные таблицы(есть подозрение что именно этим он и занимается иначе я не могу представить что можно без дисковых операций делать 30 секунд с 700к записей), а хотя мог бы это делать в оперативной памяти, если настройки тронуть.
700к записей это ни что для MySQL, даже с дефолтовыми настройками она должна была отрабатывать на ура, но не отработала потому что такие запросы не годятся для продакшна их можно только преподавателю на лабораторных работах показывать.
Надеюсь, что вы решили эти проблемы оптимизацией, а не портированием проблем на другую платформу
Секрет MS SQL скорее всего кроется в начальной конфигурации сервера, мускул же из коробки настроен очень плохо, память сильно экономит и все операции сложные операции проводит через дисковые временные таблицы(есть подозрение что именно этим он и занимается иначе я не могу представить что можно без дисковых операций делать 30 секунд с 700к записей), а хотя мог бы это делать в оперативной памяти, если настройки тронуть.
700к записей это ни что для MySQL, даже с дефолтовыми настройками она должна была отрабатывать на ура, но не отработала потому что такие запросы не годятся для продакшна их можно только преподавателю на лабораторных работах показывать.
Надеюсь, что вы решили эти проблемы оптимизацией, а не портированием проблем на другую платформу
Меня больше насторожило, потеря скорости при AJAX интерфейсе. Сейчас почти кажды йпроэкт строится на Ajax, и мало кто задумывается что происходит в JavaScript в загружаеммых страницах. Ведь подгружают не только чистый HTML, и вариантов с расчетами и кодом в JavaScript которые загружаются по Ajax дуаю можно найти в каждом втором проекте. А ведь потеря скорости просто огромна.
Собрав до кучи то что нашел, и все это в одном проэкте, вот и решил показать как пример, как можно убить проэкт, причем намертво.
Собрав до кучи то что нашел, и все это в одном проэкте, вот и решил показать как пример, как можно убить проэкт, причем намертво.
Ни разу вот не сталкивался с потерей производительности при AJAX запросах. Может я что-то делаю не так?
Поскольку eval Это зло в чистом виде, для загрузки скриптов я обычно пользуюсь тегом script (его можно спокойно создать хоть на нативном JS Хоть jQuery (хотя сейчас есть еще более крутой подход — WebWorkers). Если в кусках HTML закрадывается JS то уже по умолчанию у меня в мозгу появляется желание побыстрее избавиться от этого (JS код внутри HTML который передается по Ajax… вам не кажется что это глупо?). В идеале по AJAX передаются данные в формате JSON/XML и рендрятся уже на клиенте. Во всяком случае я стараюсь делать так всегда, если есть такая возможность.
Словом, ваше удивление мне непонятно.
Поскольку eval Это зло в чистом виде, для загрузки скриптов я обычно пользуюсь тегом script (его можно спокойно создать хоть на нативном JS Хоть jQuery (хотя сейчас есть еще более крутой подход — WebWorkers). Если в кусках HTML закрадывается JS то уже по умолчанию у меня в мозгу появляется желание побыстрее избавиться от этого (JS код внутри HTML который передается по Ajax… вам не кажется что это глупо?). В идеале по AJAX передаются данные в формате JSON/XML и рендрятся уже на клиенте. Во всяком случае я стараюсь делать так всегда, если есть такая возможность.
Словом, ваше удивление мне непонятно.
Ну так для чиво я и создавал тесты и выводил цифры? Все также потому что увидел это в коде который я анализировал. Потому и создал пост чтобы поделиться этими цифрами и тем кто это видит в первый раз, может помочь пересмотреть свои проекты. Про базу было упомянуто, только чтобы показать, почему девелоперы вместо базы засунули обработку в PHP снова создав проблему очередную.
Я для себя в тестах просто получил вполне интересные цифры, решил вот поделиться… в итоге 99% коментариев уперлось в MySQL и завал минусами. Т.е. вся собранная статистика чисто до одного места, и тут все 100% только Гуру находться. А значит мои старания были чисто бредом… чтож… понял, учту, и больше не буду так делать. Для себя нашел чтото, и и ладно, остальные и так все знают уже давно.
Я для себя в тестах просто получил вполне интересные цифры, решил вот поделиться… в итоге 99% коментариев уперлось в MySQL и завал минусами. Т.е. вся собранная статистика чисто до одного места, и тут все 100% только Гуру находться. А значит мои старания были чисто бредом… чтож… понял, учту, и больше не буду так делать. Для себя нашел чтото, и и ладно, остальные и так все знают уже давно.
Ценность данной статьи вполне могут представлять комментарии к ней. Надеюсь что и вы нашли среди них что-то познавательное, а это уже должно окупать затраченное время. Как минимум кто-то другой мог узнать что-то новое.
А по поводу MySQL vs MSSQL, то тут все просто. Продукты разных весовых категорий, разной сферы применения. Да и условия эксперемента как минимум не ясны, на производительность СУБД влияет очень много факторов. Как минимум отсутствие механизмов оптимизации подзапросов в MySQL (как было сказано, она была добавлена в MariaDB), нельзя посмотреть настройки (если у MySQL настройки по умолчанию то вполне возможно что именно в этом причина низкой производительности).
Касательно производительности PHP/JS/ASP/ASPX, то тут опять же много нюансов. Про JS даже говорить не буду, в PHP ситуацию могут исправить структуры SPL (на больших объемах данных дает неплохой прирост производительности), попробовать разные способы обхода массивов… Ведь в каждом языке свои особенности. Опять же ASPX это все же использует CLR, что по умолчанию должно показывать более высокие показатели нежели примитивная структура PHP. Так что копировать код влоб это не слишком интересная задумка. Намного интереснее выжать из каждого языка максимум при решении одной и той же задачи, и сравнить как само решение, так и производительность. Хотя большой разницы с полученными числами вряд-ли удастся добиться.
А по поводу MySQL vs MSSQL, то тут все просто. Продукты разных весовых категорий, разной сферы применения. Да и условия эксперемента как минимум не ясны, на производительность СУБД влияет очень много факторов. Как минимум отсутствие механизмов оптимизации подзапросов в MySQL (как было сказано, она была добавлена в MariaDB), нельзя посмотреть настройки (если у MySQL настройки по умолчанию то вполне возможно что именно в этом причина низкой производительности).
Касательно производительности PHP/JS/ASP/ASPX, то тут опять же много нюансов. Про JS даже говорить не буду, в PHP ситуацию могут исправить структуры SPL (на больших объемах данных дает неплохой прирост производительности), попробовать разные способы обхода массивов… Ведь в каждом языке свои особенности. Опять же ASPX это все же использует CLR, что по умолчанию должно показывать более высокие показатели нежели примитивная структура PHP. Так что копировать код влоб это не слишком интересная задумка. Намного интереснее выжать из каждого языка максимум при решении одной и той же задачи, и сравнить как само решение, так и производительность. Хотя большой разницы с полученными числами вряд-ли удастся добиться.
Коллеги, кто хорошо внутренности javascript знает, подскажите — почему разница в скорости с PHP на 2 порядка? Попробовал этот код на python — те же 7.5 секунды в варианте автора. Понятное дело что можно переписать сам алгоритм на поддерживаемые языком примитивы и операции для мгновенного выполнения — но два порядка разница в скорости для вложенного цикла с javascript настораживает.
По моим ощущениям MySQL не умеет оптимизировать вложенные SELECT'ы, поэтому их использование на больших таблицах весьма чревато. Ну и конфиг там из коробки не оптимальный для таких таблиц, да.
Вот к тому и шла речь. Одно дело просто выборки, а дальше на PHP творить расчеты как обычно. Другое дело сразу все посчитать прямо в базе. Тотже MS почемуто легко справляется и с более сложными вложениями и подзапросами. Я сижу на проэктах под MS SQL и потому заглянув в чужой проэкт, в первую очередь непонимал, почему не посчитать прямо в базе все, проверив разные варианты, а не только то что в примере, я убедился что MySQL чемто близкое к SQLite, т.е. простой вариант для простых задачь. И это такое зачастую по всему инету, очень много проэктов когда слодные задачи садят на все туже связку php+mysql. и потом играются настройками базы, хитростями на php и т.д. в тратится время клиента, тратится время разработки, с ростом данных начинаются переделки кусков кода. Т.е. выбрав неправельный шаг — потом нужно делать десятки.
Вы не смогли написать быстро работающий запрос, не смогли оптимизировать настройки MySQL под ваши данные, вместо этого вы выбросили всю мощь SQL-сервера и вручную лопатите данные в массиве.
Подход распространённый но непроизводительный. MySQL оттачивался годами, есть внедрения на которых он обрабатывает огромные объёмы данных, его разработкой сейчас занимается сам Oracle. Вы думаете что сможете всё это повторить в своём небольшом проекте? Вероятность этого ничтожна. Проще документацию почитать и нанять нормального скльщика.
Подход распространённый но непроизводительный. MySQL оттачивался годами, есть внедрения на которых он обрабатывает огромные объёмы данных, его разработкой сейчас занимается сам Oracle. Вы думаете что сможете всё это повторить в своём небольшом проекте? Вероятность этого ничтожна. Проще документацию почитать и нанять нормального скльщика.
Изначально хотелось поделиться цифрами касательно только Array в PHP и проблеме JavaScript под Prototype. Я столкнулся с такими проблемами в чужом коде, протестировал и выдал всем итог теста для информации. Проблема же MySQL была как отправная точка, которая повела разработчиков по дальнешим неверным шагам.
Но почемуто все комментарии свелись чисто к базе данных и моем тупизме в этом плане. Если весь пост был лишним, чтож… первая и последняя попытка была с моей стороны на хабре. Я для себа получил нужные мне данные. И для себя я знаю, что какбы я не мудрил с настройками базы и серверов, я никогда не буду делать сложный проэкт с аналитикой под базой третего эшелона. Есть для этого Oracle и SQL Server, за все года они ниразу не подводили, и позволяли выполнять просто сверх сложные задачи без потери производительности, и тучи ручного кода.
Опятьже, все почемуто свелось чисто к трениям вокруг базы данных. Если вы сможете довести MySQL до 1sec, чтож вы Гуру, я так не могу.
Но почемуто все комментарии свелись чисто к базе данных и моем тупизме в этом плане. Если весь пост был лишним, чтож… первая и последняя попытка была с моей стороны на хабре. Я для себа получил нужные мне данные. И для себя я знаю, что какбы я не мудрил с настройками базы и серверов, я никогда не буду делать сложный проэкт с аналитикой под базой третего эшелона. Есть для этого Oracle и SQL Server, за все года они ниразу не подводили, и позволяли выполнять просто сверх сложные задачи без потери производительности, и тучи ручного кода.
Опятьже, все почемуто свелось чисто к трениям вокруг базы данных. Если вы сможете довести MySQL до 1sec, чтож вы Гуру, я так не могу.
а зачем бегать по массиву? Ну вот по простому, в двух словах. Вопрос в незнании SQL (судя по боязливому упоминанию 3-х этажей)? Надо учить если работаешь с данными, да кода в конечном итоге будет только меньше.
много раз слышал про эти магические 5 строчек заменяющих большие и сложные конструкции на SQL, но ни разу не встречал.
типичная ошибка — смешивать получение данных с выводом их на экран. Это две разные задачи с разными требованиями.
Смотря с какой базой работали. Тотже SQL Server c учетом тех вкусностей что они выдали в 2012 базе, может решить все эти вопросы и с заголовками и с нумерацией внутри групп, как раз сталкивался, и причем довольно таки легко и без 20 запросов :) А если это делать через @таблицы то скорость просто великолепная. И насколько я понал в Oracle этов се тоже есть, как раз был спор что MS в 2012 базе добавили то, что уже было в Oracle
потому что слой приложения гораздо лучше (линейно) масштабируемый, чем БД
if("5468735354987"!="654654655465")Эээ? о_0
это просто нагрузка, чтобы небыло холостого хода. ведь в рабочем коде тоже ведь были разные проверки внутри. Причем !== от != ни чем не отличается по скорости, если что.
>> это просто нагрузка, чтобы небыло холостого хода.
Это Вы хитро придумали. Только C# выкинет эту часть кода, так как сравниваются константы.
Это Вы хитро придумали. Только C# выкинет эту часть кода, так как сравниваются константы.
если убрать ложную задачу, общая картина не изменится, проблема в самом core каждой платформы именно в работе с массивами. Также как и подмена $i++ vs ++$i влияет да доли ms в общей картине, но никак не спасает всю ситуацию в целом. 10sec это огромный предел, и PHP тут ничего не спасет, все игры и пути смогут сэкономить % но не общую проблему.
>> Также как и подмена $i++ vs ++$i влияет да доли ms в общей картине
А Вы проверяли?
Если убрать условие
то в PHP время выполнения сократится в 3 раза.
Если вернуть условие, но заменить его на:
то PHP время выполнения сократится в 2 раза.
А вот если наоборот вынести эти константы в переменные, то C# замедлится в 2 раза.
Я с Вами не спорю о том, что C# быстрее PHP. В это я верю.
Я Вам указываю на то, как Вы хитро подобрали тесты.
А Вы проверяли?
Если убрать условие
if("5468735354987" != "654654655465")то в PHP время выполнения сократится в 3 раза.
Если вернуть условие, но заменить его на:
if("asdfghjkl" != "qwertyuiop")то PHP время выполнения сократится в 2 раза.
А вот если наоборот вынести эти константы в переменные, то C# замедлится в 2 раза.
Я с Вами не спорю о том, что C# быстрее PHP. В это я верю.
Я Вам указываю на то, как Вы хитро подобрали тесты.
>> «хитро подобрали тесты»
нивкоем разе :) просто переписал за пару минут оригинал на другие платформы практически 1в1 без игры в тонкости каждой платформы а их хватает. Меня интересовал чисто вопрос работы самого массива, и просто, чтото вставил внутрь, чтобы оптимизатор той или иной платформы не выкинул кусок кода, и без всяких задних мыслей. мог просто 1!=2 вставить но показалось мало.
нивкоем разе :) просто переписал за пару минут оригинал на другие платформы практически 1в1 без игры в тонкости каждой платформы а их хватает. Меня интересовал чисто вопрос работы самого массива, и просто, чтото вставил внутрь, чтобы оптимизатор той или иной платформы не выкинул кусок кода, и без всяких задних мыслей. мог просто 1!=2 вставить но показалось мало.
>> нивкоем разе :) просто переписал за пару минут оригинал на другие платформы
Я рассматривал 2 варианта:
Теперь я вижу, что 2-ой вариант ближе к правде.
Я рассматривал 2 варианта:
- либо Вы очень хорошо разбираетесь в различных языках программирования и смогли все так подстроить, что один язык выглядит супер крутым, а другой не очень;
- либо это получилось случайно.
Теперь я вижу, что 2-ой вариант ближе к правде.
в задачу и в пост не входило холиварить, всеголишь выдача найденых моментов, которые встерчаются почти каждый день, ну и чисто поделится цифрами которые получились, ведь было ведь любопытно глянуть, как оно в других платформах.
К примеру тотже ASP не отреагировал на разницу JS и VB языка. Хотя есть задачи когда это влияет сильно, а в этом тесте выдал единное время на удивление, потому и не стал проверять в .NET разницу JS vs VB
К примеру тотже ASP не отреагировал на разницу JS и VB языка. Хотя есть задачи когда это влияет сильно, а в этом тесте выдал единное время на удивление, потому и не стал проверять в .NET разницу JS vs VB
В итоге, какое решение вы внедрили? Простые SQL запросы + циклы на стороне клиента на нативном js для построения отчёта?
А по второгому случаю с реплейсами, решение пока так и не нашлось?
А по второгому случаю с реплейсами, решение пока так и не нашлось?
Идеальным решением для того проэкта былобы заране свести таблицу эвентов на стороне сервера, толи по крону толи самой базой, и потом делать все выборки просто по статичной таблице. Даже учитывая что MS SQL выполняет это мгновенно, но всеравно такие операции лучше делать один раз, последующие запросы с SELECT SUM() ужеб несли совсем минимальную нагрузку.
Переделать базу или чтото кординально менять, отказались сам хозяева. Потому их отчеты были спасены вариантом переноса обработки кода в JavaScript, с учетом также вырезки и переноса всех JS кусков из Prototype в шапку интерфейса. Все отчеты начали летать буквально, при минимальных изминениях а также уже без каких либо лемитов по периоду времени. MySQL все также делает просто выборку, PHP собирает в массив и выдает темплейту, а сам интерфейс только запрашивает массив даных, загружая по ajax и уже строит графики выдавая все менее чем за считанные ms.
Replace осилить неудалось, как и писал выше, регулярка давала еще больш евремя, все хитрости которые писали н афорумах с разбивкой на мелкие массивы и обработку, также были с большей потерей скорости, ведь для ASP теже массивы еще хуже чем для PHP. Итогом стала серьезная работа по переделке самого генератора отчета, дабы сразу по ходу вписать нужные значения.
Переделать базу или чтото кординально менять, отказались сам хозяева. Потому их отчеты были спасены вариантом переноса обработки кода в JavaScript, с учетом также вырезки и переноса всех JS кусков из Prototype в шапку интерфейса. Все отчеты начали летать буквально, при минимальных изминениях а также уже без каких либо лемитов по периоду времени. MySQL все также делает просто выборку, PHP собирает в массив и выдает темплейту, а сам интерфейс только запрашивает массив даных, загружая по ajax и уже строит графики выдавая все менее чем за считанные ms.
Replace осилить неудалось, как и писал выше, регулярка давала еще больш евремя, все хитрости которые писали н афорумах с разбивкой на мелкие массивы и обработку, также были с большей потерей скорости, ведь для ASP теже массивы еще хуже чем для PHP. Итогом стала серьезная работа по переделке самого генератора отчета, дабы сразу по ходу вписать нужные значения.
не так страшна задача как ее решение :)
если explain select сделать, там хоть один индекс использоваться будет?
700к записей за 30сек — это ж при полном тейбл-скане, пустых кешах mysql и ОС, длине строки в 100 байт, скорость чтения с диска должна получаться чуть больше 2мб в секунду. Как-то слабо даже для рандомного чтения.
Я думаю, план запроса пролил бы свет на истину :)
если explain select сделать, там хоть один индекс использоваться будет?
700к записей за 30сек — это ж при полном тейбл-скане, пустых кешах mysql и ОС, длине строки в 100 байт, скорость чтения с диска должна получаться чуть больше 2мб в секунду. Как-то слабо даже для рандомного чтения.
Я думаю, план запроса пролил бы свет на истину :)
Отсутствие индексов в данном случае — это пол беды т.к. даже тейбл-скан по 700к записей для современного сервера — задача на пару секунд.
Скорее всего там творится какая-нибудь фантастика вроде джоина 700к временной таблицы с 700к основной таблицы без индекса. По моему опыту сабселекты — это вообще достаточно гнусная хрень, с ними не только у MySQL проблемы возникают, но и у вполне уважаемых БД вроде Sybase ASE и MSSQL.
Скорее всего там творится какая-нибудь фантастика вроде джоина 700к временной таблицы с 700к основной таблицы без индекса. По моему опыту сабселекты — это вообще достаточно гнусная хрень, с ними не только у MySQL проблемы возникают, но и у вполне уважаемых БД вроде Sybase ASE и MSSQL.
C индексами все ок. причеv создавался тест отдельно на подобии кода под MS SQL, пробовал разные варианты, игрался и с join и с другими вариантами, тотже выбор нужной записи по MIN() проигрывал в скорости в сравнении с LIMIT 1, в тоже время у SQL Server оказалось, все наоборот, MIN() выиграл в скорости у TOP 1.
Но тут больше время видимо у MySQL забирает нарезание памяти для подзапроса.
Дело в том что, если в под запрос добавить ограничение выборки повторив:
ev2.event_date BETWEEN '2012-1-1' AND '2012-1-31'
то время будет отличное, но так нельзя, иначе потеряются концовки событий, которые могут быть уже за пределами периода.
Также условие IF() или CASE() добавляют сложностей. Селив примере поставить статично type=1 (...type=2) то расчет будут почти идеальный, но это снов ане подходит, так как групп много, и у каждого эвента своя пара, потому и нужно указывать, для какого варианта, что является концом.
Вы все увидели просто выборку и все, и понеслась что я ламер и все остальное уже неважно.
Но тут больше время видимо у MySQL забирает нарезание памяти для подзапроса.
Дело в том что, если в под запрос добавить ограничение выборки повторив:
ev2.event_date BETWEEN '2012-1-1' AND '2012-1-31'
то время будет отличное, но так нельзя, иначе потеряются концовки событий, которые могут быть уже за пределами периода.
Также условие IF() или CASE() добавляют сложностей. Селив примере поставить статично type=1 (...type=2) то расчет будут почти идеальный, но это снов ане подходит, так как групп много, и у каждого эвента своя пара, потому и нужно указывать, для какого варианта, что является концом.
Вы все увидели просто выборку и все, и понеслась что я ламер и все остальное уже неважно.
Так добавьте в статью explain или хотя бы какие индексы есть на таблице
Речь вообще не шла о базе, база была как отправная точка у разработчиков и что и как они дальше намудрили в проекте. Как ни извращайся но второй суммарный запрос c SUM() вы не сможете на MySQL получить одним запросом даже за минуту. И снова пойдете на PHP доделывать то что впринципе долдна делать база, и снова попадетесь на проблемы самого PHP и его болезни с Array. И в итоге вся задача была, показать то что нашел, как сравнил и что пулучил… но неожидал такого холивара на хабре, стоило только в чемто упрекнуть MySQL и ее приминении.
Резюмируя всё, сто написано выше, могу сказать так:
Используй третью форму нормализации БД, Люк.
Аналогично можно сказать:
— используй индексы
— по возможности используй джоины вместо сабселектов
— настрой кеш, особенно для индексов
— да и вообще используй конфиг БД
— смотри план запроса, если что-то не так
я уверен, что любой из перечисленных советов решил бы проблему производительности первого SQL-запроса :)
— используй индексы
— по возможности используй джоины вместо сабселектов
— настрой кеш, особенно для индексов
— да и вообще используй конфиг БД
— смотри план запроса, если что-то не так
я уверен, что любой из перечисленных советов решил бы проблему производительности первого SQL-запроса :)
Еще раз. второй запрос с суммарным подсчетом вам MySQL не выдаст даже при любых индексах и любой оптимизации. Это ей просто не по силам. Линейные выборки да, но не суммарные из подзапросов. И дальее мы снова идем на PHP и считаем там.
А давайте выкатим базу в паблик (хотя бы урезанную, неполную версию) и докажем Вам, что всё возможно даже в таких условиях.
Просто я совершенно недавно решал задачу 1:1 c Вашей и решение было именно в индексах и грамотно поставленных запросах. PHP же производил минимальную обработку данных — банальные сортировки — и выдавал данные для построения графиков и таблиц. Причём на базе в over 1kk записей весь рендер на сервере и клиенте занимал от силы 3-4 секунды (период — год).
Просто я совершенно недавно решал задачу 1:1 c Вашей и решение было именно в индексах и грамотно поставленных запросах. PHP же производил минимальную обработку данных — банальные сортировки — и выдавал данные для построения графиков и таблиц. Причём на базе в over 1kk записей весь рендер на сервере и клиенте занимал от силы 3-4 секунды (период — год).
del
вот, можете играться, надеюсь не наделал ошибок перегоняя с SQL в MySQL.
сразу замечу что MS в самой простой и тупой Web редакции, без танцев с бубном войти чрез форточку вместо парадного входа — выполняет суммарный скрипт менее чем за 1 сек, в виртуалке с 1 ядром и 1гигом.
вот линк код
в комментах не дает столько текста вставить
сразу замечу что MS в самой простой и тупой Web редакции, без танцев с бубном войти чрез форточку вместо парадного входа — выполняет суммарный скрипт менее чем за 1 сек, в виртуалке с 1 ядром и 1гигом.
вот линк код
в комментах не дает столько текста вставить
Как я и думал, Вы не знаете как правильно составлять индексы. У Вас в любом случае идет перебор в памяти таблицы (хоть и не всей, часть Вы все таки отсекаете индексом). Отсюда и тормоза. Могу посоветовать хорошую книгу: MySQL оптимизация производительности
Она хоть и не дешевая, но Вы много узнаете нового. Да и основы индексирования поймете, что пригодится не только в mysql
Она хоть и не дешевая, но Вы много узнаете нового. Да и основы индексирования поймете, что пригодится не только в mysql
А меня поразило вот это:
То есть не обрабатывать здоровенный массив в несколько десятков (а то и сотен) тысяч элементов на сервере, а тупо отдать его на клиент?
Даже с современными скоростями Интернет большой массив данных на клиент будет грузиться несколько десятков секунд. А если клиент сидит через GPRS или чего еще похуже, он будет долго вспоминать вас нехорошими словами.
Решение понятно сразу — вырезать обработку массива из PHP и передать клиенту в массив, и там сделать расчет.
То есть не обрабатывать здоровенный массив в несколько десятков (а то и сотен) тысяч элементов на сервере, а тупо отдать его на клиент?
Даже с современными скоростями Интернет большой массив данных на клиент будет грузиться несколько десятков секунд. А если клиент сидит через GPRS или чего еще похуже, он будет долго вспоминать вас нехорошими словами.
Все зависит от целей. Насколько я понимаю это какой-то внутренний инструмент аналитики, так что «по GPRS» уж точно никто не будет туда залезать. Хотя решение сомнительное. Если над массивом не планируется производить множество операций, то стоит все же все обрабатывать на сервере. Во всяком случае было бы логично такой массив данных обрабатывать либо в C# либо на node.js.
чистый массив данных в цифрах, еще и ужатый gzip занимает копейки, было проверено, и клиент его даже по инету получает за считанные ms что фидлером и было проверено. в итоге получив только 1 строку массива, клиент далее может строить любые графики и таблицы, меняя отображение. а до этого при самый оптимальных переделках, для php+mysql не удавалось даже к 5 секундам приблизиться. Да ещ еи отчет ранее строился готовый, значит коиент получал HTML с чартами и т.д. а это все хуже и дольше чем полученный вариант обработки на JS.
И да — это спец проект для клиента был, и понятно что на простеньком планшете где АРМ6 никто пользоваться не собирается.
И да — это спец проект для клиента был, и понятно что на простеньком планшете где АРМ6 никто пользоваться не собирается.
Но как бы базы даже Вы берете разные, не говоря уже о платформах. Нет такого хостинга (ну хорошо, «почти не встретишь»), где есть и mysql, и mssql. Тем более, если столько записей, почему mysql, а не postgres? Да и о настройках ни слова нет…
Цифры в вашем случае впечатляют. Честно — вывод у меня обратный, «не надо на такие языки переносить такие задачи». Так и хочется попробовать то же посчитать в чисто статистическом пакете.
Цифры в вашем случае впечатляют. Честно — вывод у меня обратный, «не надо на такие языки переносить такие задачи». Так и хочется попробовать то же посчитать в чисто статистическом пакете.
не я строил и не я планнировал. моя задача состояла в том, чтобы найти проблемы и повозможности помочь исправить без глобальной переделки продукта и его заморозки. Что и былосделано, с небольшими изминениями, получена производительность в ms в сумме. Клиент доволен, заказчик доволен. продукт спасен, еще и на шару.
Да вот с изменениями-то как раз и хотелось понять, каковы же они.
Поясню: когда у людей все на php+mysql сделано, это часто значит, что ничего более интересного они не умели сделать. У Вас же сравнение происходит с несколькими разными языками и с БД другого уровня, и получается, что с «другим миром» сравниваете. Если разработку могли, не напрягаясь, сделать на такого рода платформе, то прямо не понятно, откуда php/mysql, если же пришлось для переделки нанимать спецов, то не совсем «нашару» результат. В общем, пытаюсь понять…
Поясню: когда у людей все на php+mysql сделано, это часто значит, что ничего более интересного они не умели сделать. У Вас же сравнение происходит с несколькими разными языками и с БД другого уровня, и получается, что с «другим миром» сравниваете. Если разработку могли, не напрягаясь, сделать на такого рода платформе, то прямо не понятно, откуда php/mysql, если же пришлось для переделки нанимать спецов, то не совсем «нашару» результат. В общем, пытаюсь понять…
почему выбор php+mysql? мне не ведомо. видимо это считается стандартом для многих, да и я восновном вижу в инете большую часть это php или asp.net и в очень редких случаях сервлеты. Видимо потому что линух, потому что бесплатно, и малоли что еще. Базу упомянул только чтобы показать что для аналитики люди не смогли осилить муську, и пошли стандартным путем, все считать на php. Я же сравнил с другой платформой, потому что было чисто любопытно, а что будет там с такой базой? Сам работаю большую часть под SQL Server и там практическинет проблем с размерами и временем, там восновном проблема это как правельно и что из возможного и как применить.
Т.е. еще раз уточню… база тут непричем. Сменить сервер возможности небыло, чтото кординально менять тоже, а спасать нужно было. Вот и была работа в поиске всех больных мест, а чисто для себя сравнения с другими платформами.
Да и не планировали все это специально… для себя они ограничивали в 7 дней и жили с этим. Случайно так вышло, что мне получилось взглянуть и стало инетресно почему так много времени. Попробовал базу, ужасно долго, со своей стороны решить эту проблему не мог не имея доступа к базе. Начал ковырять дальше, увидел обработки огромных масивов на PHP и ужасные тормоза… также начал выяснять и для себя сравнить в других платформах, так как есть другие задачи на asp.net и node.js… что ыбло под рукой и легко перекинуть то по быстром уи проверил. Цифры были очень интересные, решил поделиться… за что нахватал минусов по самые нехочу.
Решение проблемы, было таким:
— в базе оставить только выборку линейную, время в ms
— в php забрать данные с базы удалив все обработки и отдать ввиде data[] массива через ajax клиенту, также время на затраты в ms
— в интерфейсе сидит function переписанная из php в javascript, которая считает всю аналитику за 110ms настороне клиента, тутже создав чарты, плюс возмодность по разнымопциям перерисовать чарты. имея исходники данных а не только суммарные, JS на клиенте может с легкостью за 110ms снова все пересчитать уже по другим группам, хоть по дням, хоть по месяцам, хоть сами группы превернуть… т.е. имеем полностью динамичный клиент, без лишнего обращения к серверу и без потери времени на расчеты.
т.е. в итоге получилось даже лучше, чем есле бы удалось домучать mysql. JavaScript на стороне клиента в чистом виде, позволяет совершать довольно большие расчеты и тутже все отображать не обращаясь к серверной части.
Как помне, то в идеале иметь серверную часть на nodejs+mongodb чисто для приема и выдачи даных клиенту. а все остальное это JS и темплейты, которые один раз загружаются либами, а далее получая только чистые данные от срвера, можно строить и рисовать как душе угодно. Клиент считает все с легкостью, сервер почти полностью разгружен от лишних запросов. gzip доводит размер общения клиента и сервера до смешных пакетов.
Т.е. еще раз уточню… база тут непричем. Сменить сервер возможности небыло, чтото кординально менять тоже, а спасать нужно было. Вот и была работа в поиске всех больных мест, а чисто для себя сравнения с другими платформами.
Да и не планировали все это специально… для себя они ограничивали в 7 дней и жили с этим. Случайно так вышло, что мне получилось взглянуть и стало инетресно почему так много времени. Попробовал базу, ужасно долго, со своей стороны решить эту проблему не мог не имея доступа к базе. Начал ковырять дальше, увидел обработки огромных масивов на PHP и ужасные тормоза… также начал выяснять и для себя сравнить в других платформах, так как есть другие задачи на asp.net и node.js… что ыбло под рукой и легко перекинуть то по быстром уи проверил. Цифры были очень интересные, решил поделиться… за что нахватал минусов по самые нехочу.
Решение проблемы, было таким:
— в базе оставить только выборку линейную, время в ms
— в php забрать данные с базы удалив все обработки и отдать ввиде data[] массива через ajax клиенту, также время на затраты в ms
— в интерфейсе сидит function переписанная из php в javascript, которая считает всю аналитику за 110ms настороне клиента, тутже создав чарты, плюс возмодность по разнымопциям перерисовать чарты. имея исходники данных а не только суммарные, JS на клиенте может с легкостью за 110ms снова все пересчитать уже по другим группам, хоть по дням, хоть по месяцам, хоть сами группы превернуть… т.е. имеем полностью динамичный клиент, без лишнего обращения к серверу и без потери времени на расчеты.
т.е. в итоге получилось даже лучше, чем есле бы удалось домучать mysql. JavaScript на стороне клиента в чистом виде, позволяет совершать довольно большие расчеты и тутже все отображать не обращаясь к серверной части.
Как помне, то в идеале иметь серверную часть на nodejs+mongodb чисто для приема и выдачи даных клиенту. а все остальное это JS и темплейты, которые один раз загружаются либами, а далее получая только чистые данные от срвера, можно строить и рисовать как душе угодно. Клиент считает все с легкостью, сервер почти полностью разгружен от лишних запросов. gzip доводит размер общения клиента и сервера до смешных пакетов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Черные дыры при разработке Веб проекта