Closed kuncajs closed 4 years ago
preinheimer
commented
10 years ago 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.
kuncajs
commented
10 years ago 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 :-) )
markstory
commented
10 years ago 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?
preinheimer
commented
10 years ago 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?
markstory
commented
10 years ago composer will require separate repos for each package. It doesn't have a way of making multiple packages out of one repository.
kuncajs
commented
10 years ago Still you can make it as THREE packages (repos) 1) Collector 2) GUI 3) 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
markstory
commented
10 years ago 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.
preinheimer
commented
10 years ago 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.
markstory
commented
10 years ago Thats a reasonable option I think.
pavelsmolka
commented
8 years ago 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:
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.
markstory
commented
8 years ago @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.
pavelsmolka
commented
8 years ago 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.
lauripiisang
commented
7 years ago 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 :)
markstory
commented
7 years ago @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.
lauripiisang
commented
7 years ago @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!
markstory
commented
7 years ago 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.
lauripiisang
commented
7 years ago Clicking "update" in the project view should refresh all references
On Apr 5, 2017 19:06, "Mark Story" notifications@github.com wrote:
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.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/perftools/xhgui/issues/85#issuecomment-291911198, or mute the thread https://github.com/notifications/unsubscribe-auth/AFWAyUFHLOVRYUigD26pK53UL9AiT16zks5rs7wXgaJpZM4BZ6Mj .
markstory
commented
7 years ago It doesn't. I pushed that button a few times last night :cry:. Could packagist not be finding the tags because the old tags are prefixed with v?
glensc
commented
7 years ago packagist tag problem solved: https://github.com/perftools/xhgui/pull/199#issuecomment-291960753
lauripiisang
commented
7 years ago I've pushed lauripiisang/xhgui-data-collector to perftools/xhgui-collector, but there are some issues to resolve: https://github.com/perftools/xhgui-collector/issues/1
Krinkle
commented
6 years ago 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.
glensc
commented
6 years ago 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:
composer install --no-dev)markstory
commented
6 years ago 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.
lauripiisang
commented
6 years ago 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.
markstory
commented
6 years ago 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.
glensc
commented
4 years ago perftools/xhgui-collector has been created, which is now superseded by perftools/php-profiler package.
Hello developers, as even your installation guide says you can use xhgui even when you do not have access to mongoDB directly. This is exactly our case - we do not want to run mongo on our production just for profiling, instead of it we would like to generate files, download them periodically and analyze locally, however we will not be able to compose this project as dependency in composer on production because this project has ext-mongo as a requirement.
It is not a requirement though as you CAN run without it and you even suggest it in the manual. Do you think it would be wise to remove this dependency? Otherwise I will need to fork :-) Thank you!
PS I forgot to show some appreciation. The project is very nice, GUI working, callgraph interactive (!) and everything works. This XHProf GUI is much better than the other ones I tried. Thanks, guys!