Eclipse webtools projet (WTP) et sa performance / qualité
Notre société est à l'aide d'eclipse depuis plusieurs années maintenant (nous sommes à l'aide de WTP depuis la version 0.7)
Je suis actuellement en train d'évaluer eclipse 3.6.2 avec WTP 3.2.3 qui devrait remplacer eclipse 3.4.2 avec WTP 3.0.4 comme étant notre principale de l'IDE.
Et je dois dire qu'encore une fois, je suis assez déçu dans les préoccupations de la performance:
WTP 3.2.3 semble être beaucoup plus lent que 3.0.4.
En fait, je me demande vraiment pourquoi WTP devient plus lent, avec chaque version.
L'une de nos applications (dynamic web project) contiennent environ 4000 classes java et 700 pages jsp/jsp fragments. Nous avons seulement besoin de base de la volonté à payer des fonctionnalités pour le développement jsp, xmls et xsd. Nous n'avons pas besoin de haute sophistic fonctionnalités comme Dali (devrait JPA outils vraiment couvert par un webtools projet?), La balance ou un visual éditeur xml en premier lieu.
Un autre point intéressant est que la VDP semble ralentir l'ensemble de l'IDE.
SWT est non-reponsive pour une fraction de secondes, l'utilisation du processeur est très élevé (en particulier après un construit, a eu lieu - si vous regardez le système emplois, plusieurs jsp/javascript indexeurs sont en train de faire des travaux pour quelques minutes, même si tous les WTP construire les validateurs ont été désactivés), l'ouverture de nouveaux fichiers sont plus lents, de naviguer à travers le projet, etc.
Cela peut être particulièrement visibles sur les vieilles machines qui ne contient qu'un seul core.
Le pire, c'est que j'ai l'impression que la VDP de l'équipe de développement ne se soucient pas beaucoup sur les performances
(par exemple, avoir un regard sur le http://wiki.eclipse.org/WTP_Performance_Tests page - dernière mise à jour a eu lieu en 2008).
Les rapports de bogues et des messages du forum au sujet de l'exercice de fonctions de base (par exemple, jsp modification/validation) sont souvent ignorés ou fermé peu de temps après, quelques exemples: ici, ici, et ici.
Quo vadis, la volonté à payer?
S'il vous plaît ne vous méprenez pas:
Je ne veux pas blâmer WTP.
En fait, je crois que la VP est un bon projet open-source développé par une équipe talentueuse.
Mais, évidemment, la projet a un problème avec son assurance de la qualité, notamment en termes de performance qui touche de convivialité et d'acceptation par l'utilisateur.
Je veux juste souligner que l'équipe doit se concentrer sur les choses qui sont essentiel à la plupart des utilisateurs en premier lieu et ensuite travailler sur la mise en œuvre de super-duper-fonctions.
Mes Questions
- Quelles sont vos expériences avec WTP, en particulier les versions les plus récentes?
- Pouvez-vous confirmer ou infirmer mes observations?
- Sont t-il de meilleures solutions de rechange?
- Avez-vous passer de ou de CAP et pourquoi?
- Avez-vous des meilleures pratiques pour l'accélérer, en particulier pour le haut-de taille moyenne comme la nôtre?
Mise à JOUR
Je voudrais faire une mise à jour sur cette question afin de refléter le courant des réponses et des
pour résumer les résultats actuels:
-
De nombreux utilisateurs se plaignent plus ou moins sur les mêmes questions, donc je vois ces questions, comme l'a confirmé.
BTW, cette question est également mentionné sur un communiqué de post sur theserverside.com avec des commentaires supplémentaires. -
Le responsable de la VP chef de projet, nitind, de façon remarquable post sur la situation actuelle de la VDP, dont j'aime à citer:
"Le simple fait est que nous ne passons pas beaucoup de temps sur les tests de performance parce que nous manquons de ressources pour le faire."
"Bien sûr que nous aimerions être proactif plutôt que réactif, mais nous avons tendance à attribuer notre temps à des problèmes fonctionnels en premier."
Ainsi, cette question tourne un peu dans une sorte de lettre ouverte à la communauté de la VDP de l'équipe:
Dear WTP team,
it's obvious that WTP is suffering from major quality/performance issues
which you try to play down or to ignore.
Please invest some time to improve the current situation
at the cost of new features and do everything what's required
to solve the current problems.
E.g. revive the performance team, do some regression tests between
previous releases or ask the community for (precise defined) help.
I am sure that they are enough people willing and able to help here.
If you like, do some kind of poll to get a feeling what should be
the most important scopes of future's WTP releases.
Please, please, listen to your community.
- J'ai le même problème avec WTP performances, mais n'ont pas trouvé de solution/fix/hack pour accélérer les choses. J'espère que quelque chose tourne jusqu'ici.
- Avez-vous essayé de poster vos préoccupations à l'Éclipse forums/groupes de discussion? Vérifiez également Bugzilla et voir si quelqu'un a soulevé la moindre performance des bugs?
- Oui, j'ai créé quelques liées à la performance de bugs, et j'ai exprimé mes préoccupations à la liste de diffusion il y a quelques temps. Mais la volonté à payer les développeurs semblent ignorer la situation de plus ou de moins. J'ai reçu une réponse comme "l'analyse des fichiers jsp est une chose complexe," que "ok, on va faire de profilage de travail pour voir si il y a un problème". J'ai créé ce stackoverflow question de me faire une idée si je suis la seule personne qui a l'expérience de ce genre de problèmes avec WTP. Je pense que la VDP de l'équipe doit se concentrer sur les performances de la prochaine version de l'ajout de nouvelles fonctionnalités.
- Juste assez 🙂 je n'ai pas utilisé la volonté à payer beaucoup, donc je ne peux pas vraiment commenter.
- Quel type de matériel utilisez-vous? J'ai de bonnes performances avec Eclipse sur mon ancien Sun Ultra-20 (2,5 GHz single-core Opteron w/ 4G), mais je n'ai pas de projets aussi grand que le vôtre. Si vous êtes encore sous-single-core machines de développement, je l'avais question de savoir si vous devriez être mise à niveau du logiciel. SoTA logiciel a toujours exigé de SoTA matériel à courir, il n'y a pas à contourner.
- La plupart de nos matériels contiennent un Dual-Core Intel Core i5 660 CPU avec 3,3 Ghz, 4 GO de RAM, fonctionnant sous Windows XP.
- Votre entreprise est de penser à investir de l'argent pour le VDP de l'équipe? si vous faites cela, vous pouvez demander de l'performance test 🙂
- Le mot! Cela devient de plus en plus pire. attente de 20 Minutes pour l'enregistrement d'un 30 lignes de fichier xhtml qui se passe assez souvent. Parfois, les IDE se fige pendant plus de 5 Minutes lorsque vous essayez de modifier un fichier jsf. Totalement pas cool...
- Article intéressant (malheureusement disponible qu'en allemand) concernant les enjeux actuels (et futurs) de l'éclipse en général: heise.de/developer/meldung/...
Vous devez vous connecter pour publier un commentaire.
De répondre, je suis le plomb pour les projets d'approvisionnement de la JSP, XML, JavaScript et la modification de la source de la fonctionnalité dans la VDP. Le simple fait est que nous ne passons pas beaucoup de temps sur les tests de performance parce que nous manquons de ressources pour le faire. Bien sûr, nous aimerions être proactif plutôt que réactif, mais nous avons tendance à attribuer notre temps à des problèmes fonctionnels de la première. Nous avons un adoptant le produit en marche de régression de la performance des tests régulièrement, mais je pense que les tests sont exécutés sur multi-core machines à maintenant, et nous n'avons pas eu de nouvelles des "drapeaux rouges" signalés pendant un certain temps.
De l'3 bugs que vous avez lié à, 2 sont antérieurs à la version 3.0.4 vous laud et la troisième est une mise en forme du problème de performance (depuis réglé) ou l'un avec as-you-type de validation spécifique pour les fichiers XML (la fixation de ce qui aurait provoqué une fuite de mémoire dans Xerces, iirc, donc à ne pas nous mettre dans de l'époque). Si vous avez des projets concrets que vous pouvez attacher à un bug, et que dire de "faire X est plus lente en 3.2 en Y montant", nous allons faire ce que nous pouvons savoir d'où il y a une régression.
Comme pour les indexeurs, ils devraient au moins finalement complète. Le disque de l'information qui est stockée qui a changé entre la volonté à payer des versions, et ces fichiers doivent être retraitées ils sont donc de nouveau inclus dans la recherche et l' (où en œuvre) opérations de refactoring. Une fois l'indexation initiale est terminée, il doit agir de façon progressive et être quasiment nul. Un changement architectural, vous pourriez être en cours d'exécution, c'est que pour les Jsp, l'ensemble de l'espace de travail doit être indexé dans unique workbench session pour cet index pour être considéré comme "up to date". L'arrêt de l'Éclipse de la frustration ne feront que prolonger l'impact de ce retraitement.
Il semble que votre société d'installation standard comprend l'intégralité de la volonté à payer plutôt que de rouler votre propre distribution. Je vous invite à vérifier la de Démarrage et d'Arrêt page de préférences et de désactiver le début du démarrage de toutes les fonctionnalités que vous n'êtes pas intéressé par l'aide. Rien de ce que vous avez mentionné l'intérêt en fait usage de cette possibilité, mais il y a d'autres domaines de la VP et de la Plate-forme qui ne. Tout ce que vous n'êtes pas intéressé par la validation est un jeu équitable sur le Validation page des préférences, ainsi que la mise à valider JSP fragments par défaut sur le Web /Fichiers JSP /Validation page de préférences.
Nous avons le même problème avec WTP 3.2.3 ici, trop. Nous l'utilisons dans notre produit pour plusieurs années, mais l'acceptation de nos développeurs et des clients dans cet outil est en baisse chaque année, parce que dans chaque version plus récente, il est plus lent et plus lent.
Je voudrais l'utiliser si je pouvais désactiver toutes les fonctionnalités "avancées" mais comme vous l'avez mentionné, vous ne pouvez pas désactiver les indexeurs à tous. Aussi vous ne pouvez pas arrêter le programme de validation des fichiers JSP si il est déjà en cours d'exécution (vous pouvez le tester, si vous avez beaucoup de fichiers que vous avez et nous avons aussi autour de 1000 JSP de fichiers et les fichiers de balises dans notre projet).
Je peux aussi prouver que l'augmentation de la mémoire n'aide pas. Il permet de prévenir les accidents de la totalité de l'éclipse, mais il ne réduit pas l'INTERFACE utilisateur de blocage des opérations internes de la VDP.
Dans la version la plus récente 3.2.3 j'ai eu beaucoup se bloque lorsque je démarrer Tomcat de l'intérieur de la serveurs de vue. Le de l'INTERFACE utilisateur juste se bloque sur 1 minute. Ce n'est pas seulement moi qui le bloque, c'est l'ensemble de mes collègues qui travaillent sur Windows ont le même problème. Sur Linux, je ne sais pas à propos de ce problème.
Il existe également des problèmes dans la volonté à payer lorsque vous n'avez pas accès à internet. Il semble qu'il y a la demande de certains registres pour télécharger les schémas ou de telles choses et si vous n'avez pas de connexion, puis il se bloque et attend le temps.
Je ne sais pas qui est à blâmer: CAP ou JBoss Tools.
Le fait est que, comme je travaille avec GWT minimale (JSP), je suis allé le chemin inverse: Pas de CAP à tous!!! Je suis maintenant à l'aide de la plaine Eclipse pour Java, et d'utiliser une configuration d'essai pour le déploiement (par programmation en invoquant ANT) et démarrer le serveur, et je n'ai jamais regardé en arrière!!!
Eclipse utilisé pour prendre ~1,5 GO et s'est écrasé à plusieurs reprises. Maintenant, il est assis sur ~800 MO, et l'ensemble de l'environnement est devenu plus stable.
J'ai vu des effets similaires, voici une solution qui pourrait être appropriée dans certains environnements de projet...
Pour garantir vite et responsable de l'Éclipse de projet Web, de l'environnement, pensez à ceci:
Résultat: fast & sensible Eclipse comparativement à beaucoup d'autres Éclipse les installations qui utilisent Eclipse EE version avec de la volonté à payer des trucs.
Pourquoi? Il se pourrait que certaines fonction Eclipse ou plugin contient des bugs ou tout simplement utilise les ressources dans une mauvaise voie, et cela rend l'INTERFACE utilisateur d'Eclipse lent.
Non-Java EE Eclipse est assez bon, même pour beaucoup de projet Java EE environnements, tout dépend de l'architecture et quels sont les outils que vous utilisez..
Voici un petit tutoriel pour commencer dans le cas où vous souhaitez essayer la Jetée de Conteneur de Servlet avec Eclipse. Voir https://vaadin.com/web/jani/home/-/blogs/vaadin-for-everyone-how-to-get-started . Télécharger VaadinProjectForAnyIDE.zip c'est un projet Eclipse. Juste ignorer que Vaadin des trucs et de les remplacer HelloWorldApplication.java avec votre propre servlet et de modifier web.xml en conséquence.
Une chose de plus. Avec Eclipse EE version, vous pouvez également essayer J2EE aperçu serveur qui est en fait Jetty embarqué dans Eclipse bundle. Toutefois, cela utilise aussi WTP mécanisme.
Je pense aussi que la stabilité et les performances de Eclipse/WTP est assez inquiétant. Je suis à l'aide d'Eclipse depuis la mi-2003 et ont essayé de WTP depuis ses premières versions.
Au premier abord, la qualité est absolue insondable, mais pour un 0.x version je ne pouvais pas me plaindre de cours. En attendant de la VP à maturité, j'ai utilisé MyEclipse, qui était en quelque sorte d'accord mais a ses défauts aussi (et étant en partie basé sur la volonté à payer, hérité de certaines de WTP).
Quand MyEclipse est devenu de plus en plus lourd, plus lent et plus lent et nous avons rencontré plusieurs problèmes de stabilité, nous nous sommes mis à "pure CAP'. Tous nous avons été à l'aide est vraiment la base de JSP/JSF éditeur et deployer.
Depuis WTP ne pas faire de déploiement incrémentiel (au moins pas pour le serveur JBoss runtime), nous avons ajouté la séparer d'exécution du serveur de JBoss tools. Lorsque nous avons adopté la Facelets, nous avons aussi opté pour l'éditeur de JBoss tools.
Cependant, nous rencontrons beaucoup de problèmes, nous avons aussi eu avec MyEclipse. Il y a des ralentissements inexplicables, mais bien pire sont différents des problèmes de stabilité. Il y a beaucoup de maladroit exceptions et les accidents. Un typique .fichier journal sur de nombreux postes de travail différents, j'ai examiné est plein à craquer d'exceptions. Une petite sélection des 10 dernières exceptions dans mon journal:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Noter que ce sont juste les 10 dernières, il y a de nombreuses exceptions.
Le casual réaction serait: "Eclipse installation est corrompu! Vous avez un problème local!" Oui, je pourrais avoir un problème local, mais ce "problème local" semble largement répandue que de nombreuses Eclipse installe j'ai inspecté semblent avoir ce genre de choses dans leurs journaux.
Je suis aussi à avoir des problèmes avec les déploiements comme signalé sur le lien suivant dans diverses incarnations: http://community.jboss.org/thread/158611 Il peut être JBoss outils spécifiques ou il peut être sur la base de la volonté à payer ou même Éclipse de code. Je ne sais pas, mais je sais que c'est un méchant problème. Chaque WTP et JBoss tools version il y a " quelque chose de fixe, et chaque version d'un tel problème refait surface sous une forme légèrement différente.
Entre les problèmes de stabilité, je suis en mesure d'obtenir un peu de travail, et j'aime la saisie semi-automatique et de naviguer dans les fonctionnalités les éditeurs de m'offrir (ce qui m'empêche de passer à un éditeur de texte et un bâtiment complètement sur la ligne de commande), mais j'aimerais plus de stabilité.
De loin la meilleure façon d'accélérer mon projet a été de précompiler code que je ne suis pas en train d'utiliser. Nous avons environ 20 projets qui composent notre système et lorsque l'on travaille sur un problème spécifique, je suis le seul à en toucher un sous-ensemble spécifique de ces fichiers java. La compilation de la plupart des codes que je ne sois pas toucher et de le jeter dans certains .jar, puis en utilisant ce que la source à la place de, y compris les projets de a prouvé pour accélérer les choses en un peu. J'imagine que ce sera vous aider si vous avez 4k+ fichiers.
Chaque projet a juste un peu build.xml qui va faire un pot pour inclure.
Comme pour l'esprit d'engourdissement de la lenteur dans la page JSP d'édition. J'ai les mêmes problèmes, c'est juste à ce barrage lent. Je n'ai pas beaucoup plus de 100 fichiers jsp mais j'ai les mêmes problèmes que vous. Ma solution a été de jeter de l'argent au matériel, ce qui je dois avouer que j'aime faire :P.
Pour répondre à la question suivante:
Avez-vous des meilleures pratiques pour l'accélérer, en particulier pour le haut-de taille moyenne comme la nôtre?
Désactivation de la validation et de l'auto-construction après enregistrement de fichier est un bon début pour augmenter les performances.
J'ai désactivé le WTP éditeur JSP pour les raisons que vous avez mentionnées ci-dessus: Il y a juste trop de ressources. Certaines choses que vous devriez considérer:
Modifier les Jsp dans le cadre normal de l'éditeur HTML. Cela signifie que vous n'obtenez pas de complétion de code qui est une bonne chose. OMI, Mélange de Java et HTML est une erreur dans la première place et un éditeur ne peut pas résoudre ce problème. Mettre tout le code Java dans helper haricots (que vous pouvez tester facilement) et d'accéder simplement à les haricots de JSP. Cela devrait se débarrasser de 99% de tous les
<% %>
balises et résoudre la plupart de vos problèmes déjà.Envisager d'utiliser du Printemps pour être en mesure de construire plus complexe de haricots et de les injecter dans votre Jsp à l'aide de ces modèles:
Utilisation SpringBeanAutowiringSupport:
Essayez une autre VM. VDP des éditeurs crée d'énormes quantités d'objets et de maintenant, toutes les machines virtuelles (GC mises en œuvre) peuvent gérer aussi bien. Si vous utilisez Java de Sun, essayez JRockit ou Ibm J9. Jouer avec la GC paramètres. L'augmentation de la RAM ne va pas aider parce que si vous avez GC questions, plus de RAM généralement l'aggrave (depuis le GC aura à traiter plus de données).
Précompiler autant de code que possible. Vous n'avez pas besoin de 4000 classes ouvertes à tout moment sur votre espace de travail. Couper votre énorme projet en parties gérables.
Remplacer les Jsp avec la plaine des servlets Java et l'utilisation de rendu HTML des bibliothèques comme rendersnake ou de l'utilisation d'un langage de programmation qui joue de plus belle avec le HTML (comme Groovy).
Obtenir certaines matériel décent. Un nouveau PC avec un processeur quad core et 8 go de RAM au prix de $1000. Si vous enregistrez dix minutes chaque jour, l'investissement sera payé à 50 jours (au taux de 1 personne frais de 1000 $par jour dans l'ensemble).
Essayer MyEclipse qui a beaucoup plus de rédacteurs web. L'éditeur JSP est mieux que WTP (complétion de code fonctionne la plupart du temps, par exemple) mais c'est toujours lent.
WTP (3.2.3) est lent pour moi aussi. Je crois que j'ai trouvé des façons de rendre pas si lent:
target
répertoire qui contient une copie de tous les JSP et quelques autres XML de. J'ai reconnu qu'ils sont parfois balayé par le VDP des validateurs. Mais ce n'est pas nécessaire, j'ai donc exclus de validation (Projet/Propriétés/Validation/XXX/Exclure/Groupe). (Vous devriez être en mesure d'obtenir le même effet lors du marquage de l'target
répertoire que dérivé, mais cela ne fonctionne pas pour moi quelques fois ;-( )Si vous avez besoin de barebones Java EE, alors vous êtes mieux avec Netbeans, si vous avez besoin de tout, mais seulement de travail, vous êtes mieux avec l'IDÉE. C'est aussi simple que cela.
Ne pouvais pas le commentaire, donc je vais juste mettre mon commentaire à cette réponse.
Avez-vous essayé de monter l'Éclipse de l'allocation de mémoire, je sais que c'utilisé pour planter tout le temps quand je l'ai utilisé sur Mac OS X y a quelques temps. Il y a un fichier de config qui a la base allocation de RAM, une fois que je l'ai modifié le fichier en question et donné un supplément de 128 mégaoctets de mémoire, il s'est comporté mieux. Vous ne savez pas si cela va affecter la WTP, je suis de commenter plus en ce qui concerne le noyau d'Eclipse application elle-même.