Comments (26)
@lauripiisang Would you be interested in moving that repository to this org? You could continue to maintain the collector, and we could work together to slim down this project to not contain the collector code.
from xhgui.
So that's a dead easy way to solve the problem short term.
I think a bigger question is: Should we split the data collector and UI into separate projects. The former requires xhprof, the latter doesn't. The latter requires mongo, the former doesn't.
from xhgui.
Well from architectonic point of view that would be an ideal solution to divide it into "data collector" and "plain GUI", the question is how many users want or need this kind of functionality.
But IMO: I think that not many PHP projects use MongoDB on the live environment and make this memory consumer running all the time "just for profiling" is not ideal way. Also on some environments you might not be able to run your own Mongo and data collector just needs xhprof. We want to put the files in the directory and make CRON scp them and import using the tool your project contains automatically. And on your local where you can display all the info you need you are able to run whatever you wish. So I will never use the GUI on server and I will never use the xhprof on my local...
So for me the split would be perfect but only in case that people need it ( I do :-) )
from xhgui.
I think a split might work well. If we add more libraries to xhgui, I'd like a way to not bog down the host application with those dependencies.
One tricky bit with splitting the project up into a collector and UI, is how to manage configuration?
from xhgui.
Hrm.
The collector needs xhprof, and the display needs mongo. How granular can we get with composer? Like could we mark them both as required and somehow tag things as non-functional if they're not there? So they'd install the same package twice, but get clear indication regarding functionality?
from xhgui.
composer will require separate repos for each package. It doesn't have a way of making multiple packages out of one repository.
from xhgui.
Still you can make it as THREE packages (repos)
- Collector
- GUI
- remains like this one but does not have almost any code and only declares these two as a requirement so people can go on with using that as they were used to
from xhgui.
Another option is to do what symfony and laravel do, and automate some subtree splits. I don't know how having the gui as a separate package will work for people as the webroot directory will move around, as will cache & config files.
from xhgui.
What if we had one package/repo, then marked both XHProf and MongoDB as optional. Then just appropriately tagged the components (data collector/presenter) as non-functional without the various elements.
from xhgui.
Thats a reasonable option I think.
from xhgui.
Hi,
It was possible to install xhgui
as a dependency without having ext-mongo
installed for quite a long time. However, in commit c3a3f43
, a new dependency has been added:
c3a3f43#diff-b5d0ee8c97c7abd7e3fa29b9a27d1780R17
I am not sure what the reason for adding the dependency was. I can't see anything from the commit itself. It'd be great if we can maintain xhgui
as a data-capture tool, as suggested earlier in this thread, and separate the data-display logic. I guess I am not the only guy who wants to run xhgui-based profiling on the production machines, while not having ext-mongo
installed there.
from xhgui.
@pavelsmolka I can move that dependency into suggest. Splitting xhgui up might be an option in the future. I don't have a ton of time to do that right now though.
from xhgui.
Hi, I have created a pull request, with simply moving the Mongo dependency to the "suggest" section of composer.json
. I have briefly checked the code, and I'm not sure whether some more changes need to be introduced for this MR to be accepted. I'm happy to put a bit more work into this, if you guide me into the right direction.
from xhgui.
Digging up graves, but FWIW, as @kuncajs proposed, I have extracted the minimal amount of code needed to provide a data collector
from XHGUI project.
This is version-agnostic, should work on PHP 5.3 - 7.1 and doesn't modify (aside from deleting) the original code.
see https://github.com/lauripiisang/xhgui-data-collector
There's a version up on packagist as well.
Got scrutinizer rank up to 10.0 :)
from xhgui.
@markstory I don't see why not. the current project is just a very basic teardown of the unnecessaries with compatibility in mind, but I'd love for it to evolve into something more.
How do we go about doing that?
P.S. on a different topic - please create tagged releases of xhgui
project on packagist!
from xhgui.
P.S. on a different topic - please create tagged releases of xhgui project on packagist!
There has been a recent change to remove the version key in the composer.json that should fix tags not getting picked up going forward. There doesn't seem to be a way to backfill existing tags into packagist though.
from xhgui.
from xhgui.
It doesn't. I pushed that button a few times last night π’. Could packagist not be finding the tags because the old tags are prefixed with v
?
from xhgui.
packagist tag problem solved: #199 (comment)
from xhgui.
I've pushed lauripiisang/xhgui-data-collector to perftools/xhgui-collector, but there are some issues to resolve:
perftools/xhgui-collector#1
from xhgui.
It looks like perftools/xhgui should at least depend on perftools/xhgui-collector. Rather than the code being duplicated. This would also keep perftools/xhgui backwards compatible with existing usage. The main concern is that the collector used in production is minimal.
from xhgui.
common parts should be moved to separate library instead. this was also @lauripiisang opinion.
but this is likely not worked on (beside lack of time/interest/profit) because it would be major breakage for people who do not use composer for xhgui installation. currently it's standalone, no external (composer) dependencies.
this could be solved two ways:
- introduce major version, which requires composer
- upload tarballs to releases which contain dependencies (result of
composer install --no-dev
)
from xhgui.
I think requiring composer might be an option now. Back when this project started, I don't think composer was as widely used as it is today. Making tarballs for releases isn't that hard either. I have some make scripts to do just that from automating releases in CakePHP.
from xhgui.
We could have some plans for major version then in general, like PSR-4 compatibility and perhaps some restructuring, better error handling.
WDYT?
Perhaps we should consolidate these under an issue.
from xhgui.
We could have some plans for major version then in general, like PSR-4 compatibility and perhaps some restructuring, better error handling.
Perhaps we should consolidate these under an issue.
Sounds like a plan. I think there are a bunch of things we can and should improve.
from xhgui.
perftools/xhgui-collector has been created, which is now superseded by perftools/php-profiler package.
from xhgui.
Related Issues (20)
- NetData/DirectAdmin/Ubuntu integration
- PHP files in docker 0.18.0 image aren't readable to www-data user HOT 2
- Removed Profile::getCallgraphNodes method in use HOT 1
- Can't auth with mongodb HOT 14
- redirects after run delete do not honor 'path.prefix' HOT 5
- Docker Hub images HOT 14
- Error on callgraph for profile on symfony based project HOT 1
- PHP 8.1 Support HOT 19
- About PDO JSON support HOT 14
- dockerηζ¬ηbug: { "error": true, "message": "Failed to decode payload" }
- Missing required parameter in RunController:274 HOT 3
- Export Call Graph
- docker: Cannot import `.xhprof` files - PHP Fatal error: require(): Failed opening required xhgui/external/../vendor/autoload.php' HOT 7
- Fatal error: Uncaught TypeError: Return value of XHGui\ServiceProvider\ServiceProvider::setupPaths() must be an instance HOT 4
- upgrade symfony/options-resolver HOT 1
- PHP8.2 Compatibility for xhgui-collector HOT 1
- Request for Support: Implementing php-twig v3.x Compatibility in XHGui HOT 2
- Changing the ip of the mongo container
- mongo The requested image's platform (linux/amd64) does not match the detected host platform HOT 1
- Add Buggregator to README (OpenSource Tool for Analyzing xhprof profiles)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from xhgui.