Feed aggregator
Zero to Drupal: St. Louis Drupal Users Post-Drupalcon Meetup
Just a quick note that the St. Louis Drupal Users group chose to reschedule our normal meetup, which occurs every third Thursday of the month, to next week, the week after Drupalcon Portland. Last year, we had a meetup right after Drupalcon Denver and had a great turn out. Those who weren't able to attend learned what it's like to attend Drupalcon, and also got valuable insight into the sessions, keynotes, and other events surrounding this great event. This year, we have at least a few known members who are here at Drupalcon (along with myself for the first time), who will be sharing their experience with the group at next week's meetup.
So if you live in or around the St. Louis area, or know someone who does, please be sure to join us this Thursday, from 7p-9p at the Missouri History Musuem (more details about the meetup can be found here).
Tagstsvenson: Our Drupal Workplace: The Issue Queue
Sooner, not later, you will end up in the Issue Queue on d.o. Its practically unavoidable if you want to get the most out of your relation with Drupal.
The more involved you get, particularly as a code developer or themer, you will find that you spend more and more of your time working on and jumping around between issues. The list of issues you are active in and/or monitoring is constantly growing.
At this point you have turned the issues queue into: Your Workplace!
Read the full "Our Drupal Workplace: The Issue Queue" post on www.tsvenson.comPixelite: How to find and debug large variables in Drupal 7
Tweet Widget Facebook Like Google Plus One Linkedin Share Button
On a recent large Drupal project we were finding that the variable table was holding around 4 MB of data. The issue of course with this is that this is loaded into memory on each page request regardless of whether or not you use it. Another issue is that the variable table holds serialized data, and there is an additional CPU overhead of actually de-serializing the data as well.
Introducing Variable debugSo I wrote a module Variable debug that is a straight forward and simple module that attempts to do only two things (at the moment):
A list of the highest memory usage variables stored in the {variable} table sorted by highest to lowest. There is also a list of links to Drupal.org issues to help resolve some known high usage offenders. If you know of an issue that exists that aims to resolve in-efficient usage of the variable table, please raise a new issue in the issue queue for this module.
A list of all suspected orphaned variables in the variable table. This is determined by whether or not the variable is:
- Not a variable provided by Drupal core
- Does not start with an enabled module name
This can help you find and remove potential abandoned variables that are of no use to you and your site.
Sometimes Drupal contributed modules use the variable table as a dumping ground for large variables that really should be stored in dedicated tables. Here is an example from one of our websites using the SQL query:
SELECT LENGTH(value) AS length, name FROM variable ORDER BY length ASC;And the end of the result:
| 534 | hs_config_taxonomy-17 | | 551 | subscription_mail_status_activated_body | | 561 | hs_config_taxonomy-13 | | 573 | googleanalytics_custom_var | | 580 | article_import_known_columnists | | 600 | menu_masks | | 617 | order_completion_text_digital_auth | | 620 | menu_default_active_menus | | 622 | order_completion_text_corporate_auth | | 626 | user_mail_register_no_approval_required_body | | 638 | menu_minipanels_hover | | 660 | field_bundle_settings_node__page | | 666 | article_import_known_agencies | | 700 | field_bundle_settings_node__collection | | 702 | field_bundle_settings_node__article | | 733 | order_completion_text_print_auth | | 781 | field_bundle_settings_node__promotion | | 869 | order_completion_text_digital | | 903 | subscription_activation_text_unverified | | 939 | order_completion_text_print | | 955 | order_completion_text_corporate | | 991 | field_bundle_settings_node__subscription | | 1012 | subscription_activation_text_pending | | 1073 | field_bundle_settings_commerce_product__subscription_product | | 1278 | entityreference:base-tables | | 1783 | high_risk_districts | | 1988 | commerce_enabled_currencies | | 2356 | metered_useragent_whitelist | | 2515 | rules_empty_sets | | 2796 | apachesolr_index_last | | 3178 | memcache_wildcard_flushes | | 3673 | drupal_js_cache_files | | 7804 | features_codecache | | 14840 | drupal_css_cache_files | | 852329 | imagefield_crop_info | +--------+-----------------------------------------------------------------+ 1207 rows in set (0.02 sec)Anything over several hundred bytes in the variable table really has to take a step back any look at better utilising cache tables.
Integration with Drupal.org issuesThe next feature I added to the module was known large variables, and links to Drupal.org issue queue items that contain patches to resolve the large memory usage.
Here is a screenshot showing the functionality.
QuestionsLet me know in the comments if this helps you, also if you have any other known rogue variables that have Drupal.org issues, that would also be welcome.
Tags drupal drupalplanet debugging code development Source Variable debug Category TutorialFlickr: Vincenzo & Brandon
m.gifford posted a photo:
Flickr: From Core Conversations
m.gifford posted a photo:
Flickr: DSC03291
m.gifford posted a photo:
Pages
