Я не на столько жесток к MySQL :)… и проверял скорость даже на своем компьютере, как в чистой среде, прямо с консоли без хоста. тоже делал и в виртуалке. Да я не проверял это под линухом. А всеголишь использовал несколько вариантов локальных хостов для теста: xamp, wampserver, open_server и usbWebserver. Плюс на двух доступных серверах: rackspace и goddady. Половина вариантов на втором запросе с SUM() по подзапросу, попросту слетало по таймауту не дождавшись.
SQL Server как я и сказал был в Web редакции… это бесплатная база от MS с самой низкой производительностью, да и сама виртуалка была на 1 ядро и 1 гиг мозгов. Да условия не равные, но и разница в скорости запредельная. чтобы заставить SQL Server подумать 10 сек, нужно было виртуалку видимо ставить на нетбук.
С Oracle справится не смог, времени не так много было, но было желание проверить и его всетаки
Вы явно не поняли. в тесте чистое время обработки массива без учета Ajax. Там проблема не во времени загрузки, а в выполнении JavaScript кода через eval(). Я не рылся в глубиннах prototype и jquery и видимо подход совершенно разный, и скорее всего первый парсит на строки или куски выполняя eval() а второй видммо делает это целиком. Но это тллько пога догадки.
вы уж простите, но разве девелопер должен настраивать сервера? вы все ничего тут не перепутали? Я специально стараюсь как можно дальше держаться от настроек серверов. Мне хватает своей головной боли в моих задачах. А для серверов есть люди которые этим обязаны заниматься а не программисты. Или вы будете указывать каждому хостеру что без вашего вмешательтсва, все работать не будет. Я потому и проверял код на разных серверах. Да и кто я такой чтобы указывать хостерам 1and1, rackspace, goddady и т.д.? о чем вообще идет речь? почему пост о сравнении производительности при равных условиях и алгоритме, вызвал такую реацию и упреки изучать мат часть по установке и настройке серверов?
Я девелопер, я должен выжать из того что мне представленно, максимум скорости. И если тотже PHP тупит на обработке массивов и я это вижу, то я должен найти лучшее решение а не кидаться в админов и отписывать хозяину что PHP тормозит потому что у него сервер убогий, и пусть ищет сервер которые не 10сек будет считать, а 50ms.
Смотря с какой базой работали. Тотже SQL Server c учетом тех вкусностей что они выдали в 2012 базе, может решить все эти вопросы и с заголовками и с нумерацией внутри групп, как раз сталкивался, и причем довольно таки легко и без 20 запросов :) А если это делать через @таблицы то скорость просто великолепная. И насколько я понал в Oracle этов се тоже есть, как раз был спор что MS в 2012 базе добавили то, что уже было в Oracle
а в чем суть неправельного сравнения? давайте забудем о PHP, и если речь идет чисто о базе даных, то каждому продукту свои задачи. Никто не будет предлагать ставить какойто форум на Oracle или SQL Server, это понятно всем. Но почемуто если вопрос идет касательно большой и быстро растучщей базе, при том что задача ее изначально под аналитику, т.е. это и кроссовые запросы, и pivot выводы, расчеты по периодам. и т.д. Мое мнение — MySQL не для таких задачь. Можете минусовать это ваше право, но для задачь со сложной аналитикой и большими данными, экономить на базе и все садить на MySQL, изначально неверное решение.
Иначе можно закрывать Oracle, SQL Server и другие, по вашим словам и всем будет прекрасно и бесплатно на MySQL. Зачем платить больше? Н упусть не 150 ms расчет а 5 sec, но зато бесплатно.
Да никакой связки то и нету :) с таким же успехом можно придраться, по поводу VBS и других вариантов.
просто тест производительности одинакового варинта кода в разных условиях. и все! был бы доступ к Oracle и другим базам, обязательно бы проверил. Потому и выложил в конце поста код скрипта, который можно импортировать в другую базу и проверить если у кого то есть под рукой. Это чисто сравнение и я не предлагал хозяевам проекта переходить на MS. Мой совет касательно базы, был только в генерации статичной развертки, дабы все будущие отчеты не мудрить на PHP коде девелоперам.
PostgreSQL был протестирован сразу также. но он и близко не дал результаты в 1сек, Да быстрее чем MySQL но не идеально. К базе MS SQL был доступ, потому было очень интересно проверить что будет там. Думаю тоже самое выдаст и Oracle, эти базы практически одного уровня. Но вот минуса нахватал видимо упрекнув в чемто MySQL и похвалив MS SQL… старая добрая вражда против MS, почти что линух проти винды. странная порой реакцию у людей, И почемуто иметь базу данных на MS сервере для всех вызывает такой шок.
Идеальным решением для того проэкта былобы заране свести таблицу эвентов на стороне сервера, толи по крону толи самой базой, и потом делать все выборки просто по статичной таблице. Даже учитывая что MS SQL выполняет это мгновенно, но всеравно такие операции лучше делать один раз, последующие запросы с SELECT SUM() ужеб несли совсем минимальную нагрузку.
Переделать базу или чтото кординально менять, отказались сам хозяева. Потому их отчеты были спасены вариантом переноса обработки кода в JavaScript, с учетом также вырезки и переноса всех JS кусков из Prototype в шапку интерфейса. Все отчеты начали летать буквально, при минимальных изминениях а также уже без каких либо лемитов по периоду времени. MySQL все также делает просто выборку, PHP собирает в массив и выдает темплейту, а сам интерфейс только запрашивает массив даных, загружая по ajax и уже строит графики выдавая все менее чем за считанные ms.
Replace осилить неудалось, как и писал выше, регулярка давала еще больш евремя, все хитрости которые писали н афорумах с разбивкой на мелкие массивы и обработку, также были с большей потерей скорости, ведь для ASP теже массивы еще хуже чем для PHP. Итогом стала серьезная работа по переделке самого генератора отчета, дабы сразу по ходу вписать нужные значения.
это просто нагрузка, чтобы небыло холостого хода. ведь в рабочем коде тоже ведь были разные проверки внутри. Причем !== от != ни чем не отличается по скорости, если что.
Изначально хотелось поделиться цифрами касательно только Array в PHP и проблеме JavaScript под Prototype. Я столкнулся с такими проблемами в чужом коде, протестировал и выдал всем итог теста для информации. Проблема же MySQL была как отправная точка, которая повела разработчиков по дальнешим неверным шагам.
Но почемуто все комментарии свелись чисто к базе данных и моем тупизме в этом плане. Если весь пост был лишним, чтож… первая и последняя попытка была с моей стороны на хабре. Я для себа получил нужные мне данные. И для себя я знаю, что какбы я не мудрил с настройками базы и серверов, я никогда не буду делать сложный проэкт с аналитикой под базой третего эшелона. Есть для этого Oracle и SQL Server, за все года они ниразу не подводили, и позволяли выполнять просто сверх сложные задачи без потери производительности, и тучи ручного кода.
Опятьже, все почемуто свелось чисто к трениям вокруг базы данных. Если вы сможете довести MySQL до 1sec, чтож вы Гуру, я так не могу.
Речь вообще не о игре в настройки и попытке вытащить по пару процентов производительности. Или вы сможете второй вариант запросы с подсчетом SUM из вложенного запроса, выполнить хотябы близкое к 1 сек? даже 5 сек, при выборе за месяц это уже катастрофа. А при выборе за пол года или год, MySQL просто умрет. И снова начинаем играться в изобретения велосипеда. Для аналитики и больших расчетов, есть подходящие для этого базы. С таким успехом можно взять MongoDB и там начать играться в лего. Ктото и на SQLite умудряется посадить задачи с аналитикой, зато мол мобильность и бесплатность.
Вот к тому и шла речь. Одно дело просто выборки, а дальше на PHP творить расчеты как обычно. Другое дело сразу все посчитать прямо в базе. Тотже MS почемуто легко справляется и с более сложными вложениями и подзапросами. Я сижу на проэктах под MS SQL и потому заглянув в чужой проэкт, в первую очередь непонимал, почему не посчитать прямо в базе все, проверив разные варианты, а не только то что в примере, я убедился что MySQL чемто близкое к SQLite, т.е. простой вариант для простых задачь. И это такое зачастую по всему инету, очень много проэктов когда слодные задачи садят на все туже связку php+mysql. и потом играются настройками базы, хитростями на php и т.д. в тратится время клиента, тратится время разработки, с ростом данных начинаются переделки кусков кода. Т.е. выбрав неправельный шаг — потом нужно делать десятки.
видимо мы друг друга не поняли.
за данный период, может быть много комбинаций между эвентами. т.е. тотже поворотник в машине, может включаться и выключаться много раз, но если поворотник идет подряд, то вот к примеру ближний свет, может иметь большую разницу по времени и иметь много других событий внутри, потому и нужно линковать таблицу подбирая ближний OFF для данного события.
И кстати при тестах MIN() проигрывал варианту с LIMIT во много раз для MySQL.
И даже допустим что вы сможете всетаки выиграть время комбинациями и получить более менее вам приемлемый результат, НО! вы уже не сможете в MySQL тутже получить сверху готовый подсчет без огромной потери времени. Т.е. то что я показал во втором примере с SUM(), где MS SQL справился без каких либо проблем. Я уверен что Oracle также с этим справится на томже уровне
Меня больше насторожило, потеря скорости при AJAX интерфейсе. Сейчас почти кажды йпроэкт строится на Ajax, и мало кто задумывается что происходит в JavaScript в загружаеммых страницах. Ведь подгружают не только чистый HTML, и вариантов с расчетами и кодом в JavaScript которые загружаются по Ajax дуаю можно найти в каждом втором проекте. А ведь потеря скорости просто огромна.
Собрав до кучи то что нашел, и все это в одном проэкте, вот и решил показать как пример, как можно убить проэкт, причем намертво.
Да верно. Это чтото типа: старт и стоп зажигания, включение и выключение поворотника, начало заправки и конец заправки. и все в таком духе. Потому нужно просто найти в списке завершение эвента который гдето ниже по времени.
База и проэкт не мой, потому задача стояла найти проблемы, а то что базу нужно было строить по другому это уже отдельный вопрос.
Проэкт был чужой и потому находя проблемные места, сразу сравнивал с другими вариантами. Доступ к настройкам сервера получить не удалось, да и запуск налокальном сервере показал все теже проблемы. При том что MS SQL сервер сидел в виртуалке, с ограниченными ресурсами, да и сама редакция Web сильно урезана, но ей это не мешает выплнять гараздо сложные запросы и при гараздо больше данных, с легкостью.
MySQL тестировал на совершенно разных трех вариантах серверов… думаю статистически уже понятно что MySQL даже близко не сможет снизить время до MS SQL, поэтому игра в милисекунды уже не существенна. Даже вместо 30сек получить 15сек, все также убивает проэкт, это не 1сек.
Показать цифры тестов которые я собрал, а также те проблемные места, с которыми можно столкнуться. Тотже Prototype встерчается очень часто, когда задачи мелкие оно не видно, и порой девелоперы не понимают куда убегает время.
Тоже касается и базы, когда сложные расчеты запихивают в PHP надеясь что PHP с легкостью с этим справится, но на самом деле оказывается что PHP как раз болеет скоростью в аналитике.
SQL Server как я и сказал был в Web редакции… это бесплатная база от MS с самой низкой производительностью, да и сама виртуалка была на 1 ядро и 1 гиг мозгов. Да условия не равные, но и разница в скорости запредельная. чтобы заставить SQL Server подумать 10 сек, нужно было виртуалку видимо ставить на нетбук.
С Oracle справится не смог, времени не так много было, но было желание проверить и его всетаки
Я девелопер, я должен выжать из того что мне представленно, максимум скорости. И если тотже PHP тупит на обработке массивов и я это вижу, то я должен найти лучшее решение а не кидаться в админов и отписывать хозяину что PHP тормозит потому что у него сервер убогий, и пусть ищет сервер которые не 10сек будет считать, а 50ms.
Иначе можно закрывать Oracle, SQL Server и другие, по вашим словам и всем будет прекрасно и бесплатно на MySQL. Зачем платить больше? Н упусть не 150 ms расчет а 5 sec, но зато бесплатно.
просто тест производительности одинакового варинта кода в разных условиях. и все! был бы доступ к Oracle и другим базам, обязательно бы проверил. Потому и выложил в конце поста код скрипта, который можно импортировать в другую базу и проверить если у кого то есть под рукой. Это чисто сравнение и я не предлагал хозяевам проекта переходить на MS. Мой совет касательно базы, был только в генерации статичной развертки, дабы все будущие отчеты не мудрить на PHP коде девелоперам.
Переделать базу или чтото кординально менять, отказались сам хозяева. Потому их отчеты были спасены вариантом переноса обработки кода в JavaScript, с учетом также вырезки и переноса всех JS кусков из Prototype в шапку интерфейса. Все отчеты начали летать буквально, при минимальных изминениях а также уже без каких либо лемитов по периоду времени. MySQL все также делает просто выборку, PHP собирает в массив и выдает темплейту, а сам интерфейс только запрашивает массив даных, загружая по ajax и уже строит графики выдавая все менее чем за считанные ms.
Replace осилить неудалось, как и писал выше, регулярка давала еще больш евремя, все хитрости которые писали н афорумах с разбивкой на мелкие массивы и обработку, также были с большей потерей скорости, ведь для ASP теже массивы еще хуже чем для PHP. Итогом стала серьезная работа по переделке самого генератора отчета, дабы сразу по ходу вписать нужные значения.
Но почемуто все комментарии свелись чисто к базе данных и моем тупизме в этом плане. Если весь пост был лишним, чтож… первая и последняя попытка была с моей стороны на хабре. Я для себа получил нужные мне данные. И для себя я знаю, что какбы я не мудрил с настройками базы и серверов, я никогда не буду делать сложный проэкт с аналитикой под базой третего эшелона. Есть для этого Oracle и SQL Server, за все года они ниразу не подводили, и позволяли выполнять просто сверх сложные задачи без потери производительности, и тучи ручного кода.
Опятьже, все почемуто свелось чисто к трениям вокруг базы данных. Если вы сможете довести MySQL до 1sec, чтож вы Гуру, я так не могу.
за данный период, может быть много комбинаций между эвентами. т.е. тотже поворотник в машине, может включаться и выключаться много раз, но если поворотник идет подряд, то вот к примеру ближний свет, может иметь большую разницу по времени и иметь много других событий внутри, потому и нужно линковать таблицу подбирая ближний OFF для данного события.
И кстати при тестах MIN() проигрывал варианту с LIMIT во много раз для MySQL.
И даже допустим что вы сможете всетаки выиграть время комбинациями и получить более менее вам приемлемый результат, НО! вы уже не сможете в MySQL тутже получить сверху готовый подсчет без огромной потери времени. Т.е. то что я показал во втором примере с SUM(), где MS SQL справился без каких либо проблем. Я уверен что Oracle также с этим справится на томже уровне
Собрав до кучи то что нашел, и все это в одном проэкте, вот и решил показать как пример, как можно убить проэкт, причем намертво.
База и проэкт не мой, потому задача стояла найти проблемы, а то что базу нужно было строить по другому это уже отдельный вопрос.
MySQL тестировал на совершенно разных трех вариантах серверов… думаю статистически уже понятно что MySQL даже близко не сможет снизить время до MS SQL, поэтому игра в милисекунды уже не существенна. Даже вместо 30сек получить 15сек, все также убивает проэкт, это не 1сек.
Тоже касается и базы, когда сложные расчеты запихивают в PHP надеясь что PHP с легкостью с этим справится, но на самом деле оказывается что PHP как раз болеет скоростью в аналитике.